From: Peder Holt (peder.holt_at_[hidden])
Date: 2005-09-25 12:31:50
On 9/25/05, Andy Little <andy_at_[hidden]> wrote:
> "Peder Holt" <peder.holt_at_[hidden]> wrote in message
> > What should we do about the accuracy of double_ operations?
> > The implementation of plus,minus,times and divide mimics the behaviour
> > of the runtime equivalent, double. This means that the mantissa is
> > trunkated from 61 to 52 bit for every fundamental operation. The
> > result of this, is that complex functions such as sine and exponential
> > will differ from their runtime counterpart, unless a specialization is
> > made for double_. The problem would disappear if we allow calculations
> > with double_ to be more accurate than calculations with double. Is
> > this a problem?
> There is neverending discussion on comp.lang.c++.mod regarding differences
> between runtime floats on various platforms. IMO this is an ideal opportunity to
> create a platform independent floating point type, IOW one with an exact length
> of mantissa and exponent specified and with a consistent policy on rounding
> etc. I think this is how it is done in Java though the only link I can find
> Other question is ... What sort of rounding do you use?
For multiplication and division operations:
If the 53'rd bit is 1, add 1 to the 52'nd bit.
Ignore extra bits, cutoff after the 52'nd bit.
This mimics the behaviour of the VC compilers.
> Also ... I'm assuming it is simple enough to program the length of mantissa and
To a certain extent...
I use two 32 bit integer types to represent the mantissa, and two bits
are lost to overflow control. The last bit is the hidden 1 that
preceeds the mantissa in the double representation. It is possible to
add more integers to represent the mantissa, but it would involve some
work to get it right. Certainly doable, though.
The exponent is much simpler, as I currently only use 11 bit out of 16
> By making them length adjustable you would be able to regain
> platform dependence via typedefs where required. thus providing the best of both
Not a bad idea :) Probably best to start with the run-time adjustable
floating point, then extend it to compile-time.
> Andy Little
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk