[continued from previous message]   
      
   > difficulty getting it to give the correct answer. Integer divide was   
   > tending to overshoot the "A goes into B N times" logic, and trying to   
   > fudge it (eg, but adding 1 to the initial divisor) wasn't really   
   > working; kinda need an accurate answer here, and a reliable way to   
   > scale and add the divisor, ...   
   >   
   >   
   > Granted, one possibility could be to expand out each group of 9   
   > digits to 64 bits, so effectively it has an intermediate 10 decimal   
   > digits of headroom (or two 10e9 "digits").   
   >   
   > But, yeah, long-division is a lot more of a PITA than N-R or   
   > shift-and-subtract.   
   >   
   >   
      
   I am not totally sure what you mean by 'long division', 'N-R' and   
   'shift-and-subtract'. In my view, they are not really distinct. Shades   
   of gray, rather than black-and-white.   
   Without experimentation, I'd recommend something similar to what Terje   
   suggested - calculate approximate reciprocal with 52-bit precision (by   
   FP_DP division), then do 3 iterations. You can call them as you   
   like, all three names above apply.   
   I am not sure that it is the fastest method. It is possible, that it   
   is better to improve reciprocal initially to 62-63 bits and then proceed   
   with 2 iterations instead of 3.   
   I *am* sure that the difference in speed between two variants is not   
   dramatic and that both of them ALOT faster than what you are doing   
   today.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)