GMP suggestions

Nic Schraudolph nic at
Fri May 21 17:06:37 CEST 2010

Hi Marc,

thanks for your response!

> Basically, TG thinks the overhead of having an infinity (and the  
> effort to add one) is too large. I guess you could try to convince  
> him if you wrote a prototype implementation and ran some benchmarks.

I might give that a shot though I doubt my C++ is up to it...

> Note that if you have infinity, you also need NaN for the result of  
> Inf-Inf or 0*Inf.

Not necessarily - it may be acceptable to throw an exception for such  
expressions instead, analogous to division by zero when you don't have  

> What kind of information would you want from numeric_limits? It  
> could tell you that radix=2, is_signed, is_integer for mpz but not  
> the others, is_exact for mpz and mpq but not mpf, !has_infinity, ! 
> is_bounded, !is_modulo and not much more.

Sure. It may seem trivial but just these few bits of information can  
be very useful to application code striving to be compatible with any  
reasonable numeric class. For instance, I can use

vector<Type> vector;

const Type upper_bound(numeric_limits<Type>::is_bounded ?  
numeric_limits<Type>::max() :
     (numeric_limits<Type>::has_infinity ?  
numeric_limits<Type>::infinity() :
     *max_element(vector.begin(), vector.end())));

to upper-bound the elements of a (potentially very large) vector  
without having to calculate the max of its elements, if that can be  

> Things like digits don't fit in an int (or if you want to make them  
> fit, it is radix that won't fit anymore).

It should be clear to an application that precision resp. range- 
related information is irrelevant for types that that state that they  
are exact resp. unbounded. For mpf, range information can be given,  
and it may also be useful to communicate the current default precision  
here: numeric_limits is intended for code agnostic to the underlying  
numerical type, and such code will be ignorant of the additional  
precision parameter to mpf_class constructors anyway - so the default  
precision is what's relevant.

I agree that the numeric_limits interface is not a particularly good  
match for the GMP classes, but I see it as a case of anything being  
better than nothing...

Best regards,

- nic

More information about the gmp-discuss mailing list