converting float to double

[Dilip]

Recently in our code, I ran into a situation where were stuffing a
float inside a double. The precision was extended automatically
because of that. To make a long story short, this caused problems
elsewhere in another part of the system where that figure was used for
some calculation and some eventual truncation led to the system going
haywire. So my question is, given this code:

int main()
{
float f = 59.89F;
/* the following line caused problems */
double d = f;

/* they ended up solving it like this */
f *= 1000.0;
double dd = (double)f / 1000.0;

return 0;
}

I see what is being done but why does the latter make the situation
better?
(consider 'f' in real life to hold stock prices)

[Dilip]

Dik T. Winter wrote:

In article <11************ **********@79g2 000cws.googlegr oups.com"Dilip" <rd*****@lycos. comwrites:

(consider 'f' in real life to hold stock prices)

Consider not to use floating point for stock prices. Floating point
inherently carries imprecision (especially if you want to do decimal
calculations), which you do not want with stock prices.

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.

[Random832]

2006-12-20 <11************ *********@79g20 00cws.googlegro ups.com>,
Dilip wrote:

Dik T. Winter wrote:

>In article <11************ **********@79g2 000cws.googlegr oups.com"Dilip" <rd*****@lycos. comwrites:

> (consider 'f' in real life to hold stock prices)

Consider not to use floating point for stock prices. Floating point
inherently carries imprecision (especially if you want to do decimal
calculations ), which you do not want with stock prices.

THis isn't always possible. The market data vendor I connect to
insists that I read the stock prices as float.

Get a new vendor?

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.

Well - if you can't get a better vendor, the best way would be to do this:

#include <math.h>
//...
float floating_price;
long int price_cents;
//...
price_cents = round(f*100.);

That way you'll actually get the value to the nearest cent, instead of
doing "voodoo magic" that happens to get the right answer in one
specific case you tested it on.

If you need tenths of a cent, use 1000. there, etc, whatever precision
you need. From that point, use the integer representation throughout
your program.

[Ben Pfaff]

Random832 <ra****@random. yi.orgwrites:

Well - if you can't get a better vendor, the best way would be to do this:

#include <math.h>
//...
float floating_price;
long int price_cents;
//...
price_cents = round(f*100.);

For what it's worth, the round function is new in C99.
--
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan

[Ernie Wright]

Dilip wrote:

Dik T. Winter wrote:

>Consider not to use floating point for stock prices.

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.

Putting float values into doubles probably isn't the cause of your
problems. A double will hold exactly the same value as the original
float.

In most implementations , both float and double represent numbers as

(1 + m / 2^b) * 2^e

where m is (part of) the mantissa, b is the number of bits in m, e is
the exponent, and '^' denotes exponentiation. b is 23 for floats and 53
for doubles. Given the m, b, e of a float, you get the double with

m <<= 30
b += 30
e = e

Or to put it another way,

float: 59.89 - (1 + 7311196 / 8388608) * 32
double: 59.89 - (1 + (7311196 << 30) / (8388608 << 30)) * 32

The values are identical, so the problems must be arising from what is
being done with them.

- Ernie http://home.comcast.net/~erniew

[William Hughes]

Ernie Wright wrote:

Dilip wrote:

Dik T. Winter wrote:

Consider not to use floating point for stock prices.

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.

Putting float values into doubles probably isn't the cause of your
problems. A double will hold exactly the same value as the original
float.

True, but irrelevent.

Mathematically

(float) (1000.0 * f) =/= 1000.0 * f

There is a small bit of rounding. So

(double)( (float) 1000.0*f)/ 1000.0 =/= f

In the present case we start out with a value just less than a multiple
of
a whole cent, and end up with a value just greater than a multiple
of a cent.

- William Hughes

[William Hughes]

Dilip wrote:

Dik T. Winter wrote:

In article <11************ **********@79g2 000cws.googlegr oups.com"Dilip" <rd*****@lycos. comwrites:

(consider 'f' in real life to hold stock prices)

Consider not to use floating point for stock prices. Floating point
inherently carries imprecision (especially if you want to do decimal
calculations), which you do not want with stock prices.

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. However, it appears that by management fiat you have
to use this system, and any problems are deemed yours.

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. (adding the fudge factor may or
may
not be necessary. It would not be necessary, but for the fact that you
have to use a broken system. There may be a price that when expressed
as a double is slightly below the true price.)

* if you don't have access to a C99 type round() function, roll your
own
(e.g. floor(100.0*dd + 0.5)/100.0) or sprintf the value and sscanf
it back

- William
Hughes

[CBFalconer]

Dilip wrote:

Dik T. Winter wrote:

>"Dilip" <rd*****@lycos. comwrites:

>>(consider 'f' in real life to hold stock prices)

Consider not to use floating point for stock prices. Floating
point inherently carries imprecision (especially if you want to
do decimal calculations), which you do not want with stock prices.

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.

This is inherently impossible. While some systems use IEEE float
format, many do not, so you don't even know the bit pattern coming
in. Are you sure you aren't reading and converting a text stream?
If so all you have to do is write a suitable parser for a
particular text format, say dddd.dd, where d is a digit.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[CBFalconer]

Ben Pfaff wrote:

Random832 <ra****@random. yi.orgwrites:

>Well - if you can't get a better vendor, the best way would be
to do this:

#include <math.h>
//...
float floating_price;
long int price_cents;
//...
price_cents = round(f*100.);

For what it's worth, the round function is new in C99.

and unnecessary.

price_cents = 100 * floating_price + 0.5;

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Random832]

2006-12-20 <45************ ***@yahoo.com>,
CBFalconer wrote:

Ben Pfaff wrote:

>Random832 <ra****@random. yi.orgwrites:

>>Well - if you can't get a better vendor, the best way would be
to do this:

#include <math.h>
//...
float floating_price;
long int price_cents;
//...
price_cents = round(f*100.);

For what it's worth, the round function is new in C99.

and unnecessary.

price_cents = 100 * floating_price + 0.5;

I thought that was implementation-defined.

[William Hughes]

Random832 wrote:

2006-12-20 <45************ ***@yahoo.com>,
CBFalconer wrote:

Ben Pfaff wrote:

Random832 <ra****@random. yi.orgwrites:

Well - if you can't get a better vendor, the best way would be
to do this:

#include <math.h>
//...
float floating_price;
long int price_cents;
//...
price_cents = round(f*100.);

For what it's worth, the round function is new in C99.

and unnecessary.

price_cents = 100 * floating_price + 0.5;

I thought that was implementation-defined.

Not if price_cents is assumed to be greater than or equal to 0.

- William Hughes