Boost logo

Boost Users :

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-30 14:02:37


on Fri Aug 29 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> Just to keep the pot boiling - here's my two cents.
>
> a) Basically, floats can be represent as two integers.
> One for the exponent and one for a normalized fraction
> of one.
>
> b) The C standard library provides functions which
> generate these two integers from any double (frexp)
> and retrieves the origninal double from the pair
> of integers(ldexp). I would guess that these functions
> are pretty efficient as they only return a subset of
> some existing bits.
>
> c) the portable binary archive currently in the libraries
> handles integers in a portable manner. It has been
> tested on various platforms and already addresses
> issues such as what to do when on attempts to load
> an integer > 2^32 to a 32 bit machine. It also
> strips leading bits which don't add anything and makes
> the archives smaller.
>
> It would seem using the standard functions - supported
> by any standard C library - and using the functionality
> already in portable_binary_archive, one could add
> floating point functionality relatively easily - and it
> would be no less portable than the C library is.

I wonder if it really works so well when the word size of the machines
differs, or even when the word size is 32 bits on both ends. It's
likely they're both using IEE754, so if long double has more than 32
bits of mantissa, your method will be needlessly lossy. I think long
double commonly has 96 or 128 bits total, so you'd lose significant
precision. The HPC community has had to solve this problem numerous
times. These are people that care about the accuracy of their floating
point numbers. Why one would begin anywhere other than with the formats
the HPC people have already developed is beyond me.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net