From: already5chosen@yahoo.com   
      
   On Sun, 04 Jan 2026 08:06:50 GMT   
   anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:   
      
   > John Levine  writes:   
   > >Software implmentations of DFP would be slow, but if you know what   
   > >you are doing you can get the correctly rounded declmal results   
   > >using BFP which I would think would be faster.   
   >   
   > If you know what you are doing, you use fixed point for those   
   > financial applications which DFP targets, because that's what finance   
   > used in the old days, and what they laid down in their rules (and   
   > still do; the Euro conversion (early 2000s) has to happen with 4   
   > decimal digits after the decimal point; which is noted as unusual,   
   > apparently 2 or 3 digits are more common).  And whenever I bring that   
   > up, it is explained to me that DFP actually behaves like fixed point.   
   > Which leads to the question why one would use DFP rather than fixed   
   > point.   
   >   
      
   DFP behaves as fixed point for as long as it has enough digits in   
   significand to behave as fixed point.   
   It could use up all digits rather quickly   
   - when you sum up very big number with very small number   
     hopefully it does not happen in finances, big numbers  there are not   
     really big and small numbers are not really small.   
   - when you multiply, esp. several times   
   - when you divide. If result is inexact then just one division is enough   
      
   At this point, if you want it to continue to behave as fixed point, you   
   have to manually apply operation called quantize, which typically would   
   cause rounding to lower precision.   
   Or, may be, some languages can do it automatically. But I don't know   
   which languages it would be.   
      
      
   If the language is 'C' and compiler is gcc then on POWER one can apply   
   quantize op manually via __builtin_dfp_quantize() family of built-ins.   
      
   I have no idea how one can do it on other gcc targets. It does not look   
   like gcc provides __builtin_bid_quantize(). If it exists, manual does   
   not mention it.   
   Then again. gcc manual mentions very few details about Decimal FP   
   support. It look like work on Decimal FP was started ~10 years ago,   
   made progress for a year or two and them an interest was lost.   
      
   > In the bad old days of 16-bit processors, using the 64-bit mantissa of   
   > 80-bit BFP as a large integer may have provided an advantage, but   
   > these days we have 64-bit integers, and 80-bit BFP is slower than   
   > 64-bit BFP with 53-bit mantissa, so I don't see a reason to use any FP   
   > for financial calculations.   
   >   
   > Concerning the question of how much DFP is used: My impression is that   
   > Intel's DFP implementation is not particularly efficient,   
      
   If gcc implementation is based on Intel's then my measurements posted   
   here few weeks ago certainly agree, esp. for multiplication.   
   Disclaimer:   
   I only measured operations with 34 significant digits. It is possible   
   that this implementation is optimized for cases with significantly   
   smaller number of digits.   
      
   > and it sees   
   > no maintenance.  And I have not read about other implementations.  My   
   > guess is that there is so little use of this library that nobody   
   > bothers working on it, and the use that it sees is not in   
   > performance-critical code, so nobody works on making Intel's   
   > implementation faster or making another, faster implementation.   
   >   
   > - anton   
      
   An absence of easily accessible quantize operations seems to hints that   
   gcc implementation has no production use at all.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)