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-25 21:03:52

On 6/25/2012 4:10 AM, John Maddock 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.

The problem from the end-user's POV is that when different backends do 
different things the end user has to be aware of the backend 
implementation and take action accordingly. This complicates generic use 
of your library somewhat for an end-user.

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

I think choosing division by zero as an example was flawed as Steven 
pointed out. My general point is that the library should strive to 
provide compile-time alternatives which would regularize any differences 
in backends as much as possible. Of course if this comes at the cost of 
numeric interoperability and ease of use, I would be against any such 
regularization. But I think that the individual cases should be 
considered carefully.