Basically, if you make the base 10 arithmetic work for its only real user
base - financial applications - there is no problem in base 10 I/O and
binary in the innards, and that's the way it's been done since the early
1960's or so. If you want to impose drastic word length and overflow
requirements on it then you will require an extended precision package. An
extended precision package that does binary arithmetic inside and converts
to and from decimal representations on I/O will be far faster and easier to
maintain because it leverages binary hardware, and that's what I recommend
if you really need to do that.
To understand what I perceive to be the user base of consequence for decimal
arithmetic, browse the Wikipedia page on COBOL:
http://en.wikipedia.org/wiki/COBOL
In particular, scroll down to the table of COBOL data types:
http://en.wikipedia.org/wiki/COBOL#Data_types
Note that the only decimal data types are fixed-point decimal up to 18
digits, requiring a maximum of 80 bits to store packed or 144 bytes to store
one-byte-per-digit. It's designated by the declaration modifier [PACKED
DECIMAL] or [USAGE DISPLAY], indicating it's for I/O. All the other numeric
data types are binary 16 bits, 32 bits, or 64 bits fixed or floating point.
If that perspective is at all valid, we are going far overboard imagining
requirements to support super-astronomic overflow limits and vast word
lengths. That community needs 18 digits fixed point, which can be held in
64-bit integers. I see no need for decimal floating point anywhere in the
COBOL world.
James K Beard
-----Original Message-----
From: dashesy [mailto:[email protected]]
Sent: Saturday, April 09, 2011 4:36 PM
To: [email protected]
Subject: Re: [Mingw-w64-public] mingw-w64 Decimal Floating Point math
> Hi,
>
> Sorry for jumping into this discussion, but I don't seem to understand
what
> the advantage is of a non-hardware supported real number representation.
If
> you need the two (or a bit more) decimal places required for currency and
> percentages, why not just use a big integer and for display divide by 100?
> No more worries about precision, up to an arbitrarily determined number of
> decimal places. Are the numbers so huge that they can't be stored in a
> 128-bit integer, or are there stricter requirements precision-wise?
Thanks!
>
> Ruben
>
> Op 9 apr. 2011 15:16 schreef "K. Frank" <[email protected]> het
volgende:
>> Hello NightStrike!
>>
>> On Sat, Apr 9, 2011 at 2:41 AM, NightStrike <[email protected]>
wrote:
>>> On Sun, Apr 3, 2011 at 7:07 AM, James K Beard <[email protected]>
>>> wrote:
>>>> A quick glance through the document seems to tell us that the decimal
>>>> arithmetic will incorporate checks to ensure that any rounding in
binary
>>>> floating point does not compromise the accuracy of the final decimal
>>>> result.
>>>> ...
>>>
>>> I'm being a little OT here, but I'm curious.. does that mean that
>>> COBOL was a language that gave very high accuracy compared to C of the
>>> day?
>>>
>>
>> No, COBOL, by virtue of using decimal arithmetic, would not have been
more
>> accurate than C using binary floating-point, but rather
>> "differently"accurate.
>> (This, of course, is only true if you make an apples-to-apples
comparison.
>> If you use 64-bit decimal floating-point -- call this double precision
>> -- this will
>> be much more accurate than 32-bit single-precision binary floating-
point,
>> and, of course, double-precision binary floating-point will be much more
>> accurate than single-precision decimal floating-;point.)
>>
>> That is, the set of real numbers that can be represented exactly as
>> decimal
>> floating-point numbers is different than the set of exactly representable
>> binary
>> floating-point numbers.
>>
>> Let me illustrate this with an approximate example -- I won't get the
>> exact
>> numbers and details of the floating-point representation correct, but the
>> core idea is spot-on right.
>>
>> Compare using three decimal digits (0 -- 999; 10^3 = 1000) with ten
binary
>> digits (0 -- 1023; 2^10 = 1024), essentially the same accuracy.
>>
>> Consider the two real numbers:
>>
>> 1 - 1/100 = 0.99 = 99 ^ 10^-2, an exact decimal floating-point
>>
>> 1 - 1/128 = 0.1111111 (binary) = 127 * 2^-7, an exact binary
>> floating-point
>>
>> The first, 1 - 1/100, is not exactly representable in binary, because
>> 1/100 = 1 / (2^2 * 5^2), and you can't represent fractional (negative)
>> powers of five exactly in binary.
>>
>> The second, 1 - 1/128, is not exactly representable in decimal,
>> because we are only using three decimal digits.
>>
>> 1/128 = 0.0078125 (exact),
>>
>> so
>>
>> 1 - 1/128 = 0.9921875 (exact)
>>
>> If we give ourselves seven decimal digits, we can represent
>> 1 - 1/128 exactly, but that wouldn't be an apples-to-apples
>> comparison.
>>
>> The best we can do with our three-decimal-digit decimal
>> floating-point is
>>
>> 1 - 128 ~= 0.992 = 992 * 10^-3 (approximate)
>>
>> This shows that neither decimal nor binary is more accurate, but
>> simply that they are different. If it is important that you can
>> represent things like 1/100 exactly, use decimal, but if you want
>> to represent things like 1/128 exactly, use binary.
>>
>> (In practice, for the same word size, binary is somewhat more
>> accurate, because in decimal a single decimal digit is usually
>> stored in four bits, wasting the difference between a decimal
>> digit and a hexadecimal (0 -- 15) digit. Also, you can trade off
>> accuracy for range by moving bits from the mantissa to the
>> exponent.)
>>
>> Happy Hacking!
>>
Can this new feature maybe used for fixed point arithmetic? For some
hardware it might be advantageous because floating point
implementation is not supported or is costly.
This new addition might somehow make the libraries more standard (?),
but the real advantage would be to have the math library work with it
(does it now?).
dashesy
>>
>> K. Frank
>>
>>
>>
----------------------------------------------------------------------------
--
>> 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
>
>
----------------------------------------------------------------------------
--
> 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
>
>
----------------------------------------------------------------------------
--
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
------------------------------------------------------------------------------
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
