Re: [boost] Stream input and output of NaN and infinity

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-16 12:34:24

Martin Bonner wrote:
> Robert Ramey wrote
>
>> Geoffrey Irving wrote:
>>> Arguing that 1/0 should crash because that's what happens in "math"
>>> is the same as arguing that 2*max_int should crash because that's
>>> what happens in math...unless you have modulo arithmetic.
>>
>> True - I would argue that as well
>
> Except that 2*max_int doesn't crash in mathematics.  If we are talking
> about the integers then then depending on /exactly/ which set of
> integers we are talking about, either there isn't a value 'max_int',
> or it is positive infinity (and doubling it leaves it unchanged).  If
> we are talking about modulo arithmetic, then doubling the largest
> possible integer is perfectly well defined - it's just that the
> result is smaller than the original value.

This is a little bit off the topic - but not toooo far.

>From "The C++ Programming Language" by Stroustrup page 122.

"This [example] will (eventually) try to increase i past the largest 
integer.
What happens is undefined, but typically the value "wraps around"
to a negative number"

Of course this is extremely common behavior and many programs
depend upon it.  Is this a good thing? Hmmm - I never questioned
it but now I'm beginning to wonder.  In some ways its even worse
than the situation with floating point as we get a value which is
indistinguishable from a legitimate integer and we lose the
"overflow" characterization.

Now I'm thinking we need "safe_integer" as well as "safe_float".

I can hear the screaming.

At the bottom of all this is really different ways of looking at what
we do when writing code.  There are at least two ways.

a) One can think of himself as writing a set of instructions for a machine
to execute to achieve a desired result.  To do this, one constantly keeps
in mind the fact that a real machine is going to execute the code and
is continually consious of things like overflows, Nan's etc.

b) Another way is to consider a programming language as a means
to express abstract ideas like mathmatics.  Here the programmer doesn't
think of the machine.  He defines the behavior of his program by
the composition of other components each of whose behavior is
well defined.  Its more like construction of a mathematical proof
rather than the construction of a machine.

C++ permits either view and there exist working programs which
reflect both views.  I would argue that a) would be more likely
to produce more fragil and less portable programs.  (Though they
might be faster). While b) would produce more robust and more
portable programs.  Actually b) seems these days to be reflected
in scripting languages which are considered "easier to use" because
(in my view) they don't really even support the view a).

One (literally) man's opinion.

Robert Ramey