Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)

Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: Edward Diener (eldiener_at_[hidden])
Date: 2012-06-28 20:02:27

On 6/28/2012 8:09 AM, Dave Abrahams wrote:
>
> on Mon Jun 25 2012, John Maddock <boost.regex-AT-virgin.net> wrote:
>
>>>> As a single example of this the gmp_int backend triggers a division by 0
>>>> signal when one tries to divide the integer by 0; the tom_int raises a
>>>> hardward signal with a division by 0; the cpp_int throws a
>>>> std::runtime_error with a division by 0. I would like to see some means
>>>> by which I could use any integer backend and know that a
>>>> std::runtime_error would be thrown by a division by 0.
>>>
>>> IMO, you should just avoid division by zero period.
>>> As far as C++ itself is concerned, division by 0
>>> is undefined behavior, so any code that wants to
>>> handle any numeric type including builtins can't
>>> assume anything about division by zero.
>>
>> True, but.... I have some sympathy for Edwards POV, and we could be
>> more newbie friendly in that area.
>>
>> My original thought was "don't second guess the backend" - in other
>> words let the backend just do whatever it does for each operation, and
>> not try to manhandle different backends towards the same behavior.
>> However, on reflection, division by zero is relatively cheap to test
>> for compared to a full division anyway, so we could check that
>> particular case (or add an extra template param to the backend I
>> guess).
>
> Not only that, but not everybody is writing platform-independent code,
> and this goes double for people involved in HPC.  A long-running
> calculation that goes down because of divide-by-zero can be extremely
> expensive.  A nod should be given toward ways of handling these issues.

I did not want to focus on just divide by zero. I wanted to suggest that 
any anomalies between backends using the same general type be normalized 
as much as it is possible to do effectively in order to promote generic 
use of the backend.

As a further example the doc for the cpp_int type says:

"Construction from a string that contains invalid non-numeric characters 
results in a std::runtime_error being thrown. "

I do not see any mention if this is the case for gmp_int and/or tom_int. 
If it is not the same then a programmer constructing an mp_number using 
a cpp_int_backend<> which passes a string potentially containing an 
invalid non_numeric character must handled the mp_number constructor 
differently than when constructing using a gmp_int or a tom_int backend. 
But ideally one wants to choose any effective backend and then have all 
functionality be consistently the same and hopefully equally as correct 
as possible. My point is simply that I believe the library should 
normalize ( or "regularize" ) any differences as much as possible as 
long as this does not affect the accuracy ( and perhaps speed ) of the 
library. Of course there are always tradeoffs but a generic library 
should always work to minimize differences wherever possible.