Open axch opened 8 years ago
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.
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'snumpy.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 ofmath.log
s,numpy.log
s, and the awkwardly namedventure.lite.util.extendedLog
(which does the wrong thing for negative arguments).Plan:
extendedLog
on negative arguments (possibly by rewriting it in terms ofnumpy.log
suppressing the warning, to gain the benefit of vectorization).extendedLog
tolog
.utils.log
in preference tomath.log
ornumpy.log
throughout. (This can be enforced by static analysis (#528), e.g. by grepping formath.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 asextendedLog
.The design conversation leading to this plan is recorded near the end of #154.