Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available
On Thu, Jul 28, 2011 at 8:48 PM, Robert Love wrote: > > On Jul 28, 2011, at 7:42 AM, Martin Ling wrote: > > > On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote: > >> > >> To use quaternions I find I often need conversion to/from matrices and > >> to/from Euler angles. Will you add that functionality? > > > > Yes, I intend to. Note that these conversions are already available in > > the standalone (non-dtype) implementation in imusim.maths.quaternions: > > > > > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler > > > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler > > > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix > > > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix > > > > I should do a new release though - the Euler methods there only support > > ZYX and ZXY order conversions, my development version supports any order. > > > >> Will you handle the left versor and right versor versions? > > > > I don't know what this means. Please enlighten me and I'll be happy to > > try! I thought a 'right versor' was a unit quaternion representing an > > angle of 90 degrees (as in 'right angle') - I don't see what a 'left' > > one would be. > > > > Quaternions have a "handedness" or a sign convention. The recently > departed Space Shuttle used a Left versor convention while most things, > including Space Station, use the right versor convention, in their flight > software. Made for frequent confusion. > > Let me see if I can illustrate by showing the functions I use for > converting a matrix to a quaternion. > > > def Quaternion_Of(m): >""" >Returns a quaternion in the right versor sense. >""" > >q = N.zeros(4,float) > >q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2]) > >q04_inv = 1.0/(4.0*q[0]) >q[1] = (m[1,2] - m[2,1])*q04_inv >q[2] = (m[2,0] - m[0,2])*q04_inv >q[3] = (m[0,1] - m[1,0])*q04_inv > >return q > > > > def Quaternion_Of(m): >""" >Returns a quaternion in the left versor sense. >""" > >q = N.zeros(4,float) > >q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2]) > >q04_inv = 1.0/(4.0*q[0]) >q[1] = (m[2,1] - m[1,2])*q04_inv >q[2] = (m[0,2] - m[2,0])*q04_inv >q[3] = (m[1,0] - m[0,1])*q04_inv > >return q > > > Or transforming a vector using the different conventions. > > > def Transform(q,v): >""" >Returns the vector part of q*vq which transforms v from one >coordinate system to another. Right Versor >""" >u = Q.Vector_Part(q) >return 2.0*(q[0]*N.cross(v,u) + >N.dot(v,u)*u + >(q[0]*q[0] - 0.5)*v) > > > def Transform(q,v): >""" >Returns the vector part of q*vq which transforms v from one >coordinate system to another. Left Versor >""" >u = Q.Vector_Part(q) >return 2.0*(q[0]*N.cross(u,v) + >N.dot(u,v)*u + >(q[0]*q[0] - 0.5)*v) > > So they differ in whether the rotation about the direction of the vector part is left handed or right handed? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available
On Thu, Jul 28, 2011 at 8:48 PM, Robert Love wrote: > > On Jul 28, 2011, at 7:42 AM, Martin Ling wrote: > > > On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote: > >> > >> To use quaternions I find I often need conversion to/from matrices and > >> to/from Euler angles. Will you add that functionality? > > > > Yes, I intend to. Note that these conversions are already available in > > the standalone (non-dtype) implementation in imusim.maths.quaternions: > > > > > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler > > > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler > > > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix > > > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix > > > > I should do a new release though - the Euler methods there only support > > ZYX and ZXY order conversions, my development version supports any order. > > > >> Will you handle the left versor and right versor versions? > > > > I don't know what this means. Please enlighten me and I'll be happy to > > try! I thought a 'right versor' was a unit quaternion representing an > > angle of 90 degrees (as in 'right angle') - I don't see what a 'left' > > one would be. > > > > Quaternions have a "handedness" or a sign convention. The recently > departed Space Shuttle used a Left versor convention while most things, > including Space Station, use the right versor convention, in their flight > software. Made for frequent confusion. > > Let me see if I can illustrate by showing the functions I use for > converting a matrix to a quaternion. > > > def Quaternion_Of(m): >""" >Returns a quaternion in the right versor sense. >""" > >q = N.zeros(4,float) > >q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2]) > >q04_inv = 1.0/(4.0*q[0]) >q[1] = (m[1,2] - m[2,1])*q04_inv >q[2] = (m[2,0] - m[0,2])*q04_inv >q[3] = (m[0,1] - m[1,0])*q04_inv > >return q > > > > def Quaternion_Of(m): >""" >Returns a quaternion in the left versor sense. >""" > >q = N.zeros(4,float) > >q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2]) > >q04_inv = 1.0/(4.0*q[0]) >q[1] = (m[2,1] - m[1,2])*q04_inv >q[2] = (m[0,2] - m[2,0])*q04_inv >q[3] = (m[1,0] - m[0,1])*q04_inv > >return q > > > Or transforming a vector using the different conventions. > > > def Transform(q,v): >""" >Returns the vector part of q*vq which transforms v from one >coordinate system to another. Right Versor >""" >u = Q.Vector_Part(q) >return 2.0*(q[0]*N.cross(v,u) + >N.dot(v,u)*u + >(q[0]*q[0] - 0.5)*v) > > > def Transform(q,v): >""" >Returns the vector part of q*vq which transforms v from one >coordinate system to another. Left Versor >""" >u = Q.Vector_Part(q) >return 2.0*(q[0]*N.cross(u,v) + >N.dot(u,v)*u + >(q[0]*q[0] - 0.5)*v) > > > > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ticket 1793
2011/7/28 Stéfan van der Walt : > On Thu, Jul 28, 2011 at 2:05 PM, Paul Anton Letnes > wrote: >> In my quest for a bug-free numpy I have, I think, fixed ticket 1793. >> https://github.com/numpy/numpy/pull/123 > > This brings up an interesting question. When raising warnings, they > only show for the first time, unless the system is specially > configured. Note that the contents of the message is taken into account; *unique* messages only show up for the first time, but different messages for the same warning issued from the same place will all appear. Taking a quick glance at the pull request, it looks like the filename is included in the message, so the warning will appear once for each file that needs to be warned about. This seems entirely appropriate behavior to me. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available
On Thu, Jul 28, 2011 at 21:48, Robert Love wrote: > > On Jul 28, 2011, at 7:42 AM, Martin Ling wrote: > >> On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote: >>> >>> To use quaternions I find I often need conversion to/from matrices and >>> to/from Euler angles. Will you add that functionality? >> >> Yes, I intend to. Note that these conversions are already available in >> the standalone (non-dtype) implementation in imusim.maths.quaternions: >> >> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler >> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler >> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix >> http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix >> >> I should do a new release though - the Euler methods there only support >> ZYX and ZXY order conversions, my development version supports any order. >> >>> Will you handle the left versor and right versor versions? >> >> I don't know what this means. Please enlighten me and I'll be happy to >> try! I thought a 'right versor' was a unit quaternion representing an >> angle of 90 degrees (as in 'right angle') - I don't see what a 'left' >> one would be. >> > > Quaternions have a "handedness" or a sign convention. The recently departed > Space Shuttle used a Left versor convention while most things, including > Space Station, use the right versor convention, in their flight software. > Made for frequent confusion. For what it's worth, I have found this paper by James Diebel to be the most complete listing of all of the different conventions and conversions amongst quaternions, Euler angles, and rotation vectors: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.110.5134 -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available
On Jul 28, 2011, at 7:42 AM, Martin Ling wrote: > On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote: >> >> To use quaternions I find I often need conversion to/from matrices and >> to/from Euler angles. Will you add that functionality? > > Yes, I intend to. Note that these conversions are already available in > the standalone (non-dtype) implementation in imusim.maths.quaternions: > > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix > http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix > > I should do a new release though - the Euler methods there only support > ZYX and ZXY order conversions, my development version supports any order. > >> Will you handle the left versor and right versor versions? > > I don't know what this means. Please enlighten me and I'll be happy to > try! I thought a 'right versor' was a unit quaternion representing an > angle of 90 degrees (as in 'right angle') - I don't see what a 'left' > one would be. > Quaternions have a "handedness" or a sign convention. The recently departed Space Shuttle used a Left versor convention while most things, including Space Station, use the right versor convention, in their flight software. Made for frequent confusion. Let me see if I can illustrate by showing the functions I use for converting a matrix to a quaternion. def Quaternion_Of(m): """ Returns a quaternion in the right versor sense. """ q = N.zeros(4,float) q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2]) q04_inv = 1.0/(4.0*q[0]) q[1] = (m[1,2] - m[2,1])*q04_inv q[2] = (m[2,0] - m[0,2])*q04_inv q[3] = (m[0,1] - m[1,0])*q04_inv return q def Quaternion_Of(m): """ Returns a quaternion in the left versor sense. """ q = N.zeros(4,float) q[0] = 0.5*sqrt(1.0 + m[0,0] + m[1,1] + m[2,2]) q04_inv = 1.0/(4.0*q[0]) q[1] = (m[2,1] - m[1,2])*q04_inv q[2] = (m[0,2] - m[2,0])*q04_inv q[3] = (m[1,0] - m[0,1])*q04_inv return q Or transforming a vector using the different conventions. def Transform(q,v): """ Returns the vector part of q*vq which transforms v from one coordinate system to another. Right Versor """ u = Q.Vector_Part(q) return 2.0*(q[0]*N.cross(v,u) + N.dot(v,u)*u + (q[0]*q[0] - 0.5)*v) def Transform(q,v): """ Returns the vector part of q*vq which transforms v from one coordinate system to another. Left Versor """ u = Q.Vector_Part(q) return 2.0*(q[0]*N.cross(u,v) + N.dot(u,v)*u + (q[0]*q[0] - 0.5)*v) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can I index array starting with 1?
On 29.07.2011, at 1:38AM, Anne Archibald wrote: > The can is open and the worms are everywhere, so: > > The big problem with one-based indexing for numpy is interpretation. > In python indexing, -1 is the last element of the array, and ranges > have a specific meaning. In a hypothetical one-based indexing scheme, > would the last element be element 0? if not, what does looking up zero > do? What about ranges - do ranges still include the first endpoint and > not the second? I suppose one could choose the most pythonic of the > 1-based conventions, but do any of them provide from-the-end indexing > without special syntax? > I forgot, this definitely needs to be preserved for ndarray! > Once one had decided what to do, implementation would be pretty easy - > just make a subclass of ndarray that replaces the indexing function. In fact, Stéfan's reshuffling trick does nearly everything I would expect for using negative indices, maybe the only functionality needed to implement is 1. define an attribute like x.start that could tell appropriate functions (e.g. for print(x) or plot(x)) the "zero-point", so x would be evaluated e.g. at x[-5], wrapping around at [x-1], x[0] to x[-6]... Should have the advantage that anything that's not yet aware of this attribute could simply ignore it. 2. allow to automatically set this starting point when creating something like "x = np.zeros(-5:7)" or setting a shape to (-5:7) - but maybe the latter is leading into very dangerous territory already... Cheers, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can I index array starting with 1?
The can is open and the worms are everywhere, so: The big problem with one-based indexing for numpy is interpretation. In python indexing, -1 is the last element of the array, and ranges have a specific meaning. In a hypothetical one-based indexing scheme, would the last element be element 0? if not, what does looking up zero do? What about ranges - do ranges still include the first endpoint and not the second? I suppose one could choose the most pythonic of the 1-based conventions, but do any of them provide from-the-end indexing without special syntax? Once one had decided what to do, implementation would be pretty easy - just make a subclass of ndarray that replaces the indexing function. Anne On 28 July 2011 19:26, Derek Homeier wrote: > On 29.07.2011, at 1:19AM, Stéfan van der Walt wrote: > >> On Thu, Jul 28, 2011 at 4:10 PM, Anne Archibald >> wrote: >>> Don't forget the everything-looks-like-a-nail approach: make all your >>> arrays one bigger than you need and ignore element zero. >> >> Hehe, why didn't I think of that :) >> >> I guess the kind of problem I struggle with more frequently is books >> written with summations over -m to +n. In those cases, it's often >> convenient to use the mapping function, so that I can enter the >> formulas as they occur. > > I don't want to open any cans of worms at this point, but given that > Fortran90 supports such indexing (arbitrary limits, including negative ones), > there definitely are use cases for it (or rather, instances where it is very > convenient at least, like in Stéfan's books). So I am wondering how much it > would take to implement such an enhancement for the standard ndarray... > > Cheers, > Derek > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can I index array starting with 1?
On Thu, Jul 28, 2011 at 4:26 PM, Derek Homeier wrote: >> I guess the kind of problem I struggle with more frequently is books >> written with summations over -m to +n. In those cases, it's often >> convenient to use the mapping function, so that I can enter the >> formulas as they occur. > > I don't want to open any cans of worms at this point, but given that > Fortran90 supports such indexing (arbitrary limits, including negative ones), > there definitely are use cases for it (or rather, instances where it is very > convenient at least, like in Stéfan's books). So I am wondering how much it > would take to implement such an enhancement for the standard ndarray... Thinking about it, expanding on Anne's solution and the fact that Python allows negative indexing, you can simply reshuffle the array after operations a bit and have everything work out. import numpy as np n = -5 m = 7 x = np.zeros((m - n), dtype=float) # Do some operation with n..m based indexing for i in range(-5, 7): x[i] = i # Construct the output x = np.hstack((x[n:], x[:m])) print x Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can I index array starting with 1?
On 29.07.2011, at 1:19AM, Stéfan van der Walt wrote: > On Thu, Jul 28, 2011 at 4:10 PM, Anne Archibald > wrote: >> Don't forget the everything-looks-like-a-nail approach: make all your >> arrays one bigger than you need and ignore element zero. > > Hehe, why didn't I think of that :) > > I guess the kind of problem I struggle with more frequently is books > written with summations over -m to +n. In those cases, it's often > convenient to use the mapping function, so that I can enter the > formulas as they occur. I don't want to open any cans of worms at this point, but given that Fortran90 supports such indexing (arbitrary limits, including negative ones), there definitely are use cases for it (or rather, instances where it is very convenient at least, like in Stéfan's books). So I am wondering how much it would take to implement such an enhancement for the standard ndarray... Cheers, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dtype repr change?
Hi, 2011/7/28 Stéfan van der Walt : > On Thu, Jul 28, 2011 at 1:48 PM, Matthew Brett > wrote: >> The thread was first about how to deal with the change, and second > > I'm still curious to know of a technical solution with doctests. > Ideally, one would like to specify a set of rules that a line must > pass to know whether it matched. The current system of excluding > certain checks with "+SKIP" flags etc. seems fragile. Well - you can use the +ELLIPSIS flag, but of course you have ugly and confusing ... in the docstring for the variable bits. > Maybe a person can already do that, I'm not sure? But it would be > handy to simply have an extra rule added that said: "In any line-set > starting with 'array', ignore everything after dtype=" for example. > Then each package would be able to keep a customised set of rules. > > Do you know if doctests supports any sort of manual intervention, like > a plugin system? Actually, I was going to ask you that question :) But yes, there's the NumpyDoctest nose plugin, for example. Using it does mean you have to customize nose somehow - in numpy's case by using the 'numpy.test()' machinery. Sympy I believe has a fair amount of machinery to work with doctests, but I haven't looked at that yet, See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can I index array starting with 1?
On Thu, Jul 28, 2011 at 4:10 PM, Anne Archibald wrote: > Don't forget the everything-looks-like-a-nail approach: make all your > arrays one bigger than you need and ignore element zero. Hehe, why didn't I think of that :) I guess the kind of problem I struggle with more frequently is books written with summations over -m to +n. In those cases, it's often convenient to use the mapping function, so that I can enter the formulas as they occur. Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can I index array starting with 1?
Don't forget the everything-looks-like-a-nail approach: make all your arrays one bigger than you need and ignore element zero. Anne On 7/28/11, Stéfan van der Walt wrote: > Hi Jeremy > > On Thu, Jul 28, 2011 at 3:19 PM, Jeremy Conlin wrote: >> I have a need to index my array(s) starting with a 1 instead of a 0. >> The reason for this is to be consistent with the documentation of a >> format I'm accessing. I know I can just '-1' from what the >> documentation says, but that can get cumbersome. >> >> Is there a magic flag I can pass to a numpy array (maybe when it is >> created) so I can index starting at 1 instead of the Python default? > > You may want to have a look at some of the labeled array packages out > there, such as larry, datarray, pandas, etc. I'm sure at least one of > them allows integer re-labelling, although I'm not certain whether it > can be done in a programmatic fashion. > > An alternative may be to create an indexing function that remaps the > input space, e.g.: > > def ix(n): > return n - 1 > > x[ix(3), ix(5)] > > But that looks pretty nasty, and you'll have to expand ix quite a bit > to handle slices, etc. :/ > > Stéfan > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Sent from my mobile device ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can I index array starting with 1?
Hi Jeremy On Thu, Jul 28, 2011 at 3:19 PM, Jeremy Conlin wrote: > I have a need to index my array(s) starting with a 1 instead of a 0. > The reason for this is to be consistent with the documentation of a > format I'm accessing. I know I can just '-1' from what the > documentation says, but that can get cumbersome. > > Is there a magic flag I can pass to a numpy array (maybe when it is > created) so I can index starting at 1 instead of the Python default? You may want to have a look at some of the labeled array packages out there, such as larry, datarray, pandas, etc. I'm sure at least one of them allows integer re-labelling, although I'm not certain whether it can be done in a programmatic fashion. An alternative may be to create an indexing function that remaps the input space, e.g.: def ix(n): return n - 1 x[ix(3), ix(5)] But that looks pretty nasty, and you'll have to expand ix quite a bit to handle slices, etc. :/ Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ticket 1793
On Thu, Jul 28, 2011 at 2:05 PM, Paul Anton Letnes wrote: > In my quest for a bug-free numpy I have, I think, fixed ticket 1793. > https://github.com/numpy/numpy/pull/123 This brings up an interesting question. When raising warnings, they only show for the first time, unless the system is specially configured. Should we consider sending messages to a logger as well? Is there already a way of handling this in numpy? Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dtype repr change?
On Thu, Jul 28, 2011 at 1:48 PM, Matthew Brett wrote: > The thread was first about how to deal with the change, and second I'm still curious to know of a technical solution with doctests. Ideally, one would like to specify a set of rules that a line must pass to know whether it matched. The current system of excluding certain checks with "+SKIP" flags etc. seems fragile. Maybe a person can already do that, I'm not sure? But it would be handy to simply have an extra rule added that said: "In any line-set starting with 'array', ignore everything after dtype=" for example. Then each package would be able to keep a customised set of rules. Do you know if doctests supports any sort of manual intervention, like a plugin system? Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Can I index array starting with 1?
I have a need to index my array(s) starting with a 1 instead of a 0. The reason for this is to be consistent with the documentation of a format I'm accessing. I know I can just '-1' from what the documentation says, but that can get cumbersome. Is there a magic flag I can pass to a numpy array (maybe when it is created) so I can index starting at 1 instead of the Python default? Thanks, Jeremy ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] ticket 1793
Hi! In my quest for a bug-free numpy I have, I think, fixed ticket 1793. https://github.com/numpy/numpy/pull/123 Enjoy - feedback welcome, of course. Cheers, Paul. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dtype repr change?
Hi, 2011/7/28 Stéfan van der Walt : > On Thu, Jul 28, 2011 at 10:19 AM, Matthew Brett > wrote: >> I don't think anyone suggested that doctests should replace unit >> tests; it's a bit difficult to see why that discussion started. > > The conversation started because array([True], dtype=bool) changed to > array([True], dtype='bool') or something along those lines. A > reasonable expectation is that eval(repr(x)) should produce x. An > unreasonable expectation is to expect the repr string to remain > exactly the same over versions (as doctest does). > > So, while there seems to be a simple solution in this case, I don't > think the change was unreasonable or wrong. I don't think you'll find anyone saying the change was unreasonable or wrong. It wouldn't really matter if it was, Mark's making a lot of changes, and if some of them are wrong, that's just how it goes when you change stuff. The thread was first about how to deal with the change, and second about the tone of Mark's - and I suppose my own - replies. See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dtype repr change?
On Thu, Jul 28, 2011 at 10:19 AM, Matthew Brett wrote: > I don't think anyone suggested that doctests should replace unit > tests; it's a bit difficult to see why that discussion started. The conversation started because array([True], dtype=bool) changed to array([True], dtype='bool') or something along those lines. A reasonable expectation is that eval(repr(x)) should produce x. An unreasonable expectation is to expect the repr string to remain exactly the same over versions (as doctest does). So, while there seems to be a simple solution in this case, I don't think the change was unreasonable or wrong. Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dtype repr change?
I have a different question about this than the rest of the thread. I'm
confused at why there isn't a programmatic way to create a datetime dtype,
other than by going through this special string-based mini-language. I guess
I generally think of string-based dtype descriptors as being a legacy thing
necessary for compatibility, but probably better to avoid in new code, now
that we have nice python ways to describe dtypes with scalar types and such.
Probably that's a minority opinion, but even putting it aside: it certainly
isn't the case that we can describe arbitrary dtypes using strings right now
- think of record types and so on. And even restricting ourselves to atomic
styles, I'm skeptical about this claim that we'll be able to use strings for
everything in the future, too. My pet possible future dtype is one for
categorical data, which would be parametrized by the set of possible
categories; I don't relish the idea of making up some ad hoc syntax for
specifying such lists within the dtype mini-language.
So is the plan actually to promote strings as the canonical way of
describing dtypes? Aside from the question of what repr does, shouldn't
there actually be some sort of syntax like dtype=np.datetime64("D")
available as a working option?
- Nathaniel
On Jul 27, 2011 10:55 AM, "Mark Wiebe" wrote:
> This was the most consistent way to deal with the parameterized dtype in
the
> repr, making it more future-proof at the same time. It was producing reprs
> like "array(['2011-01-01'], dtype=datetime64[D])", which is clearly wrong,
> and putting quotes around it makes it work in general for all possible
> dtypes, present and future.
>
> -Mark
>
> On Wed, Jul 27, 2011 at 12:50 PM, Matthew Brett wrote:
>
>> Hi,
>>
>> I see that (current trunk):
>>
>> In [9]: np.ones((1,), dtype=bool)
>> Out[9]: array([ True], dtype='bool')
>>
>> - whereas (1.5.1):
>>
>> In [2]: np.ones((1,), dtype=bool)
>> Out[2]: array([ True], dtype=bool)
>>
>> That is breaking quite a few doctests. What is the reason for the
>> change? Something to do with more planned dtypes?
>>
>> Thanks a lot,
>>
>> Matthew
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dtype repr change?
Hi, On Thu, Jul 28, 2011 at 10:13 AM, Ralf Gommers wrote: > > > On Thu, Jul 28, 2011 at 1:29 AM, Gael Varoquaux > wrote: >> >> On Wed, Jul 27, 2011 at 05:25:20PM -0600, Charles R Harris wrote: >> > Well, doc tests are just a losing proposition, no one should be using >> > them >> > for writing tests. It's not like this is a new discovery, doc tests >> > have >> > been known to be unstable for years. >> >> Untested documentation is broken in my experience. This is why I do rely >> a lot on doctests. > > Rely as in making sure that the examples run once in a while and before a > release is of course a good idea. Failures can be inspected and ignored if > there are only minor differences in string representation. I think automated and frequent testing of the doctests considerably reduces the risk of broken documentation. If the code-base gets big enough, scanning the errors by eye isn't efficient, and the result can only be running the tests less often and detecting errors less often. > Relying on doctests as in "they replace the unit tests I should also have > written" is another thing altogether - unnecessary and expecting an > unrealistic level of backward compatibility. That of course doesn't mean > things in numpy should change without a good reason, but it seems there was > one. I don't think anyone suggested that doctests should replace unit tests; it's a bit difficult to see why that discussion started. Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dtype repr change?
On Thu, Jul 28, 2011 at 1:29 AM, Gael Varoquaux < gael.varoqu...@normalesup.org> wrote: > On Wed, Jul 27, 2011 at 05:25:20PM -0600, Charles R Harris wrote: > >Well, doc tests are just a losing proposition, no one should be using > them > >for writing tests. It's not like this is a new discovery, doc tests > have > >been known to be unstable for years. > > Untested documentation is broken in my experience. This is why I do rely > a lot on doctests. > Rely as in making sure that the examples run once in a while and before a release is of course a good idea. Failures can be inspected and ignored if there are only minor differences in string representation. Relying on doctests as in "they replace the unit tests I should also have written" is another thing altogether - unnecessary and expecting an unrealistic level of backward compatibility. That of course doesn't mean things in numpy should change without a good reason, but it seems there was one. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rationale for returning type-wrapped min() / max() scalars? (was: Problem with ufunc of a numpy.ndarray derived class)
Hi, On Thu, Jul 28, 2011 at 7:58 AM, Hans Meine wrote: > Hi again! > > Am Donnerstag, 21. Juli 2011, 16:56:21 schrieb Hans Meine: >> import numpy >> >> class Test(numpy.ndarray): >> pass >> >> a1 = numpy.ndarray((1,)) >> a2 = Test((1,)) >> >> assert type(a1.min()) == type(a2.min()), \ >> "%s != %s" % (type(a1.min()), type(a2.min())) >> # --- >> >> This code fails with 1.6.0, while it worked in 1.3.0. > > I just tried with 1.5.1 (Ubuntu natty), and it works, too. > > Thus, this behavor-incompatible change happened between 1.5.1 and 1.6.0. > >> I tend to think that this is a bug (after all, a1.min() does not return >> ndarray, but an array scalar), but maybe there is also a good reason for >> this (for us, unexpected) behavor change and a nice solution? > > Unfortunately, I did not receive any answers so far. Sorry about the lack of replies. If I understand you correctly, the problem is that, for 1.5.1: >>> class Test(np.ndarray): pass >>> type(np.min(Test((1, and for 1.6.0 (and current trunk): >>> class Test(np.ndarray): pass >>> type(np.min(Test((1, So, 1.6.0 is returning a zero-dimensional scalar of the given type, and 1.5.1 returns a python scalar. Zero dimensional scalars are designed to behave in a similar way to python scalars, so the change should be all but invisible in practice. Was there a particular case you ran into where this was a problem? Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Rationale for returning type-wrapped min() / max() scalars? (was: Problem with ufunc of a numpy.ndarray derived class)
Hi again! Am Donnerstag, 21. Juli 2011, 16:56:21 schrieb Hans Meine: > import numpy > > class Test(numpy.ndarray): > pass > > a1 = numpy.ndarray((1,)) > a2 = Test((1,)) > > assert type(a1.min()) == type(a2.min()), \ > "%s != %s" % (type(a1.min()), type(a2.min())) > # --- > > This code fails with 1.6.0, while it worked in 1.3.0. I just tried with 1.5.1 (Ubuntu natty), and it works, too. Thus, this behavor-incompatible change happened between 1.5.1 and 1.6.0. > I tend to think that this is a bug (after all, a1.min() does not return > ndarray, but an array scalar), but maybe there is also a good reason for > this (for us, unexpected) behavor change and a nice solution? Unfortunately, I did not receive any answers so far. Have a nice day, Hans ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Issues with adding new dtypes - customizing ndarray attributes
Hi, I'd like to kick off some discussion on general issues I've encountered while developing the quaternion dtype (see other thread, and the code at: https://github.com/martinling/numpy_quaternion) The basic issue is that the attributes of ndarray cannot be adapted to the dtype of a given array. Indeed, their behaviour can't be changed at all without patching numpy itself. There are essentially four cases of the problem: 1. Attributes which do the wrong thing even though there is a mechanism that should let them do the right thing, e.g: >>> a = array([quaternion(1,2,3,4), quaternion(5,6,7,8)]) >>> conjugate(a) # correct, calls conjugate ufunc I defined array([quaternion(1, -2, -3, -4), quaternion(5, -6, -7, -8)], dtype=quaternion) >>> a.conjugate() # incorrect, why doesn't it do the same? array([quaternion(1, 2, 3, 4), quaternion(5, 6, 7, 8)], dtype=quaternion) >>> min(a) # works, calls min ufunc I defined quaternion(1, 2, 3, 4) >>> a.min() # fails, why doesn't it do the same? ValueError: No cast function available. 2. Attributes that do the wrong thing with no mechanism to override them: >>> array([q.real for q in a]) array([ 1., 5.]) >>> a.real # would like this to return the same, can't make it do so array([quaternion(1, 2, 3, 4), quaternion(5, 6, 7, 8)], dtype=quaternion) 3. Attributes that don't exist and could be added to suit the dtype: >>> array([q.y for q in a]) array([ 3., 7.]) >>> a.y # would like this to return the same, can't make it do so AttributeError: 'numpy.ndarray' object has no attribute 'y' 4. Attributes that already exist and make no sense for some dtypes: >>> sa = array(['foo', 'bar', 'baz']) >>> sa.imag # why can I even do this? array(['', '', ''], dtype='|S3') We had ѕome discussion about this at the SciPy conference sprints and the consensus seemed to be that allowing dtypes to customize the attributes of ndarrays would be a good thing. This would also be useful for struct arrays, datetime arrays, etc. What do people think? Martin ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Quaternion dtype for NumPy - initial implementation available
On Wed, Jul 27, 2011 at 10:29:08PM -0500, Robert Love wrote: > > To use quaternions I find I often need conversion to/from matrices and > to/from Euler angles. Will you add that functionality? Yes, I intend to. Note that these conversions are already available in the standalone (non-dtype) implementation in imusim.maths.quaternions: http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromEuler http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toEuler http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#setFromMatrix http://www.imusim.org/docs/api/imusim.maths.quaternions.Quaternion-class.html#toMatrix I should do a new release though - the Euler methods there only support ZYX and ZXY order conversions, my development version supports any order. > Will you handle the left versor and right versor versions? I don't know what this means. Please enlighten me and I'll be happy to try! I thought a 'right versor' was a unit quaternion representing an angle of 90 degrees (as in 'right angle') - I don't see what a 'left' one would be. Martin ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] C-API: PyTypeObject* for NumPy scalar types
How do I get the PyTypeObject* for a NumPy scalar type such as np.uint8? (The reason I'm asking is the following: I'm writing a C++ extension module. The Python interface to the module has a function f that takes a NumPy scalar type as an argument, for instance f(np.uint8). Then the corresponding C++ function receives a PyObject* and needs to decide which type object it points to.) --Johan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
