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

From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2006-05-16 11:41:52

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

> 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.  
It certainly is documented for Microsoft Visual C++ 8.0.  It so happens
that MS have chosen to describe an argument of -inf when passed to exp
as "invalid".  Other platforms will make other choices, and probably
document them.

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

Believe me, handling exceptional values when there is no route is the
LEAST of the validation problems.

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

No.  The algorithm detects that there is no movement of coal between the
two places and says the average cost is NaN.  If there /is/ movement,
then it works out the cost of each possible transport method, and
calculates the "average" cost as log( sum( exp(-cost) ) ).  (The strange
"average" is standard for this sort of modelling.  It ensures that
opening a new hyper-expensive route does not increase the average cost.)

> It is the core of my concern that the current system permits and
> encourages programs like this to be written.  
Which is a good thing.

> Of course they might
> work in some instances but I don't think that's a good argument
> for doing things this way.

I think that reflects your lack of experience of numerical modelling.

>> 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.
Fair enough :-)

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