Page History
...
- Client to Venue - Clients should ideally always ensure that all published timestamps are at the greatest precision that they can support. For fields that will be mapped through to an equivalent field on the outbound venue message (such as
TransactTime,ValidUntilTime,EffectiveTime,ExpireTime, etc), Whisperer will always utilise the full precision supported by the venue, with the client value being truncated as necessary. - Venue to Client - Whisperer will always publish the full precision available in any timestamp received from the venue. Typically FIX venues provide millisecond values, but some fields may be second, or microsecond precision. Binary APIs will typically offer microsecond or nanosecond precisions.
Prices and Quantities
Overview
...
| Note | ||
|---|---|---|
| ||
A feature of FIX protocol interfaces (vs binary APIs) is that they involve an integer to string conversion when constructing the message. The way this is performed varies not only across venues, but also across individual fields or message types. The net result is that trailing zeros for a fractional component may not always be published, so that a price could move between "1.1999" and "1.2", vs the "1.2000") that would be most consistent. |
Nullness
The SBE Technical Specification contains the definition of nullness for composite types, such as PriceNULL and DecimalQtyNULL:
4.5.4.4 Null value of a composite type
For a composite type, nullness is indicated by the value of its first element. For example, if a price field is optional, a null value in its mantissa element indicates that the price is null.
The MF API additionally offers a nullable exponent to offer convenience support for integer types, when needed:
- There is no need to differentiate between exponent = 0 and exponent = NULL.
- A NULL exponent with a valid mantissa is treated exactly the same as exponent = 0. Therefore, when the mantissa is present (i.e., not NULL), an exponent value of 0 should always be treated as a valid exponent (i.e., scale = 10⁰).
Key Rules
- Mantissa determines nullness of the price
- If mantissa =
-9223372036854775808, the entire price is NULL - Exponent should not drive null logic
- Even though its encoded nullValue is 0, it should not be interpreted as “missing” when mantissa is valid
- No caching should be applied based on exponent = 0
- Exponent = 0 must be treated as a real value, not a signal to reuse a previous value
Scaling Considerations
The maximum mantissa value is 2^63 - 1 = 9,223,372,036,854,775,807
...
LegAllocQty= 1,000,000.000000000 = 1,000,000,000,000,000 * 10-9LastPx= 1.047400 = 1,047,400 * 10-6LegCalculatedCcyQty= (1,000,000,000,000,000 * 1,047,400) * 10-9-6 = 1,047,400,000,000,000,000,000 * 10-15 = 1047400.000000000000000- 1,047,400,000,000,000,000,000 > 9,223,372,036,854,775,807 and is thus not representable.
Such problems are easily avoided by ensuring that Quantities in particular are always scaled appropriately.
Negative Values
DecimalQtyNULL and PriceNULL may both be used to represent negative values:
...
Examples below:
| Value | Mantissa | Exponent |
|---|---|---|
| 1.2345 | 12345 | -4 |
| 1.23 | 123 | -2 |
| 1.2300 | 12300 | -4 |
| 123.00 | 12300 | -2 |
| 0.0001234 | 1234 | -7 |
| 1000000 | 1000000 | 0 |
| 1567234.56 | 156723456 | -2 |
| -0.01 | -1 | -2 |
| -500000 | -500000 | 0 |
| 0 | 0 | 0 |
| 0.0000 | 0 | -4 |
...
Overview
Content Tools