[Edu-sig] Long floats?

[Tim Peters]

Kirby, I'm delighted you're having fun with Jurjen's Real class!  It is
indeed a hoot.

> ...
> I'm not familiar with the .pyar extension.  I renamed it
> to .py after downloading, and then, since hyphenated file
> names are problematic, I had to use a weird syntax for
> import, shown below.

If you read the top of the downloaded file, it says:

#! /usr/local/bin/python
# This is a Python archive; run through your Python to convert.
# Supports bit error detection using MD5 (if available).

That is, the downloaded file is a Python program that, when *executed*,
*creates* the files real.README and real.py.  So you should do something
like

    python real-accurate.py

from a command line to unpack the contents.  As part of unpacking, it
computes MD5 checksums to ensure that the download wasn't corrupted.  Jurjen
had a unique approach to things.  pyar files never caught on.

>  >>> __import__("real-accurate") # after changing extension to .py
>  real.README : written.
>  real.py : written.
>  <module 'real-accurate' from 'g:\python20\lib\real-accurate.py'>

That's another odd way to execute the file.  From now on you can *start*
with the next line:

>  >>> import real
>  >>> from real import *
>  >>> pi()
>  3.141592653589793238462643383279503+-2
>  >>> sqrt(5)
>  2.23606797749978969640917366873127+-2
>  >>> (1+sqrt(5))/2
>  1.61803398874989484820458683436564+-1
>  >>> pow((1+sqrt(5))/2,2)
>  2.61803398874989484820458683436564+-5
> ...

I'm not sure this is documented (it's been a while):  the module attribute
"default" controls how many digits are used by default.  So, for example,

>>> import real
>>> real.pi()
3.141592653589793238462643383279503+-2
>>> real.default = 10
>>> real.pi()
3.14159265358+-2
>>> real.default = 50
>>> real.pi()
3.141592653589793238462643383279502884197169399375105+-2
>>>

> ...
> Seems to be a powerful package.

Very, yes.  It also has surprises; for example,

>>> rep('pi() - pi()')
.000000000000000000000000000000000+-4
.00000000000000000000000000000000000000000000+-3
0.+-4e-59
0.+-3e-79
0.+-4e-105
0.+-3e-140
0.+-3e-187
0.+-3e-249
0.+-4e-332
0.+-4e-443
0.+-3e-591
0.+-4e-788
0.+-3e-1051
0.+-3e-1401
0.+-3e-1868
...

which isn't surprising, but

>>> pa('pi() - pi()')

will never print anything.  This will often happen when, for example, the
exact result is an exact integer (like 0!):  the error bounds keep getting
tighter as more precision is used, but no finite amount of precision
suffices to distinguish

4.00000000000000000000000000000000000000000000000 ...

from

3.99999999999999999999999999999999999999999999999 ...

So pa gets stuck, never sure what the first digit is.  And it's a provable
general result that *no* implementation of the constructive rules can always
be sure of the first result digit.  There are some very pretty results of
that nature; as another example, comparison of the constructive reals is
also uncomputable in general (for much the same reason:  is 3.999999... < 4?
it depends on whether that sequence of trailing 9s ever ends!  if it does,
we'll eventually discover that, but if it doesn't, we'll keep computing
forever).

> Fun, too (guess I must be a nerd, huh -- actually I prefer
> "geek" as an honorific).

Then I'm a nerd too -- well, I guess I was anyway <wink>.