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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-16 10:56:36

Martin Bonner wrote:
>>> Robert Ramey wrote:

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

Ahhh - at last a short, concrete, believable scenario.

so now we're evalating exp(-cost) where cost might be +Inf.  How
do you know what the exp function does in such a case?  Is it defined?
documented? etc.  I can't see how the result of such a program can
be trusted - even if one is not concerned about portability.  How does
one check such a result? Is it just assumed to be right if it looks 
reasonable?
I don't know.

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

so our algorithm calculates the cost 0 tons of coal of moving from point a 
to point b
(for which there is no route) with the expression exp(-Inf) * Nan and 
compares it
to other floating point numbers and branches accordingly.

It is the core of my concern that the current system permits and encourages
programs like this to be written.  Of course they might work in some 
instances
but I don't think that's a good argument for doing things this way.

>>> 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 don't see how I could do that.

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

That's where we disagree.

Robert Ramey