From: user5857@newsgrouper.org.invalid   
      
   EricP  posted:   
      
   > Thomas Koenig wrote:   
   > > Kent Dickey  schrieb:   
   > >   
   > >> This is my point: I don't see a great way to encode the first NaN, which   
   > >> is why I propose not making that a goal.  You're not getting the first   
   > >> NaN in any case even if you try to do so in hardware, since the order of   
   > >> operations is a fragile thing that's hard to control unless you write   
   > >> assembly code, or the most tedious source code imaginable.   
   > >   
   > > Using Fortran, parentheses have to be honored.  If you write   
   > >   
   > >  A = (B + C) + (D + E)   
   > >   
   > > then B + C and D + E  have to be calculated before the total sum.   
   > > If you write   
   > >   
   > >   A = B + (C + (D + E))   
   > >   
   > > then you prescribe the order completetely.   
   > >   
   > > I can imagine source code that is much more tedious than this :-)   
   >   
   > That doesn't control which variable is assigned to each source operand.   
   > If both operands were Nan's and the two-Nan-rule was "always take src1"   
   > then the choice of which to propagate would still be non-deterministic.   
   >   
      
   In addition, the compiler is still allowed to perform the FORTRAN   
   equation as::   
      
       A = (C + B) + (E + D)   
      
   instead of the way expressed in ASCII.   
      
   Parenthesis order calculations not operands.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)