Hello James! On Wed, Mar 23, 2011 at 4:45 PM, James K Beard <[email protected]> wrote: > Excuse me, but isn't the representation of a number in BCD unique except for > some esoteric special cases?
Well, we could quibble about some specific details, but for the sake of this discussion, yes, let's take the BCD representation to be unique. (An aside here: I would distinguish between decimal floating-point representations in general, and BCD as a specific decimal floating-point representation. To me, a decimal floating-point number is an integer mantissa, and an integer exponent that represents scaling by powers of ten. (Likewise, a binary floating-point number is an integer mantissa and an integer exponent that represents scaling by powers of two. BCD, to me, is a specific decimal floating-point representation where the integer mantissa (and presumably the exponent, as well) is stored as a BCD (binary-coded decimal) integer, in which each decimal digit of the BCD integer is stored as a four-bit hexadecimal digit, with the restriction that only the values 0--9 are legal (i.e., A--F are illegal). Converting between BCD integers and binary integers isn't cheap because you have to unpack the decimal digits from the BCD integer, multiply them by powers of ten, and add them together to get the binary integer. The point is that regardless of the semantics -- what you call decimal or BCD -- there are two separate things going on here: how you store your integers (in BCD or binary), and the meaning of the exponent (powers of ten vs. powers of two). When I say decimal floating-point I mean that the exponent represents scaling by powers of ten, and am agnostic as to the specific representation of the integer mantissa and exponent that make up the floating-point number.) > Why wouldn't the conversion of a binary > floating point result give a correct result when converted to BCD? Perhaps > I'm being naïve here so please help me out here. The core reason is not that the conversion from binary floating-point to decimal floating-point isn't exact (It will be exact if the binary floating-point representation has less precision than the decimal floating point representation, and is not guaranteed to be exact if the binary representation has greater precision.), but rather that the conversion from decimal floating-point to binary floating-point is in general not exact. That was the point of my "(1/5 + 2/5) - 3/5" example. Once the inputs to the binary computation are not exact you risk the final decimal result not being exact, even if the binary computation and conversion back to decimal are exact. > BCD arithmetic - but not transcendental functions - are supported in > hardware in some machines that are designed for business applications. Ah, yes, decimal machines -- from back in the steam-powered era... > But, the speed and efficiency is in hardware binary floating point, which is > ubiquitously supported at 80 bits, including the trigonometric, log, and > exponential functions. Quad precision with just a few instructions that > exploit the 80-bit hardware is supported in most instruction sets and in GNU > libraries, and now in most if not all commercial C and Fortran compilers. > Without doing an operation or cycle count or timing experiments, it would > seem to me that a conversion to or from BCD and binary floating point would > be about the same as a single arithmetic operation, within a factor of two > or so. No, absent hardware support, the conversion is relatively costly. Converting BCD integers to binary integers is more than a few clock cycles or arithmetic operations, and even if you use binary integers, rather than BCD, for your mantissa and/or exponent, converting 300 in decimal floating-point (3 x 10^2) to binary floating-point (300 x 2^0) is also more than a few clock cycles or arithmetic operations. > As such the difference between computing any transcendental function > in BCD and converting a BCD input to binary floating point for hardware > computation and converting back to a unique or at least correct result is > vastly more efficient than any possible BCD library function, particularly > for trigonometric, log and exponential functions. For library functions > implemented as software such as the log gamma functions, you can leverage > the not inconsiderable effort needed to write and test these libraries. This I agree with. Certainly for elementary transcendental functions (often with hardware support), and special functions (generally in libraries), and probably even for division, I would expect conversion from decimal to binary, binary computation, followed by conversion back to decimal to be much cheaper than computation entirely using the decimal representation. But for the basic arithmetic operations (+, -, *, and possibly division) it's cheaper to do your arithmetic directly in the decimal representation. > > James K Beard Best. K. Frank > ... > -----Original Message----- > From: K. Frank [mailto:[email protected]] > Sent: Wednesday, March 23, 2011 2:49 PM > To: mingw64 > Subject: Re: [Mingw-w64-public] mingw-w64 Decimal Floating Point math > > Hi Jon and James! > > On Wed, Mar 23, 2011 at 12:45 PM, JonY <[email protected]> wrote: >> -----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. >>> ... >>> 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? > > I believe that this is a fully legitimate concern. > ... ------------------------------------------------------------------------------ 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
