Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Gregory Ewing Newsgroups: comp.lang.python Subject: Re: float("nan") in set or as key Date: Fri, 03 Jun 2011 11:17:17 +1200 Lines: 39 Message-ID: <94qjvvFb02U1@mid.individual.net> References: <94dkd3F7k4U1@mid.individual.net> <4de1e3e7$0$2195$742ec2ed@news.sonic.net> <4de22007$0$29996$c3e8da3$5496439d@news.astraweb.com> <4de2d746$0$29996$c3e8da3$5496439d@news.astraweb.com> <4de75dd5$0$29983$c3e8da3$5496439d@news.astraweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net cn2MwQhZgFtKgsGkTen5/wbSlrBYi6QujStAOUfgVISUheGvkP Cancel-Lock: sha1:Gzuz7X4pK2jea+j9cyAocJ0W6gw= User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711) X-Accept-Language: en-us, en In-Reply-To: <4de75dd5$0$29983$c3e8da3$5496439d@news.astraweb.com> Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:6894 Steven D'Aprano wrote: > def kronecker(x, y): > if x == y: return 1 > return 0 > > This will correctly consume NAN arguments. If either x or y is a NAN, it > will return 0. I'm far from convinced that this result is "correct". For one thing, the Kronecker delta is defined on integers, not reals, so expecting it to deal with NaNs at all is nonsensical. For another, this function as written is numerically suspect, since it relies on comparing floats for exact equality. But the most serious problem is, given that > NAN is a sentinel for an invalid operation. NAN + NAN returns a NAN > because it is an invalid operation, if kronecker(NaN, x) or kronecker(x, Nan) returns anything other than NaN or some other sentinel value, then you've *lost* the information that an invalid operation occurred somewhere earlier in the computation. You can't get a valid result from data produced by an invalid computation. Garbage in, garbage out. > not because NANs are magical goop that spoil everything they touch. But that's exactly how the *have* to behave if they truly indicate an invalid operation. SQL has been mentioned in relation to all this. It's worth noting that the result of comparing something to NULL in SQL is *not* true or false -- it's NULL! -- Greg