From: cr88192@gmail.com   
      
   On 11/7/2025 11:34 PM, Robert Finch wrote:   
   > >   
   >> Here is an example value:   
   >>    2DFFCC1AEB53B3FB_B4E262D0DAB5E680   
   >>   
   >    
   >   
   > I multiplied PI by 10^31 and ran it through the int to decimal-float   
   > converter. It should give the same sequence of digits although the   
   > exponent may be off.   
   >   
   > 2e078c2aeb53b3fbb4e262d0dab5e680   
   >   
   > The sequence of digits is the same, except it begins C2 instead of C1.   
   >   
      
   Does appear to work, mostly, but decodes as:   
      31425926535897932384626433832795.0   
      
   Well, except some of the digits don't match up with PI...   
      
   one of the examples from the prior post decodes as:   
      12345678.0   
      
      
   But, yeah, mostly getting consistency across multiple implementations   
   does imply that I have implemented the base format correctly.   
      
      
   As for use-case, this is less clear. It is likely to be slower than the   
   usual Binary128 format.   
      
   And, likewise, it would appear that BID is slightly more popular, though   
   both less common than people just rolling their own formats.   
      
   So, it looks like:   
      Boost, MongoDB, PyArrow: BID   
      Python, Java: Custom formats   
      .NET: Custom format.   
      
   Leaving mine, yours, and IBM's decNumber, as using DPD.   
      
   It looks like decNumber is using BCD internally.   
      Mine is using a "9 digits in 32-bit chunks" scheme.   
      
   In the case of the .NET format, it uses 9 digit chunks, so pretty   
   obvious it is probably using 9 digit chunks internally as well.   
      
      
   I left the BID code out of my example.   
      
   Partly as I realize the reason the BID case was coming out as basically   
   the same speed as DPD was because I was in-effect using DPD. If the BID   
   case were used, it is in effect somewhat slower than DPD.   
      
   It is more likely that for BID to be effective, it would need to be   
   implemented directly using 128-bit math (likely as its own thing).   
      
   I also had my experimental X30 variant, which can be slightly faster   
   than DPD, but seems the relative savings would be small. Though, the   
   cost estimates in my microbenchmarks are not showing consistent results.   
   It is looking like some sort of weirdness is going on.   
      
      
   Also the micro benchmarks don't test for values with varied levels of   
   normalization, which is likely to affect performance.   
      
   And, can note that it seems my code and decNumber was very different   
   regarding the handling of normalization.   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)