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:
>>>> I bash my head against the wall? :)
>>>
>>> Pamphlet -> http://en.wikipedia.org/wiki/IEEE_754-2008
>>>
>>> Popcorn, well, it's kinda hard to transmit over the wire. ;-)
>>
>> Easy to do with a modern email client - just needs support for POP3 and
>> a working firewall (for the heat). :-)
>
>LOL!
>
>>
>>> 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 $$$$). Unfortunately, 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. The 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. I
suppose you can call that "inadequate", but I don't see a good way
around it ... 0.6 is still infinite in binary. BigDecimal will get
you the right answer (unless you run out of memory), but when the
significant figures pile up it tends to get you there very slowly. All
the various arbitrary precision formats suffer badly performance wise.
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).
George