[PPL-devel] Bug in C++ interface (comparison between rational and double)
gmp-bugs.gmplib.org at os.tgape.org
Sun Feb 8 17:25:11 CET 2009
On Fri, 6 Feb 2009, Abramo Bagnara wrote:
> For mpz we overload the _mp_size field using MININT for -inf, MAXINT
> for +inf and MININT+1 for NaN.
> For mpq we use -N/0 for -inf, +N/0 for +inf and 0/0 for NaN.
> For both to check for special values is very fast as it can be done
> only testing the sizes and the overwriting of such special values is
> always safe inside gmplib.
> IMHO a performance critical application like gmplib should reduce the
> handling of special cases in unavoidable paths to the minimum (as
> probably they are not needed for many users). We have done the same
> thing in the PPL adding a templatic policy argument to our numeric
> classes where it's specified if the user code expects special values
> treatment or not.
Just to add a new opinion to the discussion...
If it is possible to check for all special cases with a single test (for
example, the mpq situation above allows for a single test against the
size of the denominator), it is probably reasonable to test for the
special cases, despite the performance needs. Under this case, the
normal flow is only distracted for the smallest possible time, for any
number of special cases.
If one needs to make one check per special case (for example, the mpz
situation above), it is probably not reasonable. If performance is
paramount, one should consider a possible redesign which would enable a
single test to enter all of the special case code. For example, maybe
have the sentinal value be the _mp_size field holding the MININT value
(since, in two's compliment, negative has one extra value), and use
either _mp_alloc or _mp_d to differentiate between the special cases.
It may be that inf and NaN are something that few applications
encounter. They are certainly more rare than in IEEE floating point, as
it's much harder to overflow a mpz than it is to overflow a double.
However, any maths that involve dividing relatively big numbers by
relatively little ones can do it, and programming tricks can only delay
that, not eliminate it. Even mpf math can evaluate to infinite and NaN
If my jumping into the middle of this discussion with my first post
offends anyone, I appologize. I'm new to gmp, but I'm not new to
performance-critical programming. A friend of mine recently asked me
for some assistance with some scientific programming he's working on,
and so I ended up here.
More information about the gmp-bugs