Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API design: prevent unneeded recompilation #28

Open
maurosilber opened this issue Apr 19, 2022 · 1 comment
Open

API design: prevent unneeded recompilation #28

maurosilber opened this issue Apr 19, 2022 · 1 comment

Comments

@maurosilber
Copy link
Collaborator

From: #12 (comment)

The solver shouldn't recompile when only the initial conditions y0 change. But this fact is hidden by the current API, which accepts both jitted and non-jitted functions. In the latter case, it is jitted inside Solver.__init__, leading to a "different" function as far as numba is concerned, and triggering a recompilation of (some) parts of the Solver.

Instead, we could:

  1. raise an error when the passed function is not jitted
  2. document this behaviour somewhere, as it could still be "misused" as Solver(numba.njit(func), ...)

A similar issue happens with functions which depend on parameters (func(t, y, p)). A closure (rhs(t, y)) is generated inside Solver.__init__, which is considered a different function even if the same parameters are used.

We could provide a helper function to produce the closure outside Solver.__init__:

@numba.njit
def closure(func, params):
    @numba.njit
    def rhs(t, y):
        return func(t, y, params)
    return rhs

Later, we could change the internal implementation, changing func(t, y) to func(t, y, p), and passing an array p of parameters where needed.

@hgrecco
Copy link
Owner

hgrecco commented Apr 19, 2022

I think we could start by raising a warning and then move to raise an error when we change to func(t, y, p)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants