bob gailer wrote:
It is not crucial here - but you must recognize that your program uses floating
point numbers, which almost always are an approximation to the
"real" value.
For example (assuming decimal numbers):
>>> 4/3.0
1.3333333333333333 (followed by an unending number of 0's).
Actually no, it is not followed by an unending number of zeroes. That
would imply that floats had infinite precision, but 4/3.0 was merely
calculated inaccurately. That's not the case: floats have a finite
precision, but are (or at least, should be) accurate to within the
limitations of that precision.
The exact value for 4.0/3 is actually:
1.3333333333333332593184650249895639717578887939453125
which is the closest possible binary fraction to 4/3.
The "real" value of 4/3.0 is 1 followed by an unending number of 3's.
Each successive fraction's floating point value will be "off" by some relatively
small value. Those errors will probably add up.
Another limitation of floating point numbers is that there is a maximum and a
minimum exponent. Eventually the fractions will be too small to convert to
float, raising an overflow exception.
I don't think you need to worry about that. It takes a pretty big
denominator before overflow will occur: a googol won't do it:
>>> 4.0/10**100
4.0000000000000001e-100
Even though the series given is very slow to converge (3000000 terms is
only accurate to 6 decimal places), I expect that it will converge
before the terms overflow. It might take many hours or days of
processing though.
Allof this raises the question - what computer algorithms successively
approximate pi exactly?
Er, by definition you can't APPROXIMATE something EXACTLY. But see here
for more approximations to π
http://en.wikipedia.org/wiki/Approximations_of_%CF%80
--
Steven
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
