You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A recent discussion (#48) highlighted an important point: what exactly is a Model, and what isn't it?
As the number of Model subclasses is gradually growing, it is time to create some order. Current subclasses are TaylorModel, Constraint and soon to be introduced ODEModel.
Most importantly I define too many numerical functions in an independent way even though they are not. If you know the numerical way to evaluate the function, you can also evaluate its chi-squared, just to give an example.
So lets look at some of the ways model ABC’s could be defined. I left out a lot of default behavior to clarify what is interesting about each object. If methods have not been completed below that means they are implemented in a standard way.
classBaseModel:
""" Defines all the default behavior of a model: it's iterable, and when called the components are evaluated and returned as a namedtuple. Furthermore, the model has a call signature so it's inspect friendly. """classCallable(BaseModel):
@abstractmethoddefeval_components(self, *ordered_data, **named_data):
"""" Returns the component of the model evaluated at the given data point(s) """defeval_chi_squaredclassDifferentiable(Callable):
@abstractmethoddefeval_jacobian(self, *ordered_data, **named_data):
"""" Returns the jacobian evaluated at the given data point(s) """defeval_chi_squared_jacobian
Fitting subclasses already use these eval_functions so this would allow for plug and play definitions of custom Model object which immediately play nice with symfit tools designed for these classes of objects.
Currently what is called eval_ here is actually called numerical_ and these are properties. However, this has certain limitations I recently came up again so I intend to replace them by these eval_ methods since it's a better name.
The text was updated successfully, but these errors were encountered:
Referencing #38
Also, be aware that there is a callable built-in function. I'm just saying this so you can prevent a rehash of #12 and #13 (and maybe more)
…Some fundamental changes to the definition of a Model have been made though, so all excisting tests now fail. This will be fixed by #49 in the near feature.
A recent discussion (#48) highlighted an important point: what exactly is a Model, and what isn't it?
As the number of Model subclasses is gradually growing, it is time to create some order. Current subclasses are
TaylorModel
,Constraint
and soon to be introducedODEModel
.Most importantly I define too many numerical functions in an independent way even though they are not. If you know the numerical way to evaluate the function, you can also evaluate its chi-squared, just to give an example.
So lets look at some of the ways model ABC’s could be defined. I left out a lot of default behavior to clarify what is interesting about each object. If methods have not been completed below that means they are implemented in a standard way.
Fitting subclasses already use these eval_functions so this would allow for plug and play definitions of custom Model object which immediately play nice with
symfit
tools designed for these classes of objects.Currently what is called
eval_
here is actually callednumerical_
and these are properties. However, this has certain limitations I recently came up again so I intend to replace them by theseeval_
methods since it's a better name.The text was updated successfully, but these errors were encountered: