Re: converting floating point types round off error ....
On Dec 1, 9:19 pm, forums...@hotmail.com wrote:
Just that. The value in a char* may not be a legal address for
a float or a double. (Of course, if you're messing around with
reinterpret_cast, the value in a float* or a double* may not be
a legal address for a float or a double. Don't use
reinterpret_cast unless you really know what you're doing.)
I hate to become a nuisance but do you have a source where I
obtain some more information on all this? I'm having a hard
time understanding how a char* address could be illegal.
Modern byte addressed hardware usually requires floats to be at
an address that is a multiple of four, and doubles at an address
which is a multiple of eight. A char* can be any address. What
happens when you try to access a float or a double with a
misaligned pointer depends on the machine, but it's usually not
good.
Now assume the problem is binary serialization, I suspect
converting to an unsigned integer large enough for a float or
double then playing games with bit shifting might work?
That's the way I usually do it:-).
OK! I sent a private message to the OP a few days ago to see
if/how he/she resolved this. He hasn't. The OP said he's
seen a handful of your posts where you convert the value to an
unsigned integer type large enough then parse it to the
appropriate floating point type, then suggested I ask you to
show an example of this.
For output, it's pretty straight forward. With most compilers
(but I think g++ no), you can get by with a reinterpret_cast
between double/float and the equivalently sized unsigned
integer, at least for writing. (For reading, you have to
consider the possibility that you'll end up with a signaling
NaN.) Or if the reinterpret_cast doesn't always work with your
compiler, you can resort to memcpy. Having gotten a 4/8 byte
unsigned integer, it's simply a matter of shifting and masking
to output the desired value, PROVIDED your system uses the same
floating point format as that used externally. (In practice,
this generally means IEEE. So you're OK on PC's, Sun Sparcs,
and most other mainstream Unix machines. But not on any of the
mainframes I know of.) Input is similar: you read bytes,
shifting and or'ing them into an appropriately sized unsigned
integer. Then you check to ensure that it isn't a signaling
NaN, and if not, you can safely move it into the float/double.
(This results in XDR representation for floats.)
If your portability needs are limited to machines supporting
IEEE floating point, however, memcpy'ing the floating point
value into an unsigned integral type of the same size, then
shifting an or'ing, is sufficient, and may be slightly
faster. (At least on a Sparc, however, the above is not
outrageously slow.)
Even so there's no guarantees in all this correct?
Which of all this? The code I posted is guaranteed to output a
floating point value in XDR format, regardless of the machine,
provided that the value is representable.
It seems to me that you're there's no portable way to
reinterpret_cast a T* to a char* or vice versa. True/False?
There's nothing you can portably do with reinterpret_cast
(except maybe casting null pointers). What you generally can do
is reinterpret_cast between types of the same size, and get the
bit pattern from one interpreted as if it were the other. What
that means is also rather implementation dependant, however.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34