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

Subject: Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-06-28 08:09:47

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.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com