Lumber difficulties

[axch]

In defiance of IEEE 754, Python's math.log raises an exception instead of returning infinities or NaNs when given zero or negative arguments, respectively. Numpy's numpy.log chooses a useless middle way, namely raising a divide by zero warning. Venture, however, repeatedly needs to rely on the IEEE 754 behavior. As a consequence, the numeric code is a confusing mess of math.logs, numpy.logs, and the awkwardly named venture.lite.util.extendedLog (which does the wrong thing for negative arguments).

Plan:

• [ ] Fix the behavior of extendedLog on negative arguments (possibly by rewriting it in terms of numpy.log suppressing the warning, to gain the benefit of vectorization).
• [ ] Rename extendedLog to log.
• [ ] Use utils.log in preference to math.log or numpy.log throughout. (This can be enforced by static analysis (#528), e.g. by grepping for math.log, numpy.log, np.log, and imports of math or numpy under any other qualified names.)

Exponentiation is less common in Venture, but as math.exp has similar trouble (exception instead of infinity for large arguments), it may be reasonable to treat it analogously. careful_exp is as bad of a name as extendedLog.

The design conversation leading to this plan is recorded near the end of #154.

[riastradh-probcomp]

Possibly relevant consideration: numpy.log is 10x slower on my machine than math.log for a single point input (i.e., not vectorized over an array), as measured by timeit:

import timeit
def trial(setup, payload):
    n = 1000000
    times = timeit.timeit(stmt=payload, setup=setup, repeat=3, number=n)
    return sorted(times)[1]/n

>>> trial('import math', 'math.log(1)')
1.1860084533691406e-07
>>> trial('import numpy as np', 'np.log(1)')
1.2657721042633057e-06

Measuring performance with operands leading to infinities and NaNs -- by handling appropriate exceptions or adding conditionals, in the case of math.log -- is left as an exercise for the reader.