Skip to content

subtraction of same element handled correctly #82

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

Merged
merged 1 commit into from
Dec 16, 2015
Merged

subtraction of same element handled correctly #82

merged 1 commit into from
Dec 16, 2015

Conversation

mankoff
Copy link
Contributor

@mankoff mankoff commented Mar 24, 2014

handle uncertainty in x-x case (different than x-y).

@burnpanck
Copy link
Contributor

Are you sure that you want to do this? Of course this is the proper uncertainty for the subtraction of an uncertain quantity from itself, but for this to be correctly handled, one must distinguish the 'identity' of the given variables. However, the quantities from this package otherwise have value-semantics everywhere else. For example '2_x - 2_x' should have zero uncertainty as-well. I think it hurts more than it helps in that the meaning of the subtraction now depends on the identity of the operands, while otherwise the meaning of any expression using quantities is clearly calculation of the value and uncertainty of the quantity derived using the given expression and the given values and uncorrelated uncertainties. It only improves physical correctness in a small corner-case which should very seldom appear (you never write 'x-x') while possibly leading to confusion: For example in a physics simulation/computation where one just puts in the quantities of interest in the beginning, one might very well just set one quantity to be equal to the other, implying that they are of roughly equal magnitude, but still uncorrelated physical quantities. In that case the python identity does not match with the identity of the physical quantity.

To properly propagate errors, one necessarily has to carry information on the identity of the physical quantities, as only a symbolic math or at least automatic differentiation package can do. Maybe it's worth considering to merge this package with one of the automatic differentiation packages for proper error propagation. For some quick calculations, also the simple uncorrelated errors from this package are good enough, but I do not think one should implement some ill-defined semantics halfway between proper error propagation and simple uncorrelated error calculation.

@ddale ddale merged commit 46c2efd into python-quantities:master Dec 16, 2015
@burnpanck
Copy link
Contributor

Again, I don't think it's a good idea to do this...

@ddale
Copy link
Member

ddale commented Dec 17, 2015

oh boy, I did not intend to merge this. I agree with your comments, I think I had multiple pull requests open in different tabs and hit merge in the wrong tab.

@ddale ddale mentioned this pull request Dec 17, 2015
@ddale
Copy link
Member

ddale commented Dec 17, 2015

reverted in quantities-0.11.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants