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>.