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

Model ABC's #49

Closed
tBuLi opened this issue Jan 19, 2016 · 1 comment
Closed

Model ABC's #49

tBuLi opened this issue Jan 19, 2016 · 1 comment

Comments

@tBuLi
Copy link
Owner

tBuLi commented Jan 19, 2016

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.

class BaseModel:
    """ 
    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.
    """

class Callable(BaseModel):
    @abstractmethod
    def eval_components(self, *ordered_data, **named_data):
         """" Returns the component of the model evaluated at the given data point(s) """

   def eval_chi_squared

class Differentiable(Callable):
    @abstractmethod
    def eval_jacobian(self, *ordered_data, **named_data):
         """" Returns the jacobian evaluated at the given data point(s) """

   def eval_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.

@pckroon
Copy link
Collaborator

pckroon commented Jan 25, 2016

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)

tBuLi pushed a commit that referenced this issue Jan 29, 2016
…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.
@tBuLi tBuLi closed this as completed in e87e9c5 Jul 30, 2016
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