From: already5chosen@yahoo.com   
      
   On Sun, 24 Aug 2025 11:51:18 -0400   
   EricP  wrote:   
      
   > 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,   
      
   Exceptions themselves are inexpensive. Misuses of exceptions for 'fixup   
   and continue' antipattern are expensive.   
   Invalid Operand exception is the only IEEE-754 exception which I do not   
   find misdesigned* and even consider it potentially useful despite that   
   it never helped me in practice.   
      
   > 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)