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