I notice there's no spline-based model in astropy.modeling.models. To give a specific use case, in some of the specutils planned functions one might want to use a spline as a continuum model. But if that machinery uses astropy models to do the fitting, it's not possible to say "use a spline as the continuum". So that suggests that at least a 1D spline model should be an option.
The catch here is that splines are a rather strange kind of model as far as the modeling API is concerned. You can't really initialize them without data (although they could be initialized as just all-0s), and the parameter list is rather confusing because there's several parameters per-knot, and they aren't really exposed that way in scipy's UnivariateSpline (probably the most natural underlying implementation). Additionally, you really want to always use them with a custom fitter, given that spline-optimized fitters are far more performant than any generic fitter would be. So a new fitter would also need to be implemented and users would have to know they should use that fitter if the model is a spline.
None of those are necessarily roadblocks, though. Personally I think the functionality is worth it... But I'd be interested what @nden @perrygreenfield @astrofrog, or any others might think?
I notice there's no spline-based model in
astropy.modeling.models. To give a specific use case, in some of thespecutilsplanned functions one might want to use a spline as a continuum model. But if that machinery uses astropy models to do the fitting, it's not possible to say "use a spline as the continuum". So that suggests that at least a 1D spline model should be an option.The catch here is that splines are a rather strange kind of model as far as the
modelingAPI is concerned. You can't really initialize them without data (although they could be initialized as just all-0s), and the parameter list is rather confusing because there's several parameters per-knot, and they aren't really exposed that way inscipy'sUnivariateSpline(probably the most natural underlying implementation). Additionally, you really want to always use them with a custom fitter, given that spline-optimized fitters are far more performant than any generic fitter would be. So a new fitter would also need to be implemented and users would have to know they should use that fitter if the model is a spline.None of those are necessarily roadblocks, though. Personally I think the functionality is worth it... But I'd be interested what @nden @perrygreenfield @astrofrog, or any others might think?