Re: converting floating point types round off error ....
On Dec 14, 3:55 am, forums...@hotmail.com wrote:
On Dec 1, 4:55 am, James Kanze <james.ka...@gmail.com> wrote:
That's the way I usually do it:-). Strictly speaking, it's not
100% portable; for starters, you're not even guaranteed that
such an unsigned integral type exists. (There is, in fact, at
least one platform where it doesn't.) And even if it does,
there's no guarantee concerning the format of a float. For
maximum portability, you should define your serialized floating
point format, and play games with frexp and ldexp to create it.
uint32_t tmp ;
operator>>( tmp ) ; // shifts and or's...
Referencing your thread found here:
From the looks of it you're taking the contents of a stream
and parsing it accordingly. Now lets take the value 5.14245:
ie std::istringstream iss ( "5.14245" ) ;
Would it be safe to say that after the call to operator>> tmp* would
be equal to: 0x352e313432343500 ( which is the ASCII hex
representation for the value 5.14245)?
Certainly not. First, the operator cited above is part of an
ixdrstream, not an std::istream, so you couldn't even read a
istringstream with it. Second, it reads four bytes, not eight.
If the context of the input stream were the four bytes F3 8E A4
40, in that order, the variable tmp will contain 0xF38EA440
(regardless of the byte order of the input stream). And after
the appropriate manipulations, the float (not double) will
contain the the closest possible representation of 5.14245.
* I'm assuming 'ixdrstream& ixdrstream::operator>>(
GB_uint64_t& dest )' gets invoked.
Which won't happen if the type is uint32_t. (Or
GB_uint32_t---the GB_ is because for portability reasons, I
define my own, and need to avoid clashes. And the code predates
James Kanze (GABI Software) email:email@example.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