
Boost : 
From: Robert Ramey (ramey_at_[hidden])
Date: 20060515 22:49:16
Guillaume Melquiond wrote:
> Le lundi 15 mai 2006 à 12:10 0700, Robert Ramey a écrit :
>> Peter Dimov wrote:
>>
>>> It depends. Where do you draw the line? Is inf a number? Is 0.0 a
>>> number? You have to have NaN if you want to be able to represent x/y
>>> as a float.
>>
>> That's the problem. x/y is not a valid operation if y is equal to
>> 0. So
>> it can't be represented as a number.
>>
>> The fact that C++ permits such an operation makes C++ different
>> than arithmetic. The fact that C++ uses operators like "/" and
>> defines them similar to  but not identical to  the way they are
>> defined by
>> standard arithmetic is the source of all these problems. I say
>> that C++ should be changed to so that the floats and operators which
>> apply to them should implement what people expect from arithmetic
>> operators.
>
> "Standard arithmetic" defines infinitely precise operators on real
> numbers. You cannot be seriously suggesting that C++ should stop using
> floatingpoint numbers and switch to such an arithmetic.
of course not.
> The C++ float type is a *floatingpoint* type and as such it obeys the
> rules of
> *floatingpoint* arithmetic. Whatever your expectations, you cannot do
> anything about the fact that floatingpoint numbers have a limited
> range
> and a limited precision. Because of those, they are unable to obey the
> rules of a standard arithmetic (whatever it is).
I don't expect undefined operations to produce results. That's what
most C++ implementations do. I expect that  as in "standard
arithmetic" I get some sort of exception when I invoke an undefined
operation. That's what my desk calculator does and it seems reasonable
to me. Much better than just returning a bogus value to be used
in the next operation.
Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk