From: tkoenig@netcologne.de   
      
   Robert Finch  schrieb:   
   > On 2025-11-11 4:18 p.m., Thomas Koenig wrote:   
   >> Robert Finch  schrieb:   
   >>> Typical process for NaN boxing is to set the high order bits of the   
   >>> value which causes the value to appear to be a NaN at higher precision.   
   >>> I have been thinking about using some of the high order bits of the NaN   
   >>> (eg bits 32 to 51) to indicate the precision of the boxed value. This   
   >>> would allow detection of the use of a lower precision value in   
   >>> arithmetic. Suppose a convert from single to double precision is being   
   >>> done, but the value to be converted is only half precision.   
   >>   
   >> Do you mean a type mismatch, a conversion, or digits lost due to   
   >> cancellation?   
   >   
   > It would be an input type mismatch. >   
      
   I think this can only happen when software is buggy; compilers should   
   deal with it, unless the user intentionally accesses data with   
   the wrong type.   
      
   >>> If it were   
   >>> indicated by the NaN software might be able to fix the result.   
   >>   
   >> Fixing a result after an NaN has occurred is too late, I think.   
   >>   
   > I suppose the float package could always just automatically upgrade the   
   > precision from lower to higher when it goes to do the calculation. But   
   > maybe with a trace warning. It would be able to if the precision were   
   > indicated in the NaN.   
      
   I have implemented a few warning about conversions in gfortran.   
   For example, -Wconversion-extra gives you, for the program   
      
   program main   
     print *,0.3333333333   
   end program main   
      
   the warning   
      
       2 |   print *,0.3333333333   
         |                      1   
   Warning: Non-significant digits in 'REAL(4)' number at (1), maybe incorrect   
   KIND [-Wconversion-extra]   
      
   But my favorite is   
      
       3 |   print *,a**(3/5)   
         |               1   
   Warning: Integer division truncated to constant '0' at (1) [-Winteger-division]   
      
   which (presumably) has caught that particular idiom in a few codes.   
   --   
   This USENET posting was made without artificial intelligence,   
   artificial impertinence, artificial arrogance, artificial stupidity,   
   artificial flavorings or artificial colorants.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)