GMP suggestions

[Marc Glisse]

On Fri, 21 May 2010, Nic Schraudolph wrote:

>> 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...

Oh, you are thinking of doing it at the C++ level? I thought you meant to 
do it at the C level.

>> 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 Inf.

I am not sure everybody would be happy with that (I haven't thought about 
it much).

>> 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 avoided.

This already works currently: is_bounded and has_infinity are false by 
default for types without an explicit specialization. You would need to 
see if there is anything useful to do with is_exact, is_integer or 
is_signed.

>> 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.

Probably.

> 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.

The code (typically in a library) may be type agnostic, but the numbers 
may come from another code that set the precision, or the user may change 
the default precision.