On Wed, 02 Jul 2014 23:00:15 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>:
>
>>> >>> Rational(2).sqrt() * Rational(2).sqrt() == Rational(2)
>>> False
>>
>> Square root of 2 is not a rational number.
>
> Nobody said it was.
Your comment can be read as implying it. You stated:
[quote]
Even "arbitrary-precision" RATIONALS [emphasis added] would
suffer from the same problem
[end quote]
and then showed an invented example where you squared a NON-RATIONAL. By
the way, there's no need to use an invented example. Here is an actual
example:
py> import math
py> from fractions import Fraction
py> math.sqrt(Fraction(2))**2
2.0000000000000004
> It's just that even "arbitrary-precision" rational
> numbers wouldn't free you from the issues of floating-point numbers.
Hmmm, well, I wouldn't put it that way. I would put it that a rational
number class has problems of its own. A correct, non-buggy rational
number class does not suffer from most of the problems of floating point
numbers. For example, apart from x = 0, the following:
1/(1/x) == x
is always true in mathematics, and always true with a rational class, but
not always true with floating point:
py> x = 49.0
py> 1/(1/x) == x
False
py> x = Fraction(49)
py> 1/(1/x) == x
True
The specific problem you show, with sqrt, comes about because it takes
you outside of the rationals and into the floating point numbers.
> The Decimal number class won't do it, either, of course.
Decimals are floating point number, so they suffer from the same kind of
failures as other floating point numbers.
> On the other hand, floating-point numbers are perfect whenever you deal
> with science and measurement.
/head-desk
I'm sorry Marko, have you not being paying attention? Have you ever done
any numeric programming? Floating-point is *hard*, not "perfect". Even
*trivially simple* arithmetic problems can burn you, badly. Have you not
heard of catastrophic cancellation, or the Table Maker's Dilemma, or ill-
conditioned equations? If scientists don't have to worry about these
things (and they actually do), it's because the people writing the
scientific libraries have worried about them.
Almost every thing that most non-experts believe is true about doing
calculations on a computer is false -- including, I daresay, me. I'm sure
I've probably got some wrong ideas too. Or at least incomplete ones.
This page gives some examples:
http://introcs.cs.princeton.edu/java/91float/
including a calculation of the harmonic sum 1/1 + 1/2 + 1/3 + 1/4 + ...
Mathematically that sum diverges to infinity; numerically, it converges
to a fixed, finite value.
> And when you deal with business (= money),
> integers are the obvious choice.
Unfortunately there is nothing obvious about using integers. If you want
to represent $1.01, what could be more obvious than using 1.01? But
that's the *wrong solution*.
Unfortunately using integers for money is trickier than you may think. If
all you're doing is multiplying, adding and subtracting, then using 101
for $1.01 is fine. But as soon as you start doing division, percentages,
sales tax calculations, interest calculations, currency conversions,
etc., you've got a problem. How do you divide 107 cents by 3? If you just
truncate:
py> (107//3)*3
105
you've just lost two cents. If you round to the nearest whole number:
py> (round(107/3))*3
108
you've just invented a cent from thin air. Both answers are wrong.
Depending on your application, you may pick one or the other, but either
way, you have to care about rounding, and that's neither obvious nor easy.
> I would venture to say that the real applications for Decimal are very
> rare. In practice, I'm afraid, people with rather a weak understanding
> of numbers and computation might gravitate toward Decimal unnecessarily.
Financial applications are one of the real applications for Decimal. You
can think of Decimal numbers as an easy way to fake the use of integers,
without having to worry about moving the decimal point around or come up
with your own rounding modes.
py> from decimal import *
py> setcontext(Context(prec=3))
py> (Decimal("1.07")/3)*3
Decimal('1.07')
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
