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

From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2006-05-16 04:19:19

----Original Message----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey Sent:
16 May 2006 03:43 To: boost_at_[hidden]
Subject: Re: [boost] Stream input and output of NaN and infinity

> Martin Bonner wrote:
>> -----Original Message-----
>> Robert Ramey wrote:
>> 
>>> 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.
>> "different than SOME arithmetics".  The arithmentic C++ (well,
>> actually IEEE) defines is a perfectly sensible 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
>> 
>> Granted.  It isn't the standard arithmetic.
>> 
>>> is the source of all these problems.
>> What problems?  (Apart from the extra work involved for authors of
>> libraries like serialization I mean!)
> 
> suppose that z = x * y generates a Nan or +Inf or whatever one some
> machine for some x and y.  Now z contains an undefined value which
> is used on some other operations which presumably result in other
> types of Nan's.  This behavior has the following problems:
> 
> a) it's undefined
But MANY implementations define the behaviour, and define it in a way
that is useful.

> b) it varies from machine to machine.  On some machines the hardware
> will trap an abort the program as it won't throw a C++ exception.
> Other machines will store some variety of Nan in the result

Right.  So if you need a maximally portable program you can't use NaN or
+/-Inf.  But many people /don't/ need a maximally portable program.  

> c) if it doesn't trap we're just massaging undefined values.
> d) we're getting some useless result but don't know it untill maybe
> later or many never.
> 
> How can any "real program" find this useful?  How can such a program
> not be "broken".  I suppose there might be some case where its OK
> but they would have to be special in some way.

I think what is special is that the authors would need to understand the
issues.

I used to work in transport modelling.  We used to model different types
of things (people, coal, food) travelling by different transport modes
(bus, truck, boat) between different places.

It makes perfect sense to talk about the cost of moving a ton of (eg)
food between two places by boat being +infinity (it implies there is no
boat route between the two places).  It doesn't hurt the algorithm,
because it will later assign the amount of food to be transported in
proportion to exp(-cost) ... and hence it won't try and transport any
food by boat.

It might also makes sense to talk about the cost of moving a ton of coal
between two places be NaN if there is no coal to move.

>>> 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.
> 
>> Yes, but realistically that is never going to happen.
> 
> LOL - it seems you're right there.  But that is not my point here.
> 
>> Wouldn't it be better to support the use-cases that people have in
>> real code?
> 
> well that's what we have to do.  But it raises the issue of whether
> its worth spending time to support programs that are most likely
> broken in any case.

You could EASILY extend that argument to say that you shouldn't support
floating point.  I would suggest that in the set of float-point programs
that want to use serialization the proportion of non-broken programs
will be HIGHER in the sub-set that want support for +/-Inf and NaN than
in the sub-set that don't want that support.

-- 
Martin Bonner
Martin.Bonner_at_[hidden]
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ,
ENGLAND Tel: [phone]