You don't need to go to BCD to convert DFP to IEEE (regular) floating point. A single arithmetic operation directly in DFP will exceed what you do to convert to IEEE floating point. I would use double precision for anything up to 12 decimals of accuracy, 80-bit for another three, and simply incorporate the quad precision libraries with credit (or by reference, if differences in licensing are a problem) for distribution.
Anything other than binary representation will be less efficient in terms of accuracy provided by a given number of bits. By illustration, base 10 requires four bits, but provides only 3.32 bits (log2(10)) per digit of accuracy. The only relief from this fundamental fact is use of less bits for the exponent, and in IEEE floating point the size of the exponent field is minimized just about to the point of diminishing returns (problems requiring workaround in areas such as determinants, series and large polynomials) to begin with. James K Beard -----Original Message----- From: Jon [mailto:[email protected]] On Behalf Of JonY Sent: Wednesday, March 23, 2011 12:45 PM To: [email protected] Cc: [email protected] Subject: Re: mingw-w64 Decimal Floating Point math -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/23/2011 22:06, James K Beard wrote: > Jon: The simplest and quite possibly the most efficient way to > implement a standard function library in BCD decimal arithmetic is to > convert to IEEE standard double precision (or, if necessary, quad > precision), use the existing libraries, and convert back to BCD decimal floating point format. > The binary floating point will have more accuracy, thus providing a > few guard bits for the process, and hardware arithmetic (even quad > precision is supported by hardware because the preserved carry fields > make quad precision simple to support and allow good efficiency) is > hard to match with software floating point, which is what any BCD decimal arithmetic would be. > > James K Beard > Hi, Thanks for the reply. To my understanding, converting DFP to BCD then IEEE float and back again seems to defeat the purpose using decimal floating points where exact representation is needed, I'm not too clear about this part. Will calculations suffer from inexact representation? According to the range of DECIMAL128, we do need quad precision. Looks like GCC does support quad precision via libquadmath, but its LGPL, so no suitable to be included directly. Kai, any inputs on the hardware arithmetic part? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAk2KI6gACgkQp56AKe10wHdGQACeNHQ/VnBqvGxvlHtdD2zYLrHl XGQAoIgvfcPYB90V2ULPGiQP72rZElbj =l/kw -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
