Bug in C++ interface (comparison between rational and double)

[Marc Glisse]

On Tue, 3 Feb 2009, Roberto Bagnara wrote:

>>> The comparison between mpz_class and double works fine with +inf and
>>> -inf, while the comparison between mpq_class and double gives a floating
>>> point exception, due to inappropriate mpq_set_d call in eval 
>>> specialization.

> in the Parma Polyhedra Library, we provide numerical abstractions that
> are parametric with respect to several (extended) number families.
> This includes all the native integer and floating point types and
> GMP's integers and rationals, possibly augmented with special values
> for -inf, +inf and NaN.

Oh, so you extended gmp types with +-inf and NaN, that is interesting. Out 
of curiosity, how do you do that?

> On these numerical types, we provide several
> operations, including safe (modulo bugs) comparisons.  To implement
> those we of course rely on what (we believe) is provided by the
> underlying base type.

Ok, so your goal is primarily completeness and correctness for those 
extended types, this is a fine goal, I am all for it.

> In this case, we were spoiled by the fact that GMP supports
> comparisons between mpz and double via mpz_cmp_d (which can be called
> with an infinity).

Note that you still need to handle NaN separately (you could consider it 
another gmpxx bug that comparison (<,>,<=,>=) with NaN may do something 
other than return false).

> Without looking at the manual (tsk, tsk, ...)
> we assumed the same functionality was provided for mpq.  However,
> it seems there is no such a thing as mpq_cmp_d and, as you know,
> the implementation of this comparison in gmpxx.h is incorrect.

You could say that the interaction between gmpxx types and double is only 
guaranteed to work in the finite case and the bug is in the missing 
documentation of this feature. It feels unsatisfactory to be able to say 
z<d (for an infinite d) but have (z-d) crash the program... This would 
argue in favor of pushing the appropriate code to a library that augments 
the gmpxx types with +-Inf and NaN. Which doesn't mean this won't be done 
in gmp...

> I don't know if there is any plan to add mpq_cmp_d.

Looks to me like it would make sense (but as I said in a previous email, I 
am not the one who needs convincing).

-- 
Marc Glisse