# 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:
>

> >> and the last two items here:

> >
> > Oh, well. Anyway, I have now uploaded a version of this to the vault:
> > metamath.zip
> > 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:
BOOST_STATIC_CONSTANT(bool,value=(BOOST_DOUBLE_EVAL(N1)<BOOST_DOUBLE_EVAL(N2)));

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
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.

Regards,
Peder.

> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>