reconsider Unum units package

[1fish2]

PR #423 adds a temporary monkey-patch to the unum units package to fix a bug -- the Unum class doesn't implement true-division when the Python 2 caller has from __future__ import division.

See the Unum bug report.

That bug impedes Python 3 compatibility which is a necessary step for switching to Python 3.

• If they fix the bug, then drop the monkey-patch.
• Eventually we should reconsider whether to stick with unum, find a replacement package, fork it and make fixes, or start fresh perhaps borrowing from a units package in another language. Unum's API is unclear and various operations make copies which make me wonder if they're slow (do they copy the ndarray value or just the Unum?).

The comment at the top of its main source file __init__.py reads:

# TODO: consider alternatives to unum and see how they compare.

[1fish2]

Merging in what Eran wrote in #439:

This issue follows up on some recent conversations with @prismofeverything and @heejochoi about our units package, unum. #426 mentions that unum is no longer maintained, and is incompatible with Python 3.

There are additional behaviors that make it less-than-desirable. These include:

• units are given to each value in an array, rather than the array itself. This becomes costly as the arrays are passed around.
• units aren't saved in our listeners
• there are various non-commutative operations that lead to strange units. We need better handling of conversions.

That being said, I appreciate having units available as much as possible, so I do not want to simply remove unum. Maybe we can modify unum to fit our needs, or write our own units package.

Additional details:

• unum had changes in 2018 but no responses yet to my bug report, so we don't know for sure that it's unmaintained. We could email its last author.
• unum ought to be compatible with Python 3 (where / is always truediv). It's not compatible with from __future__ import division in Python 2 (except with the monkey-patch in #423; we should be able to drop that after dropping Python 2).
• Yes, it is non-commutative. What happens with array elements depends on the order:

  >>> np.arange(5) * units.m
  array([0 [m], 1 [m], 2 [m], 3 [m], 4 [m]], dtype=object)  # you don't want that
  >>> units.m * np.arange(5)
  [0 1 2 3 4] [m]

• Some of its operations appear to copy the value, but does it copy the np.array or just the Unum that wraps the np.array?
• Saving units in our listeners in every table row would probably cost a lot of space and time. Saving units in a table attribute would be lighter weight. TableWriter could convert every row to unit-less numbers at the scale of those units.
• Saving units in the pickled Parca output doesn't seem like a good thing.
• We still have the question of whether to fork it, find a replacement, or write something new.

[1fish2]

The original unum source code project is no longer online at https://pypi.org/project/Unum/ . The pip is still in PyPI.

There is a fork at https://github.com/trzemecki/Unum

The project should probably switch to pint==0.16.1 as used in Vivarium. requirements.txt already has Pint==0.14.