astropy/astropy — pull request #2276 by embray (2014-04-04 16:54:33+00:00)
Title: Merge model classes

Note: This PR builds on top of #2264 and #2269 which should be merged before this one. If either of them is not to be merged this PR's dependency on those other changes can be cleaved off, however.

As pointed out by @nden at https://github.com/astropy/astropy/pull/2149/files#r10402422 , different classes of models had different mechanisms for storing their parameter values, creating a fair amount of unncessary complexity.

This change attempts to smooth out some of the differences by merging the old `ParametricModel` class into the base `Model` class, so that all models more or less operate on the same basis. This simplifies the code a fair amount and will make it easier to maintain. An added advantage to this is that it adds full support for parameter constraints on *all* models, which can be useful even outside the context of fitting. I intend to build that functionality in on top of this PR.

This standardizes on the way `ParametricModel` stored parameters, where all the parameter values are stored in a single flat array along with a simple `_param_metrics` data structure providing information how to extract individual parameter values from that array. As @nden points out this may not be the *best* way. In fact, it might be difficult to really make this work with parameters as Quantities. But this was the path of least resistance for the first iteration. It will also now be much easier to change to a different storage method later, as the changes are only required in a couple places.

For now I've kept around a class named `ParametricModel` and its subclasses `ParametricModel1D` and `ParametricModel2D` and the subclasses thereof--the only thing that really distinguishes them at the moment is the fact that they have the `fittable=True` flag.

This does *not* fully resolve the issue addressed in #2149, but it will make the implementation for #2149 simpler. This also adds a few inefficiences, particularly in any models that have angular parameter values that need to be converted to radians for compuations. I have a separate branch running parallel to this one that will attempt to address that issue.