From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2006-05-16 11:56:38
Robert Ramey writes:
> 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.
> > 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.
OK, maybe you don't ever need to evaluate exp(-cost). You still might
like to know that the result of a previous operation produced an
Consider a program P that is part of a data processing chain. An
upstream component gets bad data, or does something bad, and produces
an Inf or NaN. P might need to pass that on to downstream
processors, or detect it and take appropriate action.
Or, consider an algorithm that might, occasionally, produce a
legitimate Inf. How do I detect this case? Do I check errorno? No,
that's error prone. Do I catch an exception? Only if the code that
generates the Inf throws one, and that might not be an option (think
threaded embedded systems where exceptions are banned). Probably, my
only good option is to check for Inf and do something appropriate.
If I need to pass the error-handling buck to a downstream process,
emitting an Inf is a perfectly acceptable thing to do.
> 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.
There are plenty of use cases in which a NaN or Inf, either passed in
from another process, or generated internally, is an expected and
perfectly normal and understandable thing to get.
> >>> 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.
Use case given above; the programs aren't broken, although they may
be, and frequently are, part of a processing chai that involves
_other_ programs that are broken. :-)
My $0.2. :-)
Dave Steffen, Ph.D. Fools ignore complexity.
Software Engineer IV Pragmatists suffer it.
Numerica Corporation Some can avoid it.
ph (970) 419-8343 x27 Geniuses remove it.
fax (970) 223-6797 -- Alan Perlis
dgsteffen at numerica dot us
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk