Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-30 16:35:51

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/30/2010 11:45 AM, Peter Dimov wrote:

>> Which is only a problem if you're doing something that produces a NaN.
>> In XInt, that's rare, and all such cases are very carefully documented.
> 
> Right. What is the purpose of the NaN? Its function is to delay the
> exception until the first use of the result, making the point of the
> erroneous calculation harder to trace. In what scenario is this a good
> thing?

If you ignore NaN results from functions that return them, then yes,
that is the result. If you use them properly, and check for NaN as soon
as a function that can return it returns, you will know the exact line
that it came from. In what scenario is this a bad thing?

>>> (*) And by the way, out of memory is not overflow. It's possible to run
>>> out of memory while computing an integer that is smaller than another
>>> integer that already has been computed. This is not what overflow means.
>>
>> If that was aimed at XInt, note its purpose: it's intended to allow
>> calculation with numbers of arbitrary length, up to the memory size of
>> the system. If the system can't provide enough memory for it at some
>> point, that *is* an overflow -- the number is too large to represent.
> 
> No, it isn't an overflow. An overflow doesn't occur at random, depending
> on some external resource. Overflows are deterministic and depend on the
> fixed range of the number. A 32 bit signed integer always overflows at
> 2^31. If a calculation produces a number X without overflowing, that
> same calculation, when performed again, will still produce X without
> overflowing. This is not true for out of memory conditions. Arguing that
> making a copy of a number can overflow is stranger still.

I'm sorry you don't see the logic behind it. I do, and n1744 (the
"standardese" for the large-integer library proposal) specifies it, on
page two: "all integer operations which return an (temporary) integer
and many member operators may fail due to insufficient memory. Such
errors are reported as overflow_error exceptions (as available memory
defines the range of the integer class)."

As such, I'll need a much stronger reason than that to change it.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuyYKMACgkQp9x9jeZ9/wR1+gCePQwHET1YkVjsZ6O83WRnP4Ty
6TgAnA4kN0ghFxfzIBURGVCNR9KXF4xo
=J5H+
-----END PGP SIGNATURE-----