GMP suggestions

Marc Glisse marc.glisse at
Sun May 23 23:10:30 CEST 2010

On Sun, 23 May 2010, Nic Schraudolph wrote:

>> This already works currently: is_bounded and has_infinity are false by 
>> default for types without an explicit specialization.
> No. Without explicit specialization, is_specialized is false, which implies 
> that the correct interpretation should be "unknown" for all other 
> numeric_limits info.

In your code snippet, you only care about true vs "not known to be true", 
so unknown or false are equivalent, and unknown happens to imply the thing 
is set to false :-)

> And given how easy it would be to supply numeric_limits info, I don't think 
> the "usefulness" hurdle should be set all that high here.

Ok. (note that I am not currently a gmp developer)

>>> 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.
> Sure. Again, it's a case of doing the best we can do, given the interface 
> provided by numeric_limits. If some code assumes that numeric_limits will 
> always return the same answers for the same type, well that's simply not true 
> for mpf: nothing we can do about that. The best answer we can give is "if at 
> this time you create this numeric type with a standard (zero or one built-in 
> numerical argument) constructor, it will have the following properties". This 
> will work for code ignorant of GMP, which is the only kind of code that does 
> need this information.

The C++0X standard says that the information provided by numeric_limits 
has to be compile-time constants. The situation is clear for digits, less 
so for min/max/epsilon/round_error (constants don't really make sense for 
a complex type like mpf_class).

C++03 is much less restrictive and I believe it would allow your idea 
(not for digits, obviously, but at least for min/...).

Besides, I am not sure specifying is_bounded=true for mpf is a good idea 
(on the other hand, if there was an infinity, I'd be all for providing it 
in numeric_limits).

More information about the gmp-discuss mailing list