From: ThatWouldBeTelling@thevillage.com   
      
   MitchAlsup wrote:   
   > EricP  posted:   
   >   
   >> Terje Mathisen wrote:   
   >>> Anton Ertl wrote:   
   >>>> Terje Mathisen  writes:   
   >>>>   
   >>>>> This would have simplified all sorts of array/matrix sw where both   
   >>>>> errors (NaN) and missing (None) items are possible.   
   >>>> In what ways would None behave differently from SNaN?   
   >>> It would be transparently ignored in reductions, with zero overhead.   
   >> There is also the behavior with operators - how is it different from xNan?   
   >> xNan behaves like an error and poisons any calculation it is in,   
   >> which is also how SQL behaves wrt NULL values:   
   >>   
   >>    value + xNan => xNan   
   >>    value * xNan => xNan   
   >>   
   >> whereas Null is typically thought of as a missing value:   
   >>   
   >>    value + Null => value?   
   >>    value * Null => 0?   
   >>   
   >   
   > I think they would want::   
   >   
   >      value + xNaN  =>  xNaN   
   >      value × xNaN  =>  xNaN   
   >      value / xNaN  =>  xNaN   
   >      xNaN  / value =>  xNaN   
   >   
   > Where the non-existent operand is treated as turning the calculation   
   > into a copy of the xNaN. Some architectures put a payload into the   
   > xNaN such as a 3-bit code for why the xNaN was created, others also   
   > IP to help identify the instruction the xNaN first occurred.   
      
   That's how Nan propagation works now, to poison the calculation.   
   The Nan propagation rules were designed back when people thought   
   the using traps for fixing individual calculations was a good idea.   
   That way Nan could serve as either an error or missing value   
   and your exception handler could customize the behavior you want.   
      
   "6.2.3 NaN propagation   
   An operation that propagates a NaN operand to its result and has a single   
   NaN as an input should produce a NaN with the payload of the input NaN   
   if representable in the destination format.   
      
   If two or more inputs are NaN, then the payload of the resulting NaN   
   should be identical to the payload of one of the input NaNs if   
   representable in the destination format. This standard does not   
   specify which of the input NaNs will provide the payload."   
      
   Traps are expensive for pipelines, vectors, gpu's, so I'd want   
   None to behave differently - I'm just not sure what.   
   And I recognize (below) that there may be different ways that users   
   want None to behave so suggest there might be control bits to select   
   among multiple None behaviors on an each instruction.   
      
   >> It could also have different operator instruction options that select   
   >> different behaviors similar to rounding mode or exception handling bits.   
   >> All those option bits would take up a lot of instruction space.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)