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

Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2012-06-25 09:56:13

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

FYI, Several years ago, implementing a Runge Kutta integrator and 
solver, we found that removing the explicit divide by zero check and 
relying on the hardware signal to propagate as an exception gave a 40 - 
60% performance improvement. Though, I'm not sure how that translates to 
today's hardware/compilers and data types used.

Jeff