From: already5chosen@yahoo.com   
      
   On Tue, 06 Jan 2026 17:59:33 GMT   
   MitchAlsup  wrote:   
      
   > Terje Mathisen  posted:   
   >   
   > > Michael S wrote:   
   > > > On Tue, 6 Jan 2026 12:35:20 +0100   
   > > > Terje Mathisen  wrote:   
   > > >   
   > > >> Thomas Koenig wrote:   
   > > >>> Michael S  schrieb:   
   > > >>>> On Sun, 4 Jan 2026 00:21:31 -0000 (UTC)   
   > > >>>> Thomas Koenig  wrote:   
   > > >>>>   
   > > >>>>>   
   > > >>>>> And two decimal flavors, as well, with binary and densely   
   > > >>>>> packed decimal encoding of the significand... it's a bit of a   
   > > >>>>> mess.   
   > > >>>>   
   > > >>>> Since both formats have exactly identical semantics, in theory   
   > > >>>> the mess is not worse (and not better) than two bytes orders   
   > > >>>> of IEEE binary FP.   
   > > >>>   
   > > >>> Almost.   
   > > >>>   
   > > >>> IIRC, there is no restriction on the binary mantissa, so its   
   > > >>> range is slightly larger for the same number of bits   
   > > >>> (1000/1024)**(n/3).   
   > > >>>   
   > > >> Sorry, that's wrong:   
   > > >>   
   > > >> Just like the 24 "spare" DPD patterns are illegal,   
   > > >   
   > > > Non-canonical, which is not the same as illegal   
   > > > Silently accepted as input operands but never produced as result.   
   > > >   
   > > >> any mantissa   
   > > >> corresponding to a number greater than the maximum allowed (1e34   
   > > >> afair) is also illegal, and there are rules for how to handle   
   > > >> both cases (without checking, i seem to remember that they   
   > > >> should be treated as zero?)   
   > > >>   
   > > >   
   > > > BID significand extension > max is indeed treated as zeros.   
   > > > Non-canonical DPD declets have non-zero values.   
   > > > They are forms of (8+c)*100 + (8+f)*10 + (8+i), where c, f, and i   
   > > > are in range [0:1].   
   > >   
   > > OK, that is probably because allowing them on input is   
   > > significantly faster/cheaper than having to detect and   
   > > modify/trap/erase.   
   >   
   > With the calculation latencies of IBM Z-series, modify/trap/erase is   
   > of no problem.   
   >   
      
   How do you know calculation latencies of IBM Z-series?   
   Did they made an information public?   
      
   > > That said, out of range mantissas could also have been accepted,   
   > > except they would not have had a valid conversion to either DPD or   
   > > ascii.   
   > >   
   > > Terje   
   > >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)