How should UAtom uncertainty components with zero weight be handled?

[jagerber48]

I am working on the branch that has the LinearCombo/Variable/AffineScalarFunc to UAtom/UCombo/UFloat refactor and I'm coming across an edge case with how the UCombo works. The issue has to do with when the weight of a certain UAtom within a UCombo is equal to zero. This discussion is related to #283.

The code in question is around here https://github.com/lmfit/uncertainties/pull/262/files#diff-47117210822144d1b82b5f22ecfe2d43d83ac2aa86907bd24fb205a698881960R52

In this new architecture

• A UAtom is essentially just a unique ID (UUID) generated using uuid4. Unless two UAtom have the same UUID, they are unequal. Unequal UAtom objects represent independent, unit variance, zero mean random variables.
• Abstractly, a UCombo is thought of a linear combination of UAtom objects. Slightly more concretely, a UCombo is a mapping from UAtom objects to float weights. UCombo objects can be added together and multiplied by scalars. These operations support the linear error propagation arithmetic which is the heart of the uncertainties package. The UCombo object supports the lazy expansion of its mapping. This is what allows many arithmetic operations to be performed on UFloat object with linear, rather than quadratic, computational complexity. If you want to calculate the std_dev or __hash__ of a UCombo object the UCombo object must be "expanded" into a simple dict mapping UAtom to float weights. __eq__ is calculated based on __hash__.
• A UFloat has a float nominal_value attribute and a UCombo uncertainty attribute.

Before expansion, the UCombo's main attribute is the ucombo_tuple. This has the type

ucombo_tuple: Tuple[Tuple[Union[UAtom, UCombo], float], ...]

This is like a collection of mappings from either UAtom objects or other nested UCombo objects to float weights. When the expanded property is accessed via the std_dev property or __hash__ method the ucombo_tuple is recursively walked through and all like-terms (same UAtom) are collected and an expanded_dict that maps UAtom to float weights in returned.

Right now, in the spirit of #283 and not special casing 0, the behavior is that a UAtom can have a weight of exactly zero. In this case the UAtom doesn't contribute to the std_dev. However, the edge case issue that I am having, is that two UFloat can have the same nominal_value and the same expanded_dict UP TO inclusion of UAtom with 0 weights. The hash is calculated by hashing each key/value pair in the expanded_dict, so even if two UCombo differ only by inclusion of UAtom with weight 0, the hash will come out different and they will compare not equal. This is NOT in the spirit of having equality model random variables that we've discussed elsewhere. Indeed this test fails:

zero = ufloat(0, 0)
x = ufloat(1, 0.1)
x_zero = x - x
assert x_zero == zero

The resolutions that I see are

1. Exclude UAtom with zero weight from the __hash__ calculation. This will fix the test, but it has the problem that when users view the expanded_dict it may look different between two different but equal UCombo objects.
2. Exclude UAtom with zero weight from the expanded_dict. At the end of the expansion calculation I can check for UAtom with weight 0 and exclude them from the expanded_dict. This means the expanded_dict for zero and x_zero UFloat objects above would be empty. The disadvantages here are that we are special casing zero again which changes how some of the code is structured and that there might be a performance implication for this check during the expanded property calculation.

Specifically, when I implement option 2, many tests start failing. In these cases I believe the source code is behaving fine and that the tests are simply failing because they are written WITHOUT special casing this zero weight case. The tests can be reasonably rewritten to special case the zero weight case, but it's outside of the spirit of the path I'm taking out of #283 to try to avoid special casing zero.

Because the downside of option 1 seems pretty problematic, I am leaning towards exploring option 2 which involves rewriting tests and doing performance analysis. I'm curious for others to understand and comment on the issue and give opinions on my proposed resolutions or propose other resolutions.