On 13/02/2008, Dan Goodman <[EMAIL PROTECTED]> wrote: > Background: I'm writing a package to run simulations which make extensive use > of > linear algebra, for which I'm using numpy. However - it is important to my > package that quantities can have dimesions, so I've written a class Quantity > subclassed from float which includes the physical dimensions and raises > exceptions etc. if you try to add volts to kilograms or whatever. This seems > to > work fine, but I also wanted arrays containing physical dimensions. I wrote a > class qarray subclassed from numpy.ndarray which mostly just copies the > functionality of an array with dtype=object. Here is the issue. The code for > my > package internally doesn't use these qarray objects, it uses numpy arrays > because it would obviously be terribly slow to be repeatedly checking if the > dimensions were consistent all the time. However, I want to present a > (somewhat) > consistent strict unit-checking front to the user of this package. As one part > of this, I would like a class that appears to act exactly like a qarray (which > itself is supposed to act very much like a numpy array) but maintains a > connection with its numpy array counterpart in my package.
I'm not sure I understand all the different layers you're talking about here. I think that I would attack your problem in the following way: Use ScientificPython's PhysicalQuantity (alone and in object arrays) or "unum"s to represent quantities with units: http://books.google.com/books?id=3nR75KSvsq4C&pg=PA169&lpg=PA169&dq=numpy+physicalquantity&source=web&ots=_cmXEC0qpx&sig=JBEz9BlegnIQJor-1BwnAdRTKLE Object arrays are fairly horrible, but having one unit per array shouldn't be very inefficient. It could cause some headaches, since it's sometimes useful to have an array with mixed units (differential equation solvers often require this when you convert a higher-order problem to first-order, for example), but it should be quite efficient computationally. So I would pull together an array that held a collection of quantities all in the same units. Type checking then becomes a once-per-array operation, which is relatively cheap. The way I'd implement this is (by preference) by grabbing a version off the net, or (if that fails) as a subclass of ndarray. If I want to do some heavy-duty array mangling without type checking getting in my way, I'll just convert to an ndarray (either normalizing the units or saving them), do the heavy lifting, and reapply the units afterwards. I don't really see why you're talking about proxy classes... Perhaps your problem is actually two problems: implementing unit arrays, and doing something I haven't understood. Is there any reason not to separate the two, and use one of the existing solutions for unit arrays? Anne _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
