Implement Analytical Derivatives on CompoundModel - #17034

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

Ok so just for the record as I am going to stop working on this for today: one of the remaining issues is related to fit_deriv for Polynomial2D which always returns a 2-D array as it flattens multi-dimensional input, whereas other models such as Gaussian2D don't. We need to be more robust to this in CompoundModel.fit_deriv.

The Polynomial2D thing was a red herring, fitters will just call fit_deriv with 1D arrays even when there are multiple dimensions, so this won't matter. We are down to three test failures: one because there is a difference of NaN vs Inf for the numerical vs analytical derivatives, and the other one is a slight numerical difference in the final model, which might just be a numerical issue, so might be safe to increase the relative tolerance?

Yes I would like to add more operators to this but these are the most critical and I don't have time to get others in for feature freeze.

Looks to me that this can now go in. I've opened #17250 as a reminder of @WilliamJamieson's suggestion to expand the scope later on.
If no one complains about it I intend to merge this later today.

On one hand it is 'just' the chain rule but on the other hand I think it requires implementing derivatives with respect to x for all functions if I recall? (As current derivatives are relative to parameters). @Cadair and I did start looking into it but it seemed non trivial so decided to leave it for later.

@neutrinoceros ❓

This PR caused a regression in 7.0.0: #17509
Lessons learned:

• I should remember to squash-merge more often
• I should refrain from merging sizeable features literal hours ahead of feature freeze 🥶

I should refrain from merging sizeable features literal hours ahead of feature freeze 🥶

Better than hours afterwards ;)