inf & nan for mpq

Marc Glisse marc.glisse at inria.fr
Sun May 30 22:24:07 CEST 2010


( you want TG's opinion, I am just answering to pass the time ;-)

On Sat, 29 May 2010, Nic Schraudolph wrote:

> The implementation is complete, covering all mpq_* functions, including 
> mpq_set_* and mpq_get_*. The predicates mpq_equal, mpq_sgn, and mpq_cmp 
> always return zero if any argument is nan, with the sole exception that 
> mpq_equal(nan, nan) = 1. This is in keeping with standard floating-point 
> implementations in which all boolean predicates except is_nan() return false 
> if any argument is nan. (The alternative would be to raise an exception such 
> as GMP_ERROR_INVALID_ARGUMENT.)

You say mpq_equal(nan,nan) returns true, but for type double, nan==nan 
returns false.

sgn and cmp don't make much sense for nan, so a convention like 0 sounds 
ok to me. There is code out there that relies on sgn(x)==0 being 
equivalent to x==0, but then that code also relies on x being finite... 
Not sure how much introducing inf and nan may confuse existing code.
By the way, with your patch, how does one test whether x==0? Creating a 
mpq to store 0 sounds like a waste, but sgn(x)==0 must now come with 
!isnan(x) (yes, 3-valued comparison doesn't match well with nan).

You seem to have forgotten at least cmp_ui (I wouldn't have commented, but 
you are calling the implementation "complete").

The C++ wrapper would need modifications so that any comparison involving 
NaN returns false.

You would probably want extra functions like mpq_isfinite, in a second 
step.

> I benchmarked this on two programs: the big chunk of C++ code I've been 
> converting to use mpq_class, and a simple little C program (bbp.c, attached) 
> that uses the BBP formula (naively) to calculate pi. I cannot detect any 
> significant difference in speed in either case.

I guess a relevant benchmark would involve only small numbers (say one or 
two limbs each), since that's where the overhead might be noticable. Yes, 
that is a common use for mpq (though possibly not what it is best suited 
for).

-- 
Marc Glisse


More information about the gmp-discuss mailing list