On Sat, 31 Oct 2009 12:48:28 -0500, Christopher Dicely
<cmdicely / gmail.com> wrote:

>On Fri, Oct 30, 2009 at 11:40 PM, George Neuner <gneuner2 / comcast.net> wrote:
>> On Wed, 28 Oct 2009 14:30:21 -0500, Marnen Laibow-Koser
>> <marnen / marnen.org> wrote:
>>
>>>Robert Klemme wrote:
>>>> On 28.10.2009 19:21, Matthew K. Williams wrote:
>>>>> As a rule of thumb, if you really care about the decimals, either use
>>>>> BigDecimal or integers (and keep track of where the decimal should be --
>>>>> this is common for $$$$). nfortunately, this is not limited to ruby,
>>>>> either -- C, Java, and a host of other languages all are subject.
>>>>
>>>> Absolutely: this is a common issue in *all* programming languages which
>>>> are not systems for symbolic math (like Mathematica) because they do not
>>>> work with real numbers but just rational numbers.
>>>
>>>That is not the issue here -- after all, BigDecimal does precise
>>>arithmetic, but only with rational numbers. he issue is rather that
>>>IEEE 754 does an inadequate job of representing arbitrary rational
>>>numbers, and the small errors are accumulated and magnified in
>>>calculations.
>>
>> The problem is that the 754 representation has finite precision.
>
>Well, the problem isn't that. The problem is that the IEEE 754 (1985)
>provides only binary floating point representations, when many common
>problem domains deal almost exclusively with values that have finite
>(and short) exact representations in base 10, which may or may not
>have finite representations in base 2. IEEE 754 (2008) addresses this
>with decimal floating point representations and operations. As
>IEEE-754 (2008) is implemented more widely, it will be less likely
>that arbitrary precision decimal  libraries with poor performance will
>be needed to do simple tasks that don't require many (base-10) digits
>of precision, but do require precise calculations with base-10
>numbers.

True, but my point is that the base conversion is not necessarily the
source of the imprecision.  The base 10 number may, in fact, have a
finite base 2 representation which does not happen to fit into any
available hardware format.

With respect to 754(2008), I do not know of any CPU manufacturer which
as plans to implement the decimal formats in hardware.  There is a
couple of CPUs which already have binary128 (and most are expected
to), and AMD has announced support for binary16 ... but, so far, no
one is talking about decimal anything.

However, use of the 754 bit formats does not mean that the standard is
being followed with respect to functionality.


>> It's also worth noting that most floating point hardware is not
>> anywhere close to 754 compliant even though most FPUs do use the
>> standard number formats (at least for single and double precision).
>
>AFAIK, neither IEEE 754 (1985) nor IEEE 754 (2008) requires that an
>implementation be pure-hardware,and essentially-complete
>implementations of IEEE 754 (1985) existed before it was a standard,
>and complete implementations of both IEEE 754 (1985) and IEEE 754
>(2008) exist now, including both pure-hardware and hardware+software
>implementations of both.

Again true, the standard does not specify where the functions are to
be implemented ... Apple's SANE, for example, was a pure software
implementation, Intel's x87 and SSE are the closest to being pure
hardware implementations.  

However, most CPUs that use 754 number bit formats do not implement
their functionality according to the standard.  Although some
functions can be implemented in software, certain things - in
particular rounding and denormalization handling - cannot be 'fixed'
by software to be standard conforming if the underlying hardware does
not cooperate.

George