3 ms·
Hi, thanks for sharing your implementation. Am I totally misusing (py)unum? Using pyunum, repeatedly rotate the point (1,0) by 45 degrees. Print out the X co
by jepler 10y ago
Hi, thanks for sharing your implementation. Am I totally misusing (py)unum?
Using pyunum, repeatedly rotate the point (1,0) by 45 degrees. Print out the X coordinate every 8 rotations. Mathematically, the value printed each time should be exactly 1. Unfortunately, after just 79 iterations, the unum covers the range (-27352064, 27352064)! This includes the correct result but is useless.
A similar program using Python floats (i.e., platform doubles) prints 0.9999999999999937 at step 79 and runs in 1/540 of the time on my oldish core2 notebook. (or 0.9999999999371962 at step 799999 in less than 1/10 of the time of the 79 unum steps)
from unum import *
a = divideu(x2u(1), sqrtu(x2u(2)))
x, y = x2u(1), x2u(0)
for i in range(80):
x, y = timesu(minusu(x, y), a), timesu(plusu(x, y), a)
if i % 8 == 7: print i, view(x)
- AlexCoventry 10y agoYes, you're misusing the concept, and pyunum makes it hard to use in this situation (probably because the author had a different purpose in mind.) Try re-running (in a fresh python invocation if you're in a shell) with this at the top of your script: import unum_config unum_config.e = 3 unum_config.f = 9 This gives 2^3=8 bits for the exponent, and 2^9=512 bits for the fraction. The default values for e and f are 3 (8 bits) and 4 (16 bits) respectively. The idea with unums is that your program sees the unacceptable bounds, and recomputes with higher precision. Comparing speeds is very unfair: one implementation is hardware which has received maybe $100B-worth of optimization over decades, the other is one guy's python script. In this implementation, 9 seems to be the maximum value for f: if I set it to 10 unum fails to import because it tries to divide a float by too large an integer. And 4 seems to be the maximum practical value for e. At e=5, initialization of unum takes over two minutes and 250M of memory, probably because it's computing the largest possible value in that floating point scheme.
- muizelaar 10y agoYes. My intention with pyunum was to match the Mathematica code as much as was reasonable so that it's possible to follow the code samples in the book without requiring Mathematica. The result is unpythonic and very slow but should be usable for experimenting with the semantics of unums. It would certainly be nice to have more pythonic port.
- jepler 10y agoAh, I can see that I wouldn't necessarily get a very good result if I'm actually doing calculations with a 16-bit mantissa.