Path: csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 14 May 2011 18:58:45 -0500
Message-ID: <4DCF1735.9050107@SPAM.comp-arch.net>
Date: Sat, 14 May 2011 16:58:45 -0700
From: "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net>
Reply-To: andy@SPAM.comp-arch.net
Organization: comp-arch.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Computer arithmetic problems worth exploring
References: <ikaggo$mi2$1@gosset.csi.cam.ac.uk> <4DCCA37C.6090505@SPAM.comp-arch.net> <iqir93$r64$1@gosset.csi.cam.ac.uk> <5afv98-e0u2.ln1@ntp6.tmsw.no> <iqj0va$ss2$1@gosset.csi.cam.ac.uk> <4a613763-70c7-4a66-aa75-7ce3476cddd3@x10g2000yqj.googlegroups.com>
In-Reply-To: <4a613763-70c7-4a66-aa75-7ce3476cddd3@x10g2000yqj.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 53
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-SWodNfeY6gj4gijEQspwdM4wfEc4vDy6uJasiAdMxHmX9Ap6RQRiSlBkhxnR4Hi2bGL+70fVZHZQ/g6!PxfxK8aTtziIC6/Kbh6Z8Bvdxt2s9GZxnmrGKBkUVvP11/nW2xyKhpSufvtF
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3072
Xref: x330-a1.tempe.blueboxinc.net comp.arch:1577

On 5/13/2011 8:57 AM, MitchAlsup wrote:
> On May 13, 5:25 am, n...@cam.ac.uk wrote:
>> In article<5afv98-e0u2....@ntp6.tmsw.no>,
>>> Afair the idiom of "if ((0<  x) || (0>= x)) {" has been used in a bit
>>> of code to determine that (x) is a regular number, not a NaN. It does of
>>> course depend on both comparisons to fail when x is indeed NaN.
>>
>> Yes, they have.  That's not the point.
>
> It seems to me that the inherent problem, here, is ::
>
> "What is to be the effect of comparing things that are incomparable"?
>
> Perhaps one should resurect the old FORTRAN IF and add a 4'th lable
>
> 100  IF(X.NE.Y) 1,2,3,4
>
> Where the 4'th label is delivered control if the operands are
> incomparible.
>
> This seems to be at least as much a language issue as a HW
> computational issue.
>
> Mitch

My thinking along this line is that if you an ordered comparison of 
NaNs, then it should fault.

E.g.  if(x>y){... should fault if either x or y is a NaN.

You should say if(isnan(x)){...}else if(isnan(y)){...}else if( x<y) {...

But, there are many idioms such as Terje mentioned: !(x<0||x>=0).
Deprecated compiler switch.

I also like the symbolic notations  ?>?, ?>, >?,
which are read as if( lhs is nan or greater than rhs ), etc.

Methinks also, if serious, then the FP compare should be a bitmask:

LT
EQ
GT
isnan(lhs)
isnan(rhs)

although I expect the usual attempts to

a) reduce the bits in the bitmask by arguing that certain combinations
are meaningless

b) complicate it by adding not and and and or combinations relating to 
the nans