GMP suggestions

[Nic Schraudolph]

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

Oops, you're right, it should all be at the C level. Perhaps I was  
overly intimidated.

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

I agree, but again it's a case of something being better than  
nothing... I'll give it a try and report back if/when I have something  
worthwhile.

> 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. (Yes, my code snippet didn't guard for  
this, but it really should have... :-)

> You would need to see if there is anything useful to do with  
> is_exact, is_integer or is_signed.

The code I'm converting already uses the macro "#define IS_INT  
(Type(1)/2 == 0)" as a workaround for is_integer, improperly as this  
relies on rounding properties which may differ for custom types. It  
uses the same macro as a stand-in for is_exact, which only works  
because the built-in integer types are exact while the non-integer  
ones aren't. That's 2 out of 3 right there. 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.

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

Best,

- nic