|
FAST Protocol
< Previous Next >
Re: Representing a double as a Fast scaled decimal
Walter Mascarenhas / GeoCAD <>
8 Oct 2008 9:58PM ET Hi everybody,
I believe you should first handle the rounding question
(truncation is much worse than rounding, I would not even
consider it) Once you decide how to round you can decide
how to pack the rounded result.
Let me explain why with the example x = 2.5555 mentioned
earlier. This number cannot be represented exactly as
a double. If you do something like
double xr = atof("2.5555")
then the xr you get is not exactly equal to 2.5555.
Actually, xr is the horrendous number
xr = 2555499999999999882760448599583469331264495849609375 x 10^(-51)
In principle you could convert xr back to decimal
with no rounding (its is always possible to
convert from IEEE float,double to decimal with
no rounding errors if you are wiling to use
enough bits to represent the result)
However, the exact conversion is clearly a
bad idea because you would get a mantissa with
too many digits. Therefore, it is best to
round this number somehow before sending it.
Once you decide what is a reasonable rounding
policy I may try to help you with the algorithm.
Walter.
> Thanks, Daniel.
>
> My first instinct was to use frexp() for double->decimal and ldexp()
> from decimal to double. When I ran some initial benchmarks today I did
> not notice any big overhead.
>
> fxrexp() returns an integer exponent and normalized double mantissa
> (between 0.5 and 1.0). The real challenge is how to represent the
> results in a FAST wire representation - as the mantissa is still
> represented as a double/float rather then integer field. It is possible
> the send mantissa as a bit vector but then it will use at least 4/8
> bytes) not counting the length. So, I don't really like this approach.
>
> Dimitry
>
>
> > Dimitry, I had posted a related thread a while back, see
> > http://fixprotocol.org/discuss/read/eebb5ac9
> >
> > I think the optimal way to do this is to determine the amount of
> > precision you want from the IEEE float or double, and extract the
> > mantissa and exponent to create a scaled decimal. As you would expect,
> > this needs to be optimized, and I am not sure the standard C lib
> > methods are the way to go. Then comes the question of rounding vs.
> > truncation.
> >
> > So, does someone want to submit a good algorithm for conversion ?
> >
> > /Daniel
Re: Representing a double as a Fast scaled decimal
Walter Mascarenhas / GeoCAD 8 Oct 2008 9:58PM ET
|
