Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ENH: Root finding #417
Hi @jstac, in this PR @spvdchachan and I added in the Jitted Newton methods for root finding, In particular, the
As several people mentioned in #416 , extra information about convergence, iterations, etc. is crucial.
We followed the source code directly from Scipy but there were several technical issues with Numba.
Great, thanks. Nice looking code.
If we do use named tuples then let's also change our existing maximization function accordingly.
I can't think of a better approach to accommodating the fact that only only primitive arguments can be optional. @oyamad Do you have any suggestions on how to better structure this code?
This is a trivial point, but I thought I read somewhere that having multiple return statements within one function is frowned on these days in software circles. It that not so? In any case you might also save a few bytes by replacing your multiple return statements with
@jstac I am not sure if I really understand the issue, but the following generates different code for different signatures (which behaves like optional arguments from the user's perspective):
from numba import jit, generated_jit, types @generated_jit(nopython=True) def test(x, f=None, f2=None): if isinstance(f, types.Callable): if isinstance(f2, types.Callable): def return_f2(x, f, f2): return f2(x) return return_f2 # else def return_f(x, f, f2): return f(x) return return_f #else def return_0(x, f, f2): return 0 return return_0
@jit(nopython=True) def f(x): return x @jit(nopython=True) def f2(x): return 2*x
test(10, f) 10
test(10, f, f2) 20
But, in my opinion, this would unnecessarily complicate the structure of the code and increase the maintenance costs. Having different names for different sets of arguments (