From: cr88192@gmail.com   
      
   On 8/24/2025 10:53 AM, George Neuner wrote:   
   > On Sun, 24 Aug 2025 01:34:41 -0500, BGB  wrote:   
   >   
   >   
   >> If your math goes NaN, it means math was wrong.   
   >> But, if the math is not wrong, there are no NaN's.   
   >   
   > Not exactly.  A NaN result means that the computation has failed.  It   
   > may be due to limited precision or range rather than incorrect math.   
   >   
   > For most use cases, a result of INF or IND[*] similarly means the   
   > computation has failed and there is no point trying to continue.   
   >   
   > [*] IEEE 754-2008.   
      
   Yeah, pretty much.   
      
   As noted, what I was saying before probably should not have been taken   
   as arguing for a complete elimination of NaN or that the formats   
   themselves should change here...   
      
   Rather that NaN typically merely signals "Well, the math has broken";   
   and usually serves little role beyond this (apart from giving certain   
   JavaScript VMs a place to store their pointers; but if a JS VM were to   
   use an object pointer as an input to a computation, this itself is an   
   error condition).   
      
      
   Inf/NaN is usually at least more neutral (the dynamic range of Binary32   
   and Binary64 being so large, that losing one level doesn't cost much).   
      
   For Binary16, it is iffy (due to Binary16 having limited dynamic range).   
   For 8-bit formats, had already stated my stance here (only a single   
   optional NaN value exists).   
      
      
   Though, if I were to tweak Binary16 here, possibly might be:   
      Largest exponent becomes normal range again;   
      Inf/NaN is folded into the -0 range.   
      8000..81FF: Assume -0   
      8200..8201: +Inf/-Inf   
      8202..83FF: NaNs   
      
   But, debatable, as this sort of thing could create interoperability issues.   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)