-
Notifications
You must be signed in to change notification settings - Fork 19
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
Model evaluation problems encountered after several derivations #356
Comments
I think a reasonable solution would be to be able to provide a signature to Model, which should override the automatically generated one. This is something that's going to break for someone at some point, but eh. I can try to mock up a PR. In the meantime, a Model has a @tBuLi What's your take on this? |
Thanks @pckroon for your answer.
All this is not really elegant. Patrick |
Hi Patrick, thanks for your input. I am not sure that I understand the issue though, perhaps you can let me know if I understood you correctly. Your problem seems to be that you want to derive with respect to the variables instead of the parameters, but keep the same signature? That is indeed not supported currently.
>>> x, y = variables('x, y')
>>> a, b = parameters('a, b')
>>> model = Model({y: a*x + b})
>>> model.connectivity_mapping
{y: {x, a, b}}
yder, = variables('yder')
connectivity_mapping = {}
connectivity_mapping[yder] = model.connectivity_mapping[y]
diff = NumericalModel({yder: y.diff(x)}, connectivity_mapping=connectivity_mapping)
Never mind, I now realize that this does not sufficiently address your problem. My other solution is to put all derivatives and the original in the same model. >>> x, y, yder = variables('x, y, yder')
>>> a, b = parameters('a, b')
>>> model = Model({y: a*x + b, yder: a}) In this way, symfit should be able to guess the broadcasting rules correctly. But at the cost of evaluating everything at the same time, which might be undesirable. |
My interpretation of the root problem is that there is no way to set a Model's call signature (+ return values/shape), rather than rely on the automated mechanism. |
@tBuLi , @pckroon
Concerning the 2nd proposal : |
Doesn't mean I don't like the idea, or that it won't get implemented ;) I'm just not making any claims regarding timelines |
Hello,
In addition to the one reported in #355 , other issues can be encountered when doing for instance model derivations using the symfit framework.
Starting for instance with a simple model1 defined with the expression
y(x; a, b) = a*x + b
After one derivation, the derivative model2 is created with the related expression:
y(x; a) = a
but you can't evaluate it with the same original parametersa
andb
:model2(x, a=1, b=2)
because theb
parameter is missing. This is quite embarassing when working with complicated model and n-order model derivation ... (with no idea of which parameters will still be present in the final expression).Another problem is when evaluating the last expression
y(x; a) = a
with x as an array,model2(x, a=1)
will return a 'singleton' [a] and not [a, a, ...a] of same size as x.This could be fix in the future ?
Thanks
Patrick
The text was updated successfully, but these errors were encountered: