|
Boost : |
From: Peder Holt (peder.holt_at_[hidden])
Date: 2005-06-13 03:59:55
On 6/12/05, David Abrahams <dave_at_[hidden]> wrote:
> Peder Holt <peder.holt_at_[hidden]> writes:
>
> <snip>
>
> [Please try to limit the amount of quoted text in your postings]
Ok :)
> >>
> >> double< 3,1415927 ,E<+6> >
> >
One more problem:
It is not possible to write e.g. the number 3.00011 in the above notation:
double_<3,00011>
First of all, 00011 is interpreted as 9. Second, there is no way to
distinguish this from:
double_<3,9> (as I know of)
The alternatives would then be: double_<31415927,E<-7> > (which is
basically the same as what Andy does in his physical quantities
library)
DOUBLE(3,00011,E<0>) where 1 is temporarily prepended to 0001 to
preserve the preceding zeros.
Alternatively:
double_<3,DECIMALS(0001)> that has a default value for the exponent.
> > Not bad. The double type does have 16 decimals precision. Is it an
> > option to use long long for the decimal part?
>
> Only on compilers that support it. Again, that's a non-C++98 extension.
>
> > I discovered that using base 2 exponent in stead of base 10 exponent
>
> I don't understand what you mean her. Where is this exponent used?
> Does the user specify the exponent in base 2 (probably not)? YOu must
> mean in the representation?
I mean the representation. I just need to find the correct
transformation between the E<N> notation and the 2^M notation.
>
> > gives you the same accuracy as with a regular double expression.
>
>
> > Is this an absolute requirement,
> ^^^^
>
> a base 2 exponent or the same accuracy as a double?
this == same accuracy as double
>
> > or is an approximation to double sufficient?
>
> I don't know. Better ask your target audience!
> I'd guess they don't want an approximation, but I'm only guessing.
>
> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> _______________________________________________
> 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