[SciPy-dev] integration of Unum in scipy
DE MENTEN Sebastien
sebastien.dementen at alumni.insead.edu
Tue Feb 21 11:51:24 CST 2006
> The ties to traits, etc., _should_ all be optional. The base package
> (units.unit) is usable in a very stand-alone way. It is correct that
> the system is "tight to the SI" -- you'd have to derive a class or
> modify the core functionality to extend for things like currency.
> For "quantities" we typically use the quantity module, which allows
> a composite object that has 'data' and 'units' where data can be a
> float, or an array (or other sequence) of floats. This was to enable
> the performance gains of dealing with math on arrays of floats rather
> than an array of unit objects.
Was it specifically targeted at Numeric integration (i.e. is it the same
kind of problem I bumped into with Unum)?
If it is, then with wrap_array functionality from numpy, this is not
necessary anymore. Hence, I would favor I lighter approach (no redundant
> There is much more in the overall package which handles both Unit
> Systems and, orthogonally, some style information (default ranges,
> plotting styles, etc.) that is completely optional.
> As far as feedback goes, the core units package is very trouble-free
> us--we haven't had to do much to the code in a while for it to perform
> for us. On the other hand, the total package sees quite a bit of
> tweaking and cajoling to get it integrated into applications in the
> we want with the performance we want.
(see above for performance with arrays)
About feedback, I had something else in mind that the question you
answered. Do you have users who sends you questions, congratulations or
criticisms or who recommend the package to others? i.e. are there "real"
users of the package outside Enthought?
More information about the Scipy-dev