nic at schraudolph.org
Sun May 23 20:52:02 CEST 2010
> 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
>>> 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
> 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
> 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.
More information about the gmp-discuss