New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bugfix: propagation of measurement uncertainties into parameter covariances #14519
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
Propagate measurement uncertainties via the ``weights`` keyword argument into the | ||
parameter covariances. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,7 @@ In particular, this release includes: | |
.. * :ref:`whatsnew-5.3-unit-formats-fraction` | ||
.. * :ref:`whatsnew-5.3-unit-formats-order` | ||
.. * :ref:`whatsnew-5.3-nddata-collapse-arbitrary-axes` | ||
.. * :ref:`whatsnew-5.3-modeling-measurement-uncertainties` | ||
.. * :ref:`whatsnew-5.3-coordinates-refresh-site-registry` | ||
|
||
In addition to these major changes, Astropy v5.3 includes a large number of | ||
|
@@ -198,6 +199,7 @@ we can take the sum of ND masked quantities along the ``1`` axis like so:: | |
array([ True, False]), | ||
StdDevUncertainty([1.41421356, 1.73205081])) | ||
|
||
|
||
.. _whatsnew-5.3-coordinates-refresh-site-registry: | ||
|
||
Refresh cached observatory site registry for |EarthLocation| methods | ||
|
@@ -214,6 +216,16 @@ however, is updated from time to time to include new locations. The user | |
may refresh their locally cached site registry by passing the new | ||
``refresh_cache=True`` option to these two functions. | ||
|
||
.. _whatsnew-5.3-modeling-measurement-uncertainties: | ||
|
||
Support for collapse operations on arbitrary axes in ``nddata`` | ||
=============================================================== | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Too late to fix, but the whatsnew section title is wrong. (Please be more careful in future PRs) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yikes! My apologies 😱 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, this is super confusing... Is there a way to fix just the doc without doing another release? https://docs.astropy.org/en/stable/whatsnew/5.3.html#whatsnew-5-3-modeling-measurement-uncertainties Also, while we're at it, is it normal to have dev tag displayed on the "stable" URL? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It will be for the next bugfix release, 5.3 is done, but good point, we need to fix that in the v5.3.x branch. About the dev tag, this is the goal of #14860. (Not a new issue, just managed to find a solution before forgetting about it ;)). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I fixed it directly on v5.3.x 31f3290 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks ! |
||
|
||
Propagate measurement uncertainties into the best-fit parameter covariances | ||
via the ``weights`` keyword argument in non-linear fitters. Decreasing | ||
the ``weights`` will now increase the uncertainties on the best-fit parameters. | ||
|
||
|
||
Full change log | ||
=============== | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also give the option to toggle the behavior like the
absolute_sigma
option thatscipy.optimize.curve_fit
gives users for the case when no weights are passed?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand giving people options is generally a good thing, and the generic name of the kwarg is
weights
. But we say in the docstring thatweights = 1 / sigma
, which is not true ifabsolute_sigma == False
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, so then the question becomes "should we add an option to disable this change". That is add an option which allows users to return the behavior of the weights to how they previously worked? My concern here lies with the fact that this change will technically change this computation's output in some cases. This can have knock-on effects for downstream users, who may wish to return to the previous behavior.
@pllim what is your opinion here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless the old way is completely wrong, it is generally good to provide backward compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would argue the old way is completely wrong. We offered a keyword to adjust the weights, but did not compute the result based on the weights.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also – the user can have "perfect" backwards compatibility if they set
weights = None
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I told Brett offline, API change is acceptable as long as it is not backported. And if an extra option lets people get the old results, then fine by me but ultimately it is up to @astropy/modeling .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In principle, I am okay with this change so long as it is not backported. However, we should probably advertise the change with a "whats-new". So that it is clear when reading the changes for astropy 5.3 that this behavior will be slightly different.