Yes, you&#x27;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&#x27;re in a shell) with this at the top of your script:<p><pre><code>  import unum_config
  unum_config.e = 3
  unum_config.f = 9
</code></pre>
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.<p>The idea with unums is that  your program sees the unacceptable bounds, and recomputes with higher precision.<p>Comparing speeds is very unfair: one implementation is hardware which has received maybe $100B-worth of optimization over decades, the other is one guy&#x27;s python script.<p>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&#x27;s computing the largest possible value in that floating point scheme.