Yes, 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-runni

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