From: gneuner2@comcast.net   
      
   On Wed, 27 Aug 2025 14:43:20 GMT, anton@mips.complang.tuwien.ac.at   
   (Anton Ertl) wrote:   
      
   >Terje Mathisen  writes:   
   >>They don't even need to be full 8-bit: With a tiny amount of logic to=20   
   >>handle the signs you are already down to 128x128, right?   
   >   
   >With exponential representation, say with base 2^(1/4) (range   
   >0.000018-55109 for exponents -63 to +63, and factor 1.19 between   
   >consecutive numbers), if the absolutely smaller number is smaller by a   
   >fixed amount in exponential representation (14 for our base 2^(1/4)   
   >numbers), adding or subtracting it won't make a difference.  Which   
   >means that we need a 14*15/2=105 entry table (with 8-bit results) for   
   >addition and a table with the same size for subtraction, and a little   
   >logic for handling the cases where the numbers are too different or 0,   
   >or, if supported, +/-Inf or NaN (which reduce the range a little).   
   >   
   >If you want such a representation with finer-grained resolution, you   
   >get a smaller range and need larger tables.  E.g., if you want to have   
   >a granularity as good as the minimum granularity of FP with 3-bit   
   >mantissa (with hidden 1), i.e., 1.125, you need 2^(1/6), with a   
   >granularity of 1.122 and a range 0.00069-1448; adding or subtracting a   
   >number where the representation is 25 smaller makes no difference, so   
   >the table sizes are 25*26/2=325 entries.  Still looks relatively   
   >cheap.   
   >   
   >Why are people going for something FP-like instead of exponential   
   >if the number of bits is so small?   
   >   
   >- anton   
      
   Excellant question. Wish I had an answer.   
      
   Given that the use case almost invariably is NN, the only interesting   
   values are [or should be] fractions in the range 0 to 1.  Little/no   
   need for floating point.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)