Boost logo

Boost :

From: Peder Holt (peder.holt_at_[hidden])
Date: 2005-06-11 00:41:32

On 6/10/05, David Abrahams <dave_at_[hidden]> wrote:
> Peder Holt <peder.holt_at_[hidden]> writes:
> >> c.f.
> >> and the last two items here:
> >>
> >
> > Oh, well. Anyway, I have now uploaded a version of this to the vault:
> >
> > that is mpl-compliant and supports comparison and arithmetics with the
> > same accuracy as normal double arithmetics. Does not support NaN.
> Does it get around the comparison problem somehow?
> I think the results when a floating point value is converted to an
> integral that can't represent it are undefined (or something similar)
> but at least most compilers won't stop you. You might try to do some
> awful thing like transforming
> a < b
> into
> long(b - a) > 0

I am not quite sure I understand the problem correctly. What I do is
the following:

So the comparison is not a very big problem.

If you absolutely don't want to evaluate the double expression, you
would have to do something like:
if N1::exp < N2::exp then true
if N1::exp > N2::exp then false
if N1::decimals1 < N2::decimals then true
if N1::decimals1 > N2::decimals then false
if N1::decimals2 < N2::decimals then true
if N1::decimals2 > N2::decimals then false

Same goes for addition and subtraction, and arguably also multiplication.
I am not sure how to avoid double-evaluation in division, but it is
probably possible.

But, on the other hand, if you are talking about tolerances, I have
not implemented any support for a rounding-error tolerant version of
compare, I just mimic the behaviour of double.


> --
> Dave Abrahams
> Boost Consulting
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at