nic at schraudolph.org
Fri May 21 17:06:37 CEST 2010
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
const Type upper_bound(numeric_limits<Type>::is_bounded ?
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...
More information about the gmp-discuss