From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA06902 for caml-red; Sat, 14 Oct 2000 14:36:37 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA04514 for ; Sat, 14 Oct 2000 03:39:01 +0200 (MET DST) Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e9E1d0j23401 for ; Sat, 14 Oct 2000 03:39:00 +0200 (MET DST) Received: from dylan (dialup03ip039.tus.azstarnet.com [169.197.31.39]) by cepheus.azstarnet.com (8.9.3/8.9.3) with SMTP id SAA13326 for ; Fri, 13 Oct 2000 18:38:40 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <001201c03580$04423df0$210148bf@dylan> From: "David McClain" To: Subject: Re: Undefined evaluation order Date: Fri, 13 Oct 2000 18:42:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: weis@pauillac.inria.fr Dave Berry writes: > Are you saying that if (a * b) would result in a NaN >then you always want (a * b * 0.0) to return a NaN, so that you are aware > of the potential problem? Yes! That is indeed the case. This is what the IEEE floating point spec calls for. There are two kinds of Nan's -- signaling and non-signaling. The signaling ones can potentially raise an exception, while the non-signaling ones simply represent "Not-A-Number" values. One might use signaling Nan's to initialize arrays, in some languages (i.e., Fortran) so that one could catch the use of uninitialized variables... I don't really distinguish the two in most of my work... Indeed, on the Alpha architecture, you have to explicitly check for such errors by inserting trap barrier instructions into the instruction stream. Hence, all you can know is whether or not an exception has occured since the last time you checked. The IEEE floating point spec allows for this kind of behavior in the readily available FPU architectures as well (i.e., Pentium) Most of my work involves signal and image processing on vast collections of numbers, frequently in real-time environments. While the numerical analysts might like to know about Nan signaling to help them write more sophisticated (mathematical) function evaluators, nearly all of my math routines have to be quick and not so exacting. In physics and measurement environments we rarely have more than 3 significant digits in our data. Of course the work of Prof. William Kahan, UC Berkeley, shows the need to carry many more significant digits during intermediate calculations, but mathematical refinement is not generally our concern. As I mentioned previously, if an anomalous computation occurs in one or a few cases out of the billions that we stream then we just drop it (them) on the floor and keep running... - DM