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.
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.
I don't know what BOOST_DOUBLE_EVAL does, so that is opaque to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com