marc.glisse at inria.fr
Sat May 22 11:33:44 CEST 2010
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
>> 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
>> 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.
> 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.
More information about the gmp-discuss