You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AffineScalarFunc/UFloat has very strange behavior on copying. We discovered this in one of the issues about hash. @newville provided this example clearly showing some of the strange behavior.
>>> from uncertainties import ufloat
>>> import copy
>>> a = ufloat(1, 0.1)
>>> a == a*1.0
True
>>> a == copy.copy(a)
False
>>> a*1.0 == copy.copy(a*1.0)
True
>>> a == copy.copy(a*1.0)
True
>>> a*1.0 == copy.copy(a)
False
This behavior is very confusing to a user, but, looking at the test_copy test, it looks like some of this behavior is desired. There is similar behavior for pickling.
# Weak references: destroying a variable should never destroy the
# integrity of its copies (which would happen if the copy keeps a
# weak reference to the original, in its derivatives member: the
# weak reference to the original would become invalid):
delx
gc.collect()
assertyinlist(y.derivatives.keys())
It seems like the targeted behavior involves copies creating new, independentAffineScalarFunc instances but somehow retaining the correlations of the original. It just seems strange.
I would suggest that copies should be equal to the originals and have the exact same correlations as the original. Copies are correlated with originals, copies are correlated with copies etc. This is realized without any extra handling on my rewrite branch which uses immutable UAtoms and UCombos to represent the uncertainty of UFloats. This allows the following diff on test_copy and changes newville's test to
>>> from uncertainties.new import ufloat
>>> import copy
>>> a = ufloat(1, 0.1)
>>> a == a*1.0
True
>>> a == copy.copy(a)
True
>>> a*1.0 == copy.copy(a*1.0)
True
>>> a == copy.copy(a*1.0)
True
>>> a*1.0 == copy.copy(a)
True
Regardless of how the fix is implemented, I think this behavior should be modified to be more intuitive.
The text was updated successfully, but these errors were encountered:
AffineScalarFunc/UFloat
has very strange behavior on copying. We discovered this in one of the issues abouthash
. @newville provided this example clearly showing some of the strange behavior.This behavior is very confusing to a user, but, looking at the
test_copy
test, it looks like some of this behavior is desired. There is similar behavior for pickling.uncertainties/tests/test_uncertainties.py
Lines 177 to 225 in f097015
It seems like the targeted behavior involves copies creating new, independent
AffineScalarFunc
instances but somehow retaining the correlations of the original. It just seems strange.I would suggest that copies should be equal to the originals and have the exact same correlations as the original. Copies are correlated with originals, copies are correlated with copies etc. This is realized without any extra handling on my rewrite branch which uses immutable
UAtom
s andUCombo
s to represent the uncertainty ofUFloat
s. This allows the following diff ontest_copy
and changes newville's test toRegardless of how the fix is implemented, I think this behavior should be modified to be more intuitive.
The text was updated successfully, but these errors were encountered: