I think the long term solution is to implement the decimal arithmetic keywords with an open mind. Special requirements, like extremely long decimal words (DECIMAL128 == 128 digits?????) may require multiple-precision arithmetic, which may be problematic because most compilers support up to quad precision floating point, which is 128 bits with 12 bits exponent and 116 bits mantissa, or about 35 decimal digits.
If financial calculations were all that was required, that would be enough for practical use, because overflow would be at 10^33 dollars/yen/pesos/yuan/whatever. Nothing in real-world finance requires more dynamic range. But, nothing in nature requires more than about 10^125, which is the ratio of the densities of intergalactic space and the interior of a neutron star, or the time in years for the universe to reach total heat death and an overall homogeneous thermal composition. That's why IEEE floating points overflow at 10^38 or, for more than 32 bits, 10^308. I have a multiple precision package that I use for personal work that, for software convenience and best speed, uses a signed 16-bit integer for the exponent and overflows at 10^9863. I've been thinking about releasing it under the GPL but there is a lot of code cleanup needed, and some core modules are from Numerical Recipes for Fortran 90 and will require another license that I haven't pursued. James K Beard -----Original Message----- From: JonY [mailto:[email protected]] Sent: Saturday, April 09, 2011 1:08 PM To: [email protected] Subject: Re: [Mingw-w64-public] mingw-w64 Decimal Floating Point math -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/9/2011 23:03, K. Frank wrote: > > What, then, would be the advantage of using decimal floating-point? > I don't really know the history or what people were thinking when they > built those early decimal floating-point systems, but there is a > (minor) advantage of having the numbers people work with on paper > being represented exactly. I have 1.2345 * 10^10, and > 7.6543 * 10^-12 written down on a piece of paper ad type them into my > decimal computer. They are represented exactly. Of course the sum > and product of these numbers is not represented exactly (with, say, > seven-digit floating-point), so any advantage of having used decimal > floating-point is minor. > > Decimal floating-point rarely buys you anything you really care about, > which is probably why almost all modern computers support binary > floating-point, but not decimal. > > This does raise the question that Ruben alluded to: Why might someone > bother with implementing a decimal floating-point package for the gcc > environment? It's a fair amount of work and rather tricky to do it > right, and if you don't do it right, there's no point to it. > Its part of the upcoming ISO/IEC TR 24732:2009. What you use it for, or whether you will use it or not is tangent to the issue. To give a proper explanation, binary floats doesn't give the proper machine epsilon for equivalent decimal float sizes. Sure, you can cover DECIMAL64 and lower with long doubles, but what happens for DECIMAL128? I am concerned about the correctness of its implementation, and its performance implications (runtime and precession), and/or trade-offs. Right now, I opted to just map things to use the long double, its wrong but its definitely something. I haven't really got into it since I am quite busy at the moment. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAk2gkmAACgkQp56AKe10wHc8rgCfYQX+bVEV2B73q8G9i/POkwvO fAAAnR7Qkk+M1apqMaQRmA1txNYvQ3OI =O1sJ -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
