Skip to main content

Overview

NanoARB uses fixed-point arithmetic for all price and quantity calculations to avoid floating-point errors and ensure deterministic behavior across backtests and live trading. This is critical for high-frequency trading where sub-tick precision matters.

Why Fixed-Point?

Floating-point arithmetic has several issues for trading:
Fixed-point arithmetic:
  • Deterministic: Same results on all platforms
  • Exact: No rounding errors for decimal prices
  • Fast: Integer operations are faster than FP
  • Reproducible: Critical for backtest validation

Price Type

Implemented in nano-core/src/types/price.rs:42:
Prices are stored as i64 integers representing the smallest tick unit. For example, with 0.01 tick size:
  • $500.25 is stored as 50025
  • $1000.00 is stored as 100000

Creating Prices

Price Arithmetic

All operations are on raw tick values:

Safe Arithmetic

Use checked/saturating operations to prevent overflow:

Price Comparison

Conversion to Float

Quantity Type

Implemented in nano-core/src/types/quantity.rs:37:
Quantities are unsigned 32-bit integers representing contract/share counts:

Quantity Arithmetic

Saturating Operations

Signed Quantity

For positions (long/short):

Side Type

Implemented in nano-core/src/types/side.rs:24:
Used for order direction:

Timestamp Type

Nanosecond-precision timestamps in nano-core/src/types/timestamp.rs:41:

Creating Timestamps

Timestamp Arithmetic

Timestamp Comparison

Practical Example: P&L Calculation

Combining types for profit/loss calculation:

Zero-Copy Serialization

All types support zero-copy serialization via rkyv:

Performance Characteristics

Memory Size

  • Price: 8 bytes (i64)
  • Quantity: 4 bytes (u32)
  • SignedQuantity: 8 bytes (i64)
  • Side: 1 byte (enum)
  • Timestamp: 8 bytes (i64)

Operation Speed

All operations are single CPU instructions:
  • Addition/subtraction: ~1 CPU cycle
  • Multiplication/division: ~3-5 CPU cycles
  • Comparison: ~1 CPU cycle
Compare to floating-point: 5-10x slower for same operations.

Best Practices

  1. Always use fixed-point types for prices and quantities
  2. Avoid float conversions until final display/logging
  3. Use saturating arithmetic when overflow is possible
  4. Store tick size with instrument metadata
  5. Validate inputs when converting from external sources