From: cr88192@gmail.com   
      
   On 11/10/2025 1:16 AM, Terje Mathisen wrote:   
   > BGB wrote:   
   >> DIV uses Newton-Raphson   
   >> The process of converging is a lot more fiddly than with Binary FP.   
   >> Partly as the strategy for generating the initial guess is far less   
   >> accurate.   
   >>   
   >> So, it first uses a loop with hard-coded checks and scales to get it   
   >> in the general area, before then letting N-R take over. If the value   
   >> isn't close enough (seemingly +/- 25% or so), N-R flies off into space.   
   >>   
   >> Namely:   
   >>    Exponent is wrong:   
   >>      Scale by factors of 2 until correct;   
   >>    Off by more than 50%, scale by +/- 25%;   
   >>    Off by more than 25%, scale by +/- 12.5%;   
   >>    Else: Good enough, let normal N-R take over.   
   >   
   > My possibly naive idea would extract the top 9-15 digits from divisor   
   > and dividend, convert both to binary FP, do the division and convert back.   
   >   
   > That would reduce the NR step to two or three iterations, right?   
   >   
      
   After adding code to feed to convert to/from 'double', and using this   
   for initial reciprocal and square-root:   
      DIV gets around 50% faster:  ~ 1.5 MHz (~ 12x slower than MUL);   
      SQRT gets around 260% faster:  ~ 0.9 MHz (~ 22x slower than MUL);   
      
      
   Single-stepping in the debugger:   
      SQRT takes around 3 iterations.   
      
   With the initial worse estimates, it requires 7 iterations.   
      
   the iteration has a special case to stop once the adjustment would   
   effectively become too small to make a difference.   
      
   ...   
      
      
   Otherwise, it is possible I could add the fancy rounding modes.   
      
   Though, I can note that another library that uses this format also uses   
   funky normalization (primarily keeping numbers right aligned rather than   
   normalizing to left-alignment) which could effect the behavior of   
   rounding (it would nominally round to however many digits exist past the   
   decimal point in the ASCII strings it parses as input).   
      
      
   Though, it could be possible to add a feature to partly defeat the   
   floating-point behavior and behave as-if there were always at least N   
   digits above the decimal point (for normalization/rounding).   
      
   For example, if specifying that ADD should behave as-if there were 31   
   digits above the decimal point, then operations being rounded to having   
   3 digits below the decimal point.   
      
   This sort of behavior would likely need to be per-operation though.   
      
   Well, unless "how many digits exist past the decimal point in an ASCII   
   string representation" is itself a semantically important detail?...   
      
      
   For most contexts where it could matter, would expect setting a minimum   
   exponent to make more sense. Though, in these use-cases, not clear how   
   the added complexity (and overhead) if decimal floating-point could make   
   sense over using some sort of decimal fixed point scheme (such as   
   storing 64 or 128 bit integers with a fixed scale of 1000 or something).   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)