On 6/12/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/11/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> writes:
On 6/10/05, David Abrahams <dave@boost-consulting.com> wrote:
Peder Holt <peder.holt@gmail.com> 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#Depreca...
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