Using this issue to track and plan the next features. Any additional, comment in this issue and this top post will be edited to include them, link to sub-issues, and list relevant PRs for each item.
Fitting
[ ] renorm: fit only the normalization parameters easily
[x] goodness: estimate the goodness of fit with Monte-Carlo sampling. XSPEC provides the sim and nosim keywords, and samples with mean and standard deviation given by the best fit and its covariance matrix. Also fit and nofit for whether the simulation should be fitting to the model again or not.
[ ] Something akin to error but I don't really like how this command works. I think explicitly having some MCMC routines is a better and more obvious for calculating confidence intervals. The user is then fully aware of how their errors are being calculated, and that they have access to the full range of analysis the MCMC gives. I don't think the other Monte-Carlo method the XSPEC documentation describes should be implemented at all.
[x] freeze: currently all parameters must be specified as free of frozen when creating the model. A freeze! and free! API would be quite simple to implement, though would be difficult to make type-stable. Additionally, simpler constructors for specifying the initial state of parameters should be provided. It was my belief when first implementing this library that in pretty much all cases, a user would know which parameters they want to have free and frozen at any given point, and that a script could represent that at compile time. I am concerned that it may have perhaps been better to do a runtime check on the parameter states, but I am not convinced without a benchmark.
Plotting
[ ] Chi-squared differences
[x] Residual plots
[ ] Plotting unfolded models, and model contributions to a total.
General
[x] fakeit: sample spectra from a model, folded through the response and added to a background + optional statistical fluctuation, sensitive to the error statistics selected.
[ ] Energy ranges: it can be useful to be able to specify the domain vector for the fits when calling fit, especially since convolutional methods or even the redistribution matrix may be sensitive to energies not in the masked data. This is relatively straightforward to add. XSPEC has the energies command for modifying the energy range, and I think some of that should be mimicked with some set_domain! on the FitProblem, with the option of even just passing a whole new array to be used. This would have to be rebinned so that it could be folded through the RMF, but we have routines for that already.
[ ] Background fitting: this wouldn't be too difficult to do, and the API would be that the user specified a background model and the background Spectrum when creating the FitProblem. A redesign that might be needed is the rephrase some of the fitting around Spectrum instead of SpectralDataset so that this is much easier and cleaner to implement. A question to ask is, should a user be able to fit a Spectrum or only a SpectralDataset?
[ ] Rebinning data in different ways - e.g., counts above background in each bin, minimum signal-to-noise ratio, including user defined thresholds. This would ideally also be able to output an OGIP grouping column.
Using this issue to track and plan the next features. Any additional, comment in this issue and this top post will be edited to include them, link to sub-issues, and list relevant PRs for each item.
Fitting
renorm
: fit only the normalization parameters easilygoodness
: estimate the goodness of fit with Monte-Carlo sampling. XSPEC provides thesim
andnosim
keywords, and samples with mean and standard deviation given by the best fit and its covariance matrix. Alsofit
andnofit
for whether the simulation should be fitting to the model again or not.error
but I don't really like how this command works. I think explicitly having some MCMC routines is a better and more obvious for calculating confidence intervals. The user is then fully aware of how their errors are being calculated, and that they have access to the full range of analysis the MCMC gives. I don't think the other Monte-Carlo method the XSPEC documentation describes should be implemented at all.freeze
: currently all parameters must be specified as free of frozen when creating the model. Afreeze!
andfree!
API would be quite simple to implement, though would be difficult to make type-stable. Additionally, simpler constructors for specifying the initial state of parameters should be provided. It was my belief when first implementing this library that in pretty much all cases, a user would know which parameters they want to have free and frozen at any given point, and that a script could represent that at compile time. I am concerned that it may have perhaps been better to do a runtime check on the parameter states, but I am not convinced without a benchmark.Plotting
General
fakeit
: sample spectra from a model, folded through the response and added to a background + optional statistical fluctuation, sensitive to the error statistics selected.fit
, especially since convolutional methods or even the redistribution matrix may be sensitive to energies not in the masked data. This is relatively straightforward to add. XSPEC has theenergies
command for modifying the energy range, and I think some of that should be mimicked with someset_domain!
on theFitProblem
, with the option of even just passing a whole new array to be used. This would have to be rebinned so that it could be folded through the RMF, but we have routines for that already.Spectrum
when creating theFitProblem
. A redesign that might be needed is the rephrase some of the fitting aroundSpectrum
instead ofSpectralDataset
so that this is much easier and cleaner to implement. A question to ask is, should a user be able to fit aSpectrum
or only aSpectralDataset
?