Skip to content

Refactors Quantity to have a standard error property#215

Merged
DrPaulSharp merged 1 commit into
refactor_24from
refactor_24_quantity
Jun 15, 2026
Merged

Refactors Quantity to have a standard error property#215
DrPaulSharp merged 1 commit into
refactor_24from
refactor_24_quantity

Conversation

@DrPaulSharp

Copy link
Copy Markdown
Contributor

This PR refactors quantity.py to ensure Quantity objects have a standard_error property, with the variance property being simply standard_error**2. This makes it easier to access errors in other parts of the SasData code.

I propose merging this PR before #207, and then rebasing and rewriting that PR to incorporate the changes in this one.

@DrPaulSharp DrPaulSharp requested a review from krzywon June 11, 2026 11:07

@codescene-delta-analysis codescene-delta-analysis Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No quality gates enabled for this code.

See analysis details in CodeScene

Quality Gate Profile: Custom Configuration
Install CodeScene MCP: safeguard and uplift AI-generated code. Catch issues early with our IDE extension and CLI tool.

@rprospero rprospero left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a bit of confusion on two points.

self._variance_cache = self.history.variance_propagate(self.units)

return self._variance_cache
return self._variance_cache**0.5

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function surprised me slightly and is making me think that I've misunderstood the PR. I'd rather assumed that the standard_error property would just return the value of _standard_error, as defined in line 1573.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is the case for the standard_error property of the Quantity object, defined on line 1607. Here is the standard_error property of the DerivedQuantity object. Note that the __init__ for this class is:

class DerivedQuantity[QuantityType](Quantity[QuantityType]):
    def __init__(self, value: QuantityType, units: Unit, history: QuantityHistory):
        super().__init__(value, units, standard_error=None)

        self.history = history
        self._variance_cache = None
        self._has_error = history.has_error()

i.e., we call the __init__ for a Quantity with standard_error = None. This is because for a DerivedQuantity we need to propagate errors from the quantity history, rather than read the property.

Comment on lines +1614 to +1617
@property
def variance(self) -> "Quantity":
"""Get the variance of this object"""
return self.standard_error**2

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a little odd that variance returns standard_error**2, but the standard_error property returns self._variance_cache**0.5. Wouldn't it be better to cut out the middle man and just return self._variance_cache here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't do this here, because the standard error is defined differently for Quantity compared to DerivedQuantity, as noted above. We could write a variance property for the DerivedQuantity defined as you suggest, but I felt that the code duplication wasn't justified in this case despite the simpler operation. Happy to hear feedback on that point though.

@DrPaulSharp DrPaulSharp merged commit d6aeda2 into refactor_24 Jun 15, 2026
11 checks passed
@DrPaulSharp DrPaulSharp deleted the refactor_24_quantity branch June 15, 2026 10:39
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.

2 participants