-
-
Notifications
You must be signed in to change notification settings - Fork 121
full inference through solvers #570
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
Conversation
function f()
__solve(_prob,args...;kwargs...)
end
T = Core.Compiler.return_type(f,Tuple{})
if hasfield(typeof(_prob),:f) && hasfield(typeof(_prob.f),:f) && typeof(_prob.f.f) <: EvalFunc
Base.invokelatest(__solve,_prob,args...; kwargs...)::T
else
__solve(_prob,args...;kwargs...)::T
endinfers |
|
Hmmm ... I'm on and: and for reference, the 2 callbacks, which are correctly type inferred, if I pass in all the value manually: |
|
It seems |
|
Yes, fair. But any thoughts on what might prevent the problem from inferring? |
|
Maybe it helps to specify |
|
Bingo! That fixed it!! Thanks so much!!! |
|
Great that it works 😃 |
This is exciting because it finally works! The tests show that you can change keyword arguments around and inference is still fine, thanks to @JeffBezanson! This requires Julia v1.5 in order to pass because it needs constant prop through the keyword arguments, since for example
save_idxscan change the values that are saved fromutou[1]and thus change the type of the output. This should make a lot of downstream packages infer better (I'm looking at you Pumas)!While this is exciting, there is a trade-off that is required to make this PR work out. Notice that I had to drop the automated progress bar handling from @devmotion @tkf @c42f. Something about it is making everything not infer, even with constant propagation. Could we figure out what that is? I'd hope to keep everything like a greedy programmer. To "fake it before we make it", I tried to force inference via
Core.Compiler.return_type, but that only does positional arguments. So I tried stuff like:But I am not sure how to
typeofover the kwargs, and even if I did, I'd have to reconstruct the kwargs so this would need to become a generated function. I am assuming that would be trying too hard, and so does anyone have any ideas on how to force inference through that choice?Fixes SciML/DifferentialEquations.jl#603