Comments (13)
I see what you mean.
In principle, uncertainties
may do something similar. Note, however, that not all functions are wrapped in the same way anymore: functions that are locally constant (umath.ceil()
, etc.) now return a Python constant, not a value with uncertainty, so they are wrapped in a specific way.
However, I do not want to add anything that is not necessary, I prefer minimal, "essential" code. I wonder if the procedure that you propose is the best way to go: I guess that you want your module to call wrap_module()
with wrapped
= your module? But why not do things in reverse: can your code use (wrap, I guess) the functions from uncertainties.umath
(if needed) instead of those from math
?
from uncertainties.
Hi Hermann,
Is the issue that you initially raised still a problem for pint?
from uncertainties.
We now use uncertainties as the numerical class underlying Pint's Measurements (ufloat + units). All simple things work as charm (simple arithmetic, string formatting, etc). I will soon implement string parsing (also using uncertainties functions). I am really happy about this.
We are now looking for a way to have arrays and math operations.
For arrays, my understanding is that the suggested way to use numpy arrays with uncertainties is to create an ndarray
of ufloat
objects. In Pint, we do the opposite: we embed an array into a Quantity
. This difference creates some integration issues .
For math operations, in Pint we chose to use numpy functions (instead of Python's math
). So instead of creating a module wrapping math
we have added methods and attributes to Quantity
so it can deal properly with numpy functions. In this way we support almost every single numpy function without requiring the users to import a different module. We are thinking what is the best way to start providing math support for Measurements.
from uncertainties.
Thank you for this very lucid description of the situation: I understand it much better.
I would like to explore that "Pint way" of integrating NumPy. Can you describe in more details how Pint "properly deals with NumPy functions" through the "addition of methods and attributes"? I haven't looked at your code, but I have looked for such a protocol in NumPy's documentation without ever finding anyβ¦
from uncertainties.
Just for clarity, let me say that when I say support numpy functions I mean that if o
is your object of class O
, numpy.cos(o)
does the right thing. In addition to monkey patching (which I do not like), there are two ways to do it: embedding and subclassing.
You can embed a numpy array in your class O
and implement numpy ndarray attributes and methods (clip
, fill
, put
, etc) and magic methods (__array_wrap__
, __array_finalize__
, etc).
These magic methods are called at the beginning or end of numpy ufuncs and other numpy functions. One of the arguments that they receive is the ufunc that was called and therefore you can take appropriate action for every calculation. For example you can have dict mapping each ufunc to its derivative and after each ufunc call, calculate the new std_dev and use it in the object.
This is the way we have originally choose in Pint. It has worked remarkably well and we support more numpy functions than any other units package out there. However, we have found a limitation. Any function that calls asanyarray
or similar fails as it is not a ndarray subclass and there seems to be no way out. You cannot duck-type. This is the reason for hgrecco/pint#37, hgrecco/pint#39, hgrecco/pint#127
So we are looking now into subclassing. The implementation will be roughly the same but everything should work. I am trying to do it without loosing the ability to use Pint without NumPy, keeping the API simple and a single constructor. This will probably come in Pint 0.6 (we will release 0.5 before the end of this month)
Finally, let me add that this comes with a cost. In Pint, some calculations are done twice. To my knowledge, there is no way to signal NumPy that my pure python code will handle the calculation. This means that if you do sqrt(1. * kilometer / meter)
(without simplifying first), Pint actually does sqrt(1000), but NumPy still does sqrt(1)
and this value is dropped. This will not be a problem for you because to calculate f(x +/- e)
you still need f(x)
.
from uncertainties.
This is interesting. Thank you for the information.
Would it help Pint if uncertainties.unumpy.uarray()
created a custom undarray
instead, that defined the NumPy magic methods?
from uncertainties.
Pint transfers the task to the underlying numerical type. If the user wants numpy.cos(o)
, Pint takes care of the units and then calls numpy.cos(<magnitude of o with the right units>)
. So if you create numerical type (undarray) that supports this type of operations with numpy functions, it will be a big win.
from uncertainties.
I will have a look, then. I'm sorry but I'm not sure when, though,β¦ The fact that NumPy always calls the ufunc complicates things for uncertainties, but as you said at least this won't incur a processing time penalty. I need to invest more thoughts in this before deciding what to do. I hope this is not too much of a problem for Pint.
from uncertainties.
Take your time. I am really happy about how the collaboration between Pint and uncertainties is working. We find a common interest, we agree on a few things and then we implement it. We all have other things to do, so features land when we can implement them.
Please keep me posted! And if you find a better way, I might ported to Pint. For 0.6, I will start working on subclassing. I will let you know how that goes.
Maybe you found a better solution that we can take it to Pint.
from uncertainties.
Leaving a reference note about handling uncertainties in arrays in a different way than currently done by uncertainties
: numpy.cos(obj)
returns obj.cos()
if it is defined (NumPy 1.8.1). I have not checked whether this is guaranteed by NumPy, but if it is this might be very useful.
from uncertainties.
For reference: direct implementation of uncertainties in NumPy ndarrays: astropy/astropy#3715.
from uncertainties.
Thanks for the reference. It is roughly the direction I was proposing, right?
from uncertainties.
@hgrecco As far as I can tell, yes, it is similar to what you were proposing, but I haven't checked the details.
from uncertainties.
Related Issues (20)
- TypeError: can't convert an affine function (<class 'uncertainties.core.AffineScalarFunc'>) to float; use x.nominal_value HOT 2
- Type Annotation Checker Problems with UFloat HOT 6
- uncompatibility with Python3.12 HOT 4
- package maintanence HOT 65
- [3.1.7] SyntaxWarning: invalid escape sequence '\<something>' with Python 3.12 HOT 2
- Unintuitive class behaviour HOT 1
- Pandas sort_values with multiple columns does not work for AffineScalarFunc HOT 1
- Add uploading code coverage to codecov to github action HOT 3
- code coverage not uploading for master branch HOT 6
- Lacks basic VSCode settings for running pytest tests with VSCode. HOT 6
- Replace documentation references from nose unit tests to pytest unit tests.
- Remove unused imports in tests. HOT 1
- Add CITATION.cff file HOT 6
- Changelog maintenance plan HOT 2
- Review numpy API coverage
- `tests/helpers.py` is missing in 3.2.0 PyPI sdist HOT 2
- Import error in autopkgtests -missing unumpy HOT 1
- readthedocs docs not building HOT 6
- Trailing decimal symbol test failing HOT 3
- Strange behavior on copying
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uncertainties.