Re: [Numpy-discussion] composing Euler rotation matrices
[off topic] Nothing good ever comes from using Euler matrices. All the cool kids a using quaternions these days. They're (in some ways) simpler, can be interpolated easily, don't suffer from gimbal lock (discontinuity), and are not confused about which axis rotation is applied first (for Euler you much decide whether you want to apply x.y.z or z.y.x). They'd be a good addition to numpy. On Wed, Feb 1, 2017 at 1:42 AM, Matthew Brett wrote: > Hi, > > On Wed, Feb 1, 2017 at 8:28 AM, Robert McLeod > wrote: > > Instead of trying to decipher what someone wrote on a Wikipedia, why > don't > > you look at a working piece of source code? > > > > e.g. > > > > https://github.com/3dem/relion/blob/master/src/euler.cpp > > Also - have a look at https://pypi.python.org/pypi/transforms3d - and > in particular you might get some use from symbolic versions of the > transformations, e.g. here : > https://github.com/matthew-brett/transforms3d/blob/master/transforms3d/ > derivations/eulerangles.py > > It's really easy to mix up the conventions, as I'm sure you know - see > http://matthew-brett.github.io/transforms3d/reference/ > transforms3d.euler.html > > Cheers, > > Matthew > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Possible to pickle new state in NDArray subclasses?
I'm trying to subclass an NDArray as shown here: https://docs.scipy.org/doc/numpy/user/basics.subclassing.html My problem is that when I save the new class' state with pickle, the new attributes are lost. I don't seem to be able to override __getstate__ or __setstate__ to achieve this? Is it possible to allow new state to serialized when overriding an NDArray? In my example below, __setstate__ gets called by pickle but not __getstate__. In the final line, a RealisticInfoArray has been deserialized, but it has no .info attribute. import cPickle as pickle import numpy as np class RealisticInfoArray(np.ndarray): def __new__(cls, arr, info): obj = np.asarray(arr).view(cls) obj.info = info return obj def __array_finalize__(self, obj): if obj is None: return self.info = getattr(obj,"info",None) def __setstate__(self, *args): print "SET" return np.ndarray.__setstate__(self,*args) def __getstate__(self): print "GET" assert False, "EXPLODE" return np.ndarray.__getstate__(self) arr = np.zeros((2,3), int) arr = RealisticInfoArray(arr, "blarg") print arr.info arr2 = pickle.loads(pickle.dumps(arr)) print arr2.info # no .info attribute! ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] subclassing ndarray and keeping same ufunc behavior
Doh! Thanks for that. On Tue, Nov 15, 2016 at 10:48 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Hi Stuart, > > It certainly seems correct behaviour to return the subclass you > created: after all, you might want to keep the information on > `columns` (e.g., consider doing nanmin along a given axis). Indeed, we > certainly want to keep the unit in astropy's Quantity (which also is a > subclass of ndarray). > > On the shape: shouldn't that be print(np.nanmin(r).shape)?? > > Overall, I think it is worth considering very carefully what exactly > you try to accomplish; if different elements along a given axis have > different meaning, I'm not sure it makes all that much sense to treat > them as a single array (e.g., np.sin might be useful for one column, > not not another). Even if pandas is slower, the advantage in clarity > of what is happening might well be more important in the long run. > > All the best, > > Marten > > p.s. nanmin is not a ufunc; you can find it in numpy/lib/nan_functions.py > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] subclassing ndarray and keeping same ufunc behavior
I'm trying to subclass an ndarray so that I can add some additional fields.
When I do this however, I get new odd behavior when my object is passed to
a variety of numpy functions. For example nanmin returns now return an
object of the type of my new array class, whereas previously I'd get a
float64. Why? Is this a bug with nanmin or my class?
import numpy as np
class NDArrayWithColumns(np.ndarray):
def __new__(cls, obj, columns=None):
obj = obj.view(cls)
obj.columns = tuple(columns)
return obj
def __array_finalize__(self, obj):
if obj is None: return
self.columns = getattr(obj, 'columns', None)
NAN = float("nan")
r = np.array([1.,0.,1.,0.,1.,0.,1.,0.,NAN, 1., 1.])print "MIN",
np.nanmin(r), type(np.nanmin(r))
gives:
MIN 0.0
but
>>> r = NDArrayWithColumns(r, ["a"])>>> print "MIN", np.nanmin(r),
>>> type(np.nanmin(r))
MIN 0.0 >>> print r.shape # ?!(11,)
Note the change in type, and also that str(np.nanmin(r)) shows 1 field, not
11 as indicated by its shape. This seems wrong. Is there a way to get my
subclass to behave more like an ndarray?
I realize from the docs that I can override __array_wrap__, but its not
clear me how how to use it to solve this issue. Or whether its the right
tool.
In case you're interested, I'm subclassing because I'd like to track column
names in matrices of a single type. This is pretty common wish in scikit
pipelines. Structured arrays and record type arrays allow for varying type.
Pandas provides this functionality, but dealing with numpy arrays is easier
(and more efficient) when writing cython extensions. Also, I think the
structured arrays and record types are unlikely to play nice with cython
because they're more freely typed -- I want to deal exclusively with arrays
of doubles.
Any thoughts of how to subclass ndarray and keep original behavior in
ufuncs?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
