Re: [boost] meta-double

From: Peder Holt (peder.holt_at_[hidden])
Date: 2005-06-12 13:45:33

On 6/12/05, David Abrahams <dave_at_[hidden]> wrote:
> Peder Holt <peder.holt_at_[hidden]> writes:
> 
> > On 6/11/05, David Abrahams <dave_at_[hidden]> wrote:
> >> Peder Holt <peder.holt_at_[hidden]> writes:
> >>
> >> > On 6/10/05, David Abrahams <dave_at_[hidden]> wrote:
> >> >> Peder Holt <peder.holt_at_[hidden]> writes:
> >> >>
> >> >> >> c.f. http://gcc.gnu.org/ml/gcc/2005-01/msg01744.html
> >> >> >> and the last two items here:
> >> >> >> http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Deprecated-Features.html#Deprecated-Features
> >> >> >
> >> >> > 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.
> >>
> >> The problem is that a < b is not a compile-time constant when a and b
> >> are floating.  If you use such comparisons internally to your library,
> >> it is nonportable.
> >
> > Ahh, but you have the same problem with a-b, or indeed with any
> > operation.
> 
> Is that right?  I guess I thought there was a loophole if you
> ultimately convert it to int.
> 
> > The only thing that compiles with comeau online in strict mode, is
> > long(a), where a is a double literal, and this doesn't do much good.
> 
> Not much, no.
> 
> > The building up of a double is nonportable, and I haven't tried to
> > tackle this problem.  So far, the only compilers I have tried that
> > did not accept operators on doubles to form compile time constants,
> > is Comeau in strict mode and Digital Mars.
> >
> > Borland, VC [6.5 ,8beta], GCC [?, 4.0.0> on the other hand,
> > accepts the syntax.
> >
> > It is probably possible to create a less elegant way to construct a
> > double_, not involving non-standard functionality.
> 
> I think you need to at least provide the option, for people who want to
> write portable code.

Definitely. I'll try to change the operators (times,plus etc.) to use
integral operations only.

> 
> It doesn't have to be all that ugly, you know.   Do you need more than
> 32 bits after the decimal point?
> 
>   double< 3,1415927 ,E<+6> >

Not bad. The double type does have 16 decimals precision. Is it an
option to use long long for the decimal part?

I discovered that using base 2 exponent in stead of base 10 exponent
gives you the same accuracy as with a regular double expression.
Is this an absolute requirement, or is an approximation to double sufficient?

Regards,
Peder

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