pahfit
pahfit copied to clipboard
Possible API change: Separate fit results from Model/add history to Features Table
In our current design, the model details, fit settings and fit results are put together in the Model class. This brings some complexity with it:
- We always have to think about what happens when a model is "refit", especially if a different redshift is specified, and features that were deactivated due to the wavelength range have to be reactivated.
- Storing the uncertainties is an issue. They are only meaningful for a fit result, not a fit setup.
- The bounds are stored alongside the result. They are only meaningful for a fitting setup, not the result (although they are still informative to the user, i.e. they can see if a bound has been hit).
Alternative design
- Model: stores the features table provided at construction, but does not change afterwards. Every call to fit returns a new Results object. Model objects can not be saved.
- Result: Contains the fitted features table, the uncertainties, maybe even a copy of the user-supplied spectrum? This would be the new home of the "plot" function, and various extraction / analysis tools. Results can be saved and loaded.
Possible issues with this:
- What does "guess" do then? Change Model or return a Result?
- Don't we want to be able to plot unfitted models / initial guesses too?
- How to use a result as initial conditions for another fit (Answer: pass it to the guess function).
- Maybe Model doesn't even need to be a class, but just a fit-function that takes yaml pack + spectrum, or a Result + spectrum (for re-fitting).
- The user has to learn two classes instead of one.
We're not going to change this now, since we really need to get PAHFIT running. But I really wanted to write this down, and we should keep this type of redesign in mind if we run into more symptoms of the same underlying conceptual problem.