Re: converting float to double


dcorbit@xxxxxxxxx wrote:
William Hughes wrote:
Dik T. Winter wrote:
In article <1166646566.617718.113730@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> "William Hughes" <wpihughes@xxxxxxxxxxx> writes:
> Dilip wrote:
...
> > THis isn't always possible. The market data vendor I connect to
> > insists that I read the stock prices as float. So when I reach into
> > the byte-stream I will have to memcpy sizeof(float) number of bytes.
> > Since everywhere else the system uses double to hold these prices, I
> > had no choice but to stuff that retreived float value into a double
> > causing all these problems.
>
> A system that uses floating point variables to store prices should
> work correctly if a price is just above or just below the
> correct price (e.g for a price of 0.010001 dollars or 0.009998
> dollars).
> The system you use does not have this property. It needs
> to be fixed.

How do you fix a system that follows the C standard?

> A possible workaround:
> Read the prices as float
> Round to the nearest cent or tenth of a cent (*)
> Convert to double
> Add a fudge factor of 0.00000001
> Now your prices will be subtly wrong, but they will be subtly wrong in
> the correct direction. This should work as well as the
> (double)(f*1000.0)/1000.0
> kludge, and will work for any value.

But after subtraction you can be subtly wrong the wrong way.


Indeed. This is not a fix. This is a kludge that might work with
a broken system.
The suggested kludge does not make the errors any worse
(we expect an error of about 10e-6 times the shareprice)
It just insures that the errors have a consistent sign. The
alternative
of not adding the fudge factor mean that there will still
be some error with unknown sign. The preferred alternatives
of avoiding or rewriting the software do not appear to be
available.

To avoid
all this is done by internally working with integers, longs, long longs,
or whatever integer size you need.

Just remember you may be dealing with the world GDP expressed
in Turkish lira. Or design your system to use floating point and be
tolerant of
small errors In the end you need to find out what the correct answer
is (this is an accounting, not a mathematical or computer question)
and design your system to give the correct answer. What internal
data type or structure you use to do this is of lesser importance.

A 64 bit integer will correctly model currency to 18 digits (with
hundredths units that gives 16 digits for the integer part).
In a mythical currency with 1,000,000 units per dollar,

Nothing mythical here.

1 US dollar = 1374865.7 Turkish Lira

that would
leave 10 billion dollar transactions accurate to the penny.

So don't use 64 bit integers to calculate the world GDP in
Turkish Lira unless your system is tolerant of small errors.


With 6 digits {typically} of precision, float can barely handle a
decent paycheck. Float is one of the most onerous native C data type
that I can imagine for use with currency.

Both char and short are (probably) worse.
Double on the other hand is fine for many uses.
float has many uses, currency calculations is not among them.


Our database tools do all
calcuations in 110 digits of precision (so that things like interest
calculations for the national debt over 100 years would still yield
sensible results).

As pointed out: Find out what the correct answer is, then design
your system. It may be that no native type is sufficient.



For instance,
select convert(8624231011335.27 * pow(1+(.05/4),100*4), varchar(256))
returns:
1240889574596181.05248622508978018387152633758152697346355368797339001098783576983458982091988194949844928


Looks to me like you are using high precision floating point arithmetic
(rather than arbitrary precision integer arithmetic), then rounding to
get your final answer. Nothing wrong with this strategy, but it is
hardly an argument in favour of integer arithmetic.

- William
Hughes

.

Relevant Pages

  • Re: converting float to double
    ... >> insists that I read the stock prices as float. ... >> Since everywhere else the system uses double to hold these prices, ... A 64 bit integer will correctly model currency to 18 digits (with ... float usnd = 8624231011335.27f * ...
    (comp.lang.c)
  • Re: converting float to double
    ... >> insists that I read the stock prices as float. ... >> Since everywhere else the system uses double to hold these prices, ... A 64 bit integer will correctly model currency to 18 digits (with ... In a mythical currency with 1,000,000 units per dollar, that would ...
    (comp.lang.c)
  • Re: converting float to double
    ... >> insists that I read the stock prices as float. ... >> Since everywhere else the system uses double to hold these prices, ... A 64 bit integer will correctly model currency to 18 digits (with ... In a mythical currency with 1,000,000 units per dollar, that would ...
    (comp.lang.c)
  • Re: Interesting math
    ... Floating point number represents a real number with 6 digits precision. ... Floating point numbers are denoted by the keyword float. ...
    (alt.usage.english)
  • Re: float -> double
    ... Let us take a float with the hexadecimal representation 0x3f800001. ... When converting to double, we get another 29 bits of precision, which means we can theoretically convert this number to any one of 536,870,912 possible representable numbers in the range. ... The exact value could be printed if you really wanted to, but there's no real point since the implicit error in the number dwarfs most of the latter digits. ...
    (comp.lang.java.programmer)