Tim H. wrote:
Michael W. Ryder wrote:
I can not see how you can say that 0.1 != 1/10. I tried looking up the
standard but the paper I looked at, about implementing the standard in a
language, made no mention of converting floating point numbers to
rational numbers.
Ruby uses binary numbers, not decimal numbers. In binary, 1/10 cannot be
represented exactly, just like 1/3 cannot be represented exactly in decimal.
But if I told you that 10 dimes does not equal $1 you would freak. I
know that computers do not normally represent fractional numbers
correctly, but part of that is the fault of the programmers and chip
designers opting for “good enough”. If all arithmetic on a computer was
done using something like BCD there would not be this problem. Agreed
that in the deep dark past using something like BCD was noticeably
slower but with the raw power available today, most of which is wasted
there is no reason to accept second or third best.
Anyway, there is no way for you, me, or a computer program to know if
0.1 is 1/10 or .999999999999999 or 1.00000000000001 so one can only
choose one and hope that it is the right choice. Personally, as someone
who works in business, I prefer the 1/10 solution as that is the way
they expect it in business. They do not want to see 10 * .1 equaling
.99999999 or 1.00000001, they have to see 1.
On May 27, 2008, at 11:24 AM, Michael W. Ryder wrote:
If all arithmetic on a computer was done using something like BCD
there would not be this problem
How would you exactly represent 1/3 in BCD?
///ark
Michael W. Ryder wrote:
I can not see how you can say that 0.1 != 1/10. I tried looking up the
standard but the paper I looked at, about implementing the standard in a
language, made no mention of converting floating point numbers to
rational numbers.
Ruby uses binary numbers, not decimal numbers. In binary, 1/10 cannot be
represented exactly, just like 1/3 cannot be represented exactly in
decimal.
On May 27, 2008, at 2:39 PM, Michael W. Ryder wrote:
I think we can agree that 1/3 * 9 = 3 exactly, not some
approximation.
we can, but it just pushes the problem back further when you re-
introduce irrational numbers like pi and systems that are, by
definition, approximations, like calculus. the reality is that any
computation system must handle approximations and handle them
well. IEEE floating point numbers are a useful way to do just that
for classes of problems that are larger than representing fractions.
regards.
a @ http://codeforpeople.com/
Michael W. Ryder wrote:
0.1 is 1/10 or .999999999999999 or 1.00000000000001 so one can only
choose one and hope that it is the right choice. Personally, as someone
who works in business, I prefer the 1/10 solution as that is the way
they expect it in business. They do not want to see 10 * .1 equaling
.99999999 or 1.00000001, they have to see 1.
I found this interesting paper “Performance Characterization of Decimal
Arithmetic in Commercial Java Workloads” here:
[IEEE Xplore Login]
I don’t have an account so I can’t read the paper, but I see this
interesting tidbit in the summary: “In this paper, we present detailed
performance characteristics and we conclude that, relative to total
application performance, the overhead of using software decimal
implementations is low, and at least from the point of view of these
workloads, there is insufficient performance justification to pursue
hardware solutions.”
Mark W. wrote:
On May 27, 2008, at 11:24 AM, Michael W. Ryder wrote:
If all arithmetic on a computer was done using something like BCD
there would not be this problem
How would you exactly represent 1/3 in BCD?
///ark
The same way that the current binary system represents the number or
numbers like pi, as an approximation. My point was that .1 is a real
number that can be accurately represented fairly simply using something
like BCD or rational numbers without having to worry about the
approximations and the corrections necessary in the current
representation.
My module to represent rational numbers will convert decimal numbers to
rationals without having to worry that it isn’t IEEE format. I am not
worried that it isn’t “correct” according to Computer Science thinking
as the program is for my learning. I think we can agree that 1/3 * 9 =
3 exactly, not some approximation.