-
Notifications
You must be signed in to change notification settings - Fork 45
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
Pint-Pandas support for uncertain Quantities #139
Comments
MichaelTiemannOSC
added a commit
to MichaelTiemannOSC/pint-pandas
that referenced
this issue
Oct 15, 2022
Signed-off-by: MichaelTiemann <72577720+MichaelTiemannOSC@users.noreply.github.com>
This was referenced Oct 15, 2022
MichaelTiemannOSC
added a commit
to MichaelTiemannOSC/pint-pandas
that referenced
this issue
Nov 3, 2022
Signed-off-by: MichaelTiemann <72577720+MichaelTiemannOSC@users.noreply.github.com>
closing this as it's now possible with UncertaintyArray |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Pint-Pandas implements PintType as an ExtensionDtype and PintArray as an ExtensionArray, brings Pint's Kung-Fu to Pandas!
This issue is about extending PintArrays to handle Quantities whose magnitudes are
uncertainties
. Pint already supports the concept of uncertainties withMeasurement
, andMeasurement
is derived fromQuantity
. But as far as I can tell, all of the existing Extension magic is implemented aroundmagnitude
and none at all aroundvalue
,error
. So Measurements work, but in the Pint world, not the Pint-Pandas world.Looking at the problem from two perspectives (adapt Pint-Pandas to work with
Measurements
or enhance Pint-Pandas to deal with more generalQuantity
types), I chose to extend the range of allowable data types formagnitude
inQuantity
.I have written a test case, run the pre-commit scripts, and invite your commentary. I know I need to write at least one more test case (which deals with Pint talking to itself in the print->read->eval process). But that test case might more properly belong in Pint. We'll see.
The text was updated successfully, but these errors were encountered: