Open tBuLi opened 5 years ago
My only issue with this is that it makes it a little bit harder for users to create a CallableNumericalModel
with a function that just returns a number. Unless you want the CallableNumericalModel to do the wrapping of the answer, but I see problems on the horizon there: you'll need to know the symbols, and only do it if the function doesn't return Ans
objects already.
Why is it harder for functions that only return a number? We can already do that now, right? Like,
{y: lambda x: x}
is valid input to CallableNumericalModel
. What am I missing here.
Maybe I'm missing something. I was under the impression you'd have to provide {y: lambda x: Ans(x=x)}
Ah, I see what you mean. No, I'm not intending to always use the Ans
object, that would indeed be worse. I'm just proposing that if a component is evaluated, and it happens to return an Ans
object, than we realize what has happened (the component was one of our own models) and so we unpack it.
Taking the example from #248, we realized that the syntax for
CallableNumericalModel
's could be improved a bit fromto
if we make
CallableNumericalModel
's aware ofAns
objects to automate the unpacking. (ODEModel
is used here for no particular reason, could be any model.) I think this looks a lot cleaner. However, this could potentially open a pandora's box I haven't thought about, but for now I think it's save. An interesting extension would be tuple unpacking for multicomponent models:where
y2
is set toNone
so it is ignored in the optimization as usual. The general invariant here would be{ode_model.dependent_vars: ode_model}
.For general models this might not be a good idea because of the extra work involved for calculating jacobians etc, but for
CallableNumericalModel
this might in fact be a powerful addition.