Using Fast Reference API for scaled numbers

, ,
1

Imported from previous forum

2

Hi,

does anyone know how to encode/decode scaled numbers (with mantissa and exponent) using C Reference API? I can’t seem to find any method…

Thanks,
Dimitry

3

Hi Dimitry,

the fastapi-1.0 lacks support for scaled numbers and it
would be hard to fully implement scaled numbers due to
lack of support for NULL values and optional pmap slots

(the number of pmap slots for a scaled number may vary
depending on the value of the exponent in the case of
an optional scaled number field)

So, in short, it would be possible to emulate part of
the scaled number functionality, but it isn’t feasible
to implement full 1.1 scaled number support without a
re-write of most of the fastapi-1.0 implementation.

/Rolf

Hi,

does anyone know how to encode/decode scaled numbers
(with mantissa and exponent) using C Reference API?
I can’t seem to find any method…

Thanks, Dimitry

4

Thanks, Rolf, this makes sense.

This means that I would need to implement this functionality myself if I need to support scaled numbers. By the way, why do the scaled decimal numbers use base 10 rather than base 2 like floating point numbers. It seems to me that if my implementation would send a floating point number accross, it would make sense to maintain the same floating point representation consistenly for efficiency reasons. That is, if I have a number stored as a “float”, it would make sense to communicate it to my client processes as a float as well.

Dimitry

Hi Dimitry,

the fastapi-1.0 lacks support for scaled numbers and it would be hard to
fully implement scaled numbers due to lack of support for NULL values
and optional pmap slots

(the number of pmap slots for a scaled number may vary depending on the
value of the exponent in the case of an optional scaled number field)

So, in short, it would be possible to emulate part of the scaled
number functionality, but it isn’t feasible to implement full 1.1 scaled
number support without a re-write of most of the fastapi-1.0
implementation.

/Rolf

Hi,

does anyone know how to encode/decode scaled numbers (with mantissa
and exponent) using C Reference API? I can’t seem to find any
method…

Thanks, Dimitry

5

Hi Dimitry,

Always using floating point would mean loss of precision (rounding errors and so forth) in many typical financial applications. By using base 10, the FAST protocol can provide bit-to-bit numerical integrity when used to transport FIX for example.

This doesn’t mean that a floating point type wouldn’t be useful in some applications, but it has not been a priority for FAST to this date.

/David

Thanks, Rolf, this makes sense.

This means that I would need to implement this functionality myself if I
need to support scaled numbers. By the way, why do the scaled decimal
numbers use base 10 rather than base 2 like floating point numbers. It
seems to me that if my implementation would send a floating point number
accross, it would make sense to maintain the same floating point
representation consistenly for efficiency reasons. That is, if I have a
number stored as a “float”, it would make sense to communicate it to my
client processes as a float as well.

Dimitry

6

Thanks, David, for ASCII it makes sense. My point, however, was that for numerical calculation there will be additional performance cost due to the conversion - if the native format for the MDPrice is floating point, then it makes sense to sent it to the peer in exactly the same form. For now, however, it seems that I have to perform this conversion until there is support for floating point in the future FAST versions.

Dimitry

Hi Dimitry,

Always using floating point would mean loss of precision (rounding
errors and so forth) in many typical financial applications. By using
base 10, the FAST protocol can provide bit-to-bit numerical integrity
when used to transport FIX for example.

This doesn’t mean that a floating point type wouldn’t be useful in some
applications, but it has not been a priority for FAST to this date.

/David

Thanks, Rolf, this makes sense.

This means that I would need to implement this functionality myself if
I need to support scaled numbers. By the way, why do the scaled
decimal numbers use base 10 rather than base 2 like floating point
numbers. It seems to me that if my implementation would send a
floating point number accross, it would make sense to maintain the
same floating point representation consistenly for efficiency reasons.
That is, if I have a number stored as a “float”, it would make sense
to communicate it to my client processes as a float as well.

Dimitry

7

Yes, and I agree with your point, only that it hasn’t been a priority to FAST this far. But as FAST gain more speed and gets used in other context than initially considered, I’m sure a future revision of the standard will consider including support for floating point types.

/David

Thanks, David, for ASCII it makes sense. My point, however, was that for
numerical calculation there will be additional performance cost due to
the conversion - if the native format for the MDPrice is floating point,
then it makes sense to sent it to the peer in exactly the same form. For
now, however, it seems that I have to perform this conversion until
there is support for floating point in the future FAST versions.

Dimitry

8

Thanks a lot, David. By the way, is there any ETA for the next reference C fastapi implementation?

Dimitry

Yes, and I agree with your point, only that it hasn’t been a priority to
FAST this far. But as FAST gain more speed and gets used in other
context than initially considered, I’m sure a future revision of the
standard will consider including support for floating point types.

/David

Thanks, David, for ASCII it makes sense. My point, however, was that
for numerical calculation there will be additional performance cost
due to the conversion - if the native format for the MDPrice is
floating point, then it makes sense to sent it to the peer in exactly
the same form. For now, however, it seems that I have to perform this
conversion until there is support for floating point in the future
FAST versions.

Dimitry

9

AFAIK, there’s is no next reference impl in the works.

/Rolf

Thanks a lot, David. By the way, is there any ETA for the next
reference C fastapi implementation?

Dimitry

Yes, and I agree with your point, only that it hasn’t been a priority
to FAST this far. But as FAST gain more speed and gets used in other
context than initially considered, I’m sure a future revision of the
standard will consider including support for floating point types.

/David

Thanks, David, for ASCII it makes sense. My point, however, was that
for numerical calculation there will be additional performance cost
due to the conversion - if the native format for the MDPrice is
floating point, then it makes sense to sent it to the peer in
exactly the same form. For now, however, it seems that I have to
perform this conversion until there is support for floating point in
the future FAST versions.

Dimitry

10

Thanks, Rolf.

Dimitry

AFAIK, there’s is no next reference impl in the works.

/Rolf

Thanks a lot, David. By the way, is there any ETA for the next
reference C fastapi implementation?

Dimitry

Yes, and I agree with your point, only that it hasn’t been a
priority to FAST this far. But as FAST gain more speed and gets used
in other context than initially considered, I’m sure a future
revision of the standard will consider including support for
floating point types.

/David

Thanks, David, for ASCII it makes sense. My point, however, was
that for numerical calculation there will be additional
performance cost due to the conversion - if the native format for
the MDPrice is floating point, then it makes sense to sent it to
the peer in exactly the same form. For now, however, it seems that
I have to perform this conversion until there is support for
floating point in the future FAST versions.

Dimitry