Re: [Numpy-discussion] dtype from |S10 to object in array?
Assignment will never change the data-type of an already allocated array. So,
x['f2'] = y will try to convert the array to 'S10'.
On my system I get:
array([(1, 2.0, 'Hello'), (2, 3.0, 'World')],
dtype=[('f0', ' Dear All,
>
> See below code pls,
>
> import sicpy
> import numpy as np
>
> x = np.zeros((2,),dtype=('i4,f4,a10'))
> x[:] = [(1,2.,'Hello'),(2,3.,"World")]
>
> y = x['f2']
> #array(['Hello', 'World'],
> dtype='|S10')
>
> x['f2'] = y
> x
> #array([(1, 2.0, 'Hello'), (2, 3.0, 'World')],
> dtype=[('f0', '
> y = y.astype('object')
> y
> array([Hello, World], dtype=object)
>
>
> x['f2'] = y
> array([(1, 2.0, 'HellWorld'), (2, 3.0, '\x00\x00\x00\x00\x00\x00\x18')],
> dtype=[('f0', '
> ##here comes the problem: the f2 col type has not been changed and the
> data is not I wanted...
>
>
> here is why I need using this:
> suppose I have a datasource, csv, sql based db or what ever look like this:
>
> 1, 2.0, 'Hello'
> 2, 3.0, 'World'
> 3, 2.0, 'other string'
>
> I want to read them to a numpy array and process it's columns, it has no
> problem for processing the float or int type but string.
> After reading the manual and found the object dtype may store variable
> string then I want to exact the string col into an new array, try to
> process it then store back to the numpy "matrix" then store it back to
> the data source.
>
> May I know how I can do that? I do not care performance now.
>
>
> Thanks for any hints
>
> Rgs,
>
> KC
>
>
>
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
---
Travis Oliphant
Enthought, Inc.
oliph...@enthought.com
1-512-536-1057
http://www.enthought.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [PATCH] F2Py on Python 3
On Thu, Sep 23, 2010 at 7:22 PM, Lisandro Dalcin wrote:
> On 23 September 2010 01:26, Charles R Harris
> wrote:
> >
> >
> > On Wed, Sep 22, 2010 at 10:00 PM, Charles R Harris
> > wrote:
> >>
> >>
> >> On Wed, Sep 22, 2010 at 9:14 PM, Fernando Perez
> >> wrote:
> >>>
> >>> On Wed, Sep 22, 2010 at 7:16 PM, Charles R Harris
> >>> wrote:
> >>> >
> >>> > Done in 29cccb6.
> >>> >
> >>>
> >>> Mmh, I think it broke something:
> >>>
> >>> File
> >>> "/home/fperez/tmp/src/scipy/numpy/numpy/distutils/command/build.py",
> >>> line 37, in run
> >>>old_build.run(self)
> >>> File "/usr/lib/python2.6/distutils/command/build.py", line 135, in run
> >>>self.run_command(cmd_name)
> >>> File "/usr/lib/python2.6/distutils/cmd.py", line 333, in run_command
> >>>self.distribution.run_command(command)
> >>> File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
> >>>cmd_obj.run()
> >>> File
> >>>
> "/home/fperez/tmp/src/scipy/numpy/numpy/distutils/command/build_scripts.py",
> >>> line 39, in run
> >>>self.scripts = self.generate_scripts(self.scripts)
> >>> File
> >>>
> "/home/fperez/tmp/src/scipy/numpy/numpy/distutils/command/build_scripts.py",
> >>> line 24, in generate_scripts
> >>>script = func(build_dir)
> >>> File "numpy/f2py/setup.py", line 78, in generate_f2py_py
> >>>'''%(os.path.basename(sys.executable)))
> >>> TypeError: not enough arguments for format string
> >>>
> >>> If I revert to the previous commit, it installs fine again.
> >>>
> >>
> >> I wondered about that, it is probably the old `mode` vs plain old mode.
> I
> >> had just hoped it was tested. Can you check that out?
> >>
> >
> > Should be fixed in 8f6114b.
> >
>
> I had just hoped it was tested... [sorry, I could not resist! ;-) ]
>
> diff --git a/numpy/f2py/setup.py b/numpy/f2py/setup.py
> index aac3d33..37aab19 100644
> --- a/numpy/f2py/setup.py
> +++ b/numpy/f2py/setup.py
> @@ -62,7 +62,7 @@ for mode in ["g3-numpy", "2e-numeric",
> "2e-numarray", "2e-numpy
> except ValueError: pass
> os.environ["NO_SCIPY_IMPORT"]="f2py"
> if mode=="g3-numpy":
> -sys.stderr.write("G3 f2py support is not implemented, yet.\n")
> +sys.stderr.write("G3 f2py support is not implemented, yet.\\n")
> sys.exit(1)
> elif mode=="2e-numeric":
> from f2py2e import main
> @@ -72,7 +72,7 @@ elif mode=="2e-numarray":
> elif mode=="2e-numpy":
> from numpy.f2py import main
> else:
> -sys.stderr.write("Unknown mode: " + repr(mode) + "\n")
> +sys.stderr.write("Unknown mode: " + repr(mode) + "\\n")
> sys.exit(1)
> main()
> '''%(os.path.basename(sys.executable)))
>
>
Arrggg, I forgot the double backslashes :-(
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [PATCH] F2Py on Python 3
On 23 September 2010 01:26, Charles R Harris wrote:
>
>
> On Wed, Sep 22, 2010 at 10:00 PM, Charles R Harris
> wrote:
>>
>>
>> On Wed, Sep 22, 2010 at 9:14 PM, Fernando Perez
>> wrote:
>>>
>>> On Wed, Sep 22, 2010 at 7:16 PM, Charles R Harris
>>> wrote:
>>> >
>>> > Done in 29cccb6.
>>> >
>>>
>>> Mmh, I think it broke something:
>>>
>>> File
>>> "/home/fperez/tmp/src/scipy/numpy/numpy/distutils/command/build.py",
>>> line 37, in run
>>> old_build.run(self)
>>> File "/usr/lib/python2.6/distutils/command/build.py", line 135, in run
>>> self.run_command(cmd_name)
>>> File "/usr/lib/python2.6/distutils/cmd.py", line 333, in run_command
>>> self.distribution.run_command(command)
>>> File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
>>> cmd_obj.run()
>>> File
>>> "/home/fperez/tmp/src/scipy/numpy/numpy/distutils/command/build_scripts.py",
>>> line 39, in run
>>> self.scripts = self.generate_scripts(self.scripts)
>>> File
>>> "/home/fperez/tmp/src/scipy/numpy/numpy/distutils/command/build_scripts.py",
>>> line 24, in generate_scripts
>>> script = func(build_dir)
>>> File "numpy/f2py/setup.py", line 78, in generate_f2py_py
>>> '''%(os.path.basename(sys.executable)))
>>> TypeError: not enough arguments for format string
>>>
>>> If I revert to the previous commit, it installs fine again.
>>>
>>
>> I wondered about that, it is probably the old `mode` vs plain old mode. I
>> had just hoped it was tested. Can you check that out?
>>
>
> Should be fixed in 8f6114b.
>
I had just hoped it was tested... [sorry, I could not resist! ;-) ]
diff --git a/numpy/f2py/setup.py b/numpy/f2py/setup.py
index aac3d33..37aab19 100644
--- a/numpy/f2py/setup.py
+++ b/numpy/f2py/setup.py
@@ -62,7 +62,7 @@ for mode in ["g3-numpy", "2e-numeric",
"2e-numarray", "2e-numpy
except ValueError: pass
os.environ["NO_SCIPY_IMPORT"]="f2py"
if mode=="g3-numpy":
-sys.stderr.write("G3 f2py support is not implemented, yet.\n")
+sys.stderr.write("G3 f2py support is not implemented, yet.\\n")
sys.exit(1)
elif mode=="2e-numeric":
from f2py2e import main
@@ -72,7 +72,7 @@ elif mode=="2e-numarray":
elif mode=="2e-numpy":
from numpy.f2py import main
else:
-sys.stderr.write("Unknown mode: " + repr(mode) + "\n")
+sys.stderr.write("Unknown mode: " + repr(mode) + "\\n")
sys.exit(1)
main()
'''%(os.path.basename(sys.executable)))
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Commit mailing list
Hi all, The commit mailing list is running again. Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] slicing / indexing question
Hi Brett, Josef, Gökhan, and Anne, Many thanks for the suggestions! This indexing problem was not as straight-forward as I had anticipated. I have it working now, thanks to your help. Gökhan, I'm driving an ecosystem--atmosphere carbon dioxide flux model with MODIS measurements, so this_par and pars are parameter values that I need to combine with the measurements. The arrays represent time series of model parameters and MODIS reflectances and land surface products (enhanced vegetation index, land cover class, vegetation dynamics) at 1 km resolution for 1200 km by 1200 km "tiles". There are lots of IDL and Matlab folks in my department too. I've been using R and, more recently, Scipy... Being able to test out code offline on my own machine without worrying about licenses (not only cost but also talking to license servers, availability of site licenses, etc.) is a big big help! Along those lines, many thanks also to all who have put so much time and energy into developing python and Scipy. It's a great platform! -Tim On Wed, Sep 2010, 22 at 02:22:50PM -0400, Anne Archibald wrote: > On 21 September 2010 19:20, Timothy W. Hilton wrote: > > > I have an 80x1200x1200 nd.array of floats this_par. I have a > > 1200x1200 boolean array idx, and an 80-element float array pars. For > > each element of idx that is True, I wish to replace the corresponding > > 80x1x1 slice of this_par with the elements of pars. > > > > I've tried lots of variations on the theme of > this_par[idx[np.newaxis, ...]] = pars[:, np.newaxis, np.newaxis] > > but so far, no dice. > > How about this? > > > In [1]: A = np.zeros((2,3,5)) > > In [2]: B = np.array([1,2]) > > In [3]: C = np.zeros((3,5), dtype=np.bool) > > In [4]: C[1,1] = True > > In [5]: C[2,3] = True > > In [6]: C > Out[6]: > array([[False, False, False, False, False], >[False, True, False, False, False], >[False, False, False, True, False]], dtype=bool) > > In [7]: A[:,C] = B[:,np.newaxis] > > In [8]: A > Out[8]: > array([[[ 0., 0., 0., 0., 0.], > [ 0., 1., 0., 0., 0.], > [ 0., 0., 0., 1., 0.]], > >[[ 0., 0., 0., 0., 0.], > [ 0., 2., 0., 0., 0.], > [ 0., 0., 0., 2., 0.]]]) > > The key is that indexing with C replaces the two axes C is indexing > with only one; boolean indexing necessarily flattens the relevant > axes. You can check this with (e.g.) A[:,C].shape. > > Be careful with these "mixed" indexing modes (partly fancy indexing, > partly slicing) as they can sometimes seem to reorder your axes for > you: > > In [16]: np.zeros((2,3,7))[:,np.ones(5,dtype=int),np.ones(5,dtype=int)].shape > Out[16]: (2, 5) > > In [17]: np.zeros((2,3,7))[np.ones(5,dtype=int),:,np.ones(5,dtype=int)].shape > Out[17]: (5, 3) > > In [18]: np.zeros((2,3,7))[np.ones(5,dtype=int),np.ones(5,dtype=int),:].shape > Out[18]: (5, 7) > > Anne > ___ > 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] A proposed change to rollaxis() behavior for negative 'start' values
On Tue, Sep 21, 2010 at 12:48 PM, Ken Basye wrote:
> If that's going to break too much code, here's a pathway that might be
> acceptable: Add a new function moveaxis() which works the way
> rollaxis() does for positive arguments but in the new way for negative
> arguments. Eventually, rollaxis could be deprecated to keep things
> tidy. This has the added advantage of using a name that seems to fit
> what the function does better - 'rollaxis' suggests a behavior like the
> roll() function which affects other axes, which isn't what happens.
My 2 cents: +1 on a new function, but I'd change the behavior for
positive arguments too.
Currently, the API is (AFAICT): You give the index of the axis you
want to move, and you give the index of the axis that you want the
first axis to be moved in front of. This is super confusing!
I propose that a much better API would be: You give the index of the
axis you want to move, and you give the index you *want* that axis to
have. So we'd have the invariant:
b = np.moveaxis(a, i, j)
assert a.shape[i] == b.shape[j]
This is way easier to think about, at least for me. And it solves the
problem with negative indices too.
BTW, note that that the documentation for rollaxis is actually
self-contradictory at the moment:
http://docs.scipy.org/doc/numpy/reference/generated/numpy.rollaxis.html
At the top it seems to document the behavior that I propose ("Roll the
specified axis backwards, until it lies *in a given* position."), and
then in the details it describes the actual behavior("The axis is
rolled until it lies *before* this position"). I take this as further
evidence that the current behavior is unnatural and confusing :-).
-- Nathaniel
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A proposed change to rollaxis() behavior for negative 'start' values
On Thu, Sep 23, 2010 at 10:32 AM, Anne Archibald wrote: > Just a quick correction: len(a) gives a.shape[0], while what you want > is actually len(a.shape). So: > > In [1]: a = np.zeros((2,3,4,5,6)) > > In [2]: len(a) > Out[2]: 2 > > In [8]: np.rollaxis(a,0,len(a.shape)).shape > Out[8]: (3, 4, 5, 6, 2) > > So it behaves just like insert. But "len(a.shape)" is rather > cumbersome, especially if you haven't given a a name yet: It's available as a.ndim Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A proposed change to rollaxis() behavior for negative 'start' values
On 23 September 2010 02:20, Ralf Gommers wrote: > > > On Wed, Sep 22, 2010 at 4:14 AM, Anne Archibald > wrote: >> >> Hi Ken, >> >> This is a tricky one. The current behaviour of rollaxis is to remove >> the requested axis from the list of axes and then insert it before the >> axis specified. This is exactly how python's list insertion works: >> >> In [1]: a = range(10) >> >> In [3]: a.insert(-1,'a') >> >> In [4]: a >> Out[4]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 'a', 9] >> >> And indeed, there's no clean way to add something to the end of a list >> using insert (apart from the obvious a.insert(len(a),'b') ). For this >> you have .append(). Unfortunately numpy's rollaxis, while it agrees >> with insert in its behaviour, doesn't have a move_axis_to_end. The >> situation is also somewhat muddied by the fact that rollaxis also >> removes the axis from the original list of axes, so that the >> interpretation of index numbers is a little more subtle. But I think >> your suggested behaviour would be confusing because of the conflict >> with python's insert. How about allowing the string "end" as an >> argument to rollaxis to specify that the axis should go at the end? > > Allowing "end" is an easy solution, but note that moving an axis to the end > is already possible: > a = np.ones((3,4,5,6)) np.rollaxis(a, 2, len(a)+1).shape # roll axis to to last position > (3, 4, 6, 5) > > Not consistent with insert though, there you would use len(a) instead of > len(a)+1. It's a little ugly, but perhaps just documenting this is no worse > than allowing a string or adding yet another function. Just a quick correction: len(a) gives a.shape[0], while what you want is actually len(a.shape). So: In [1]: a = np.zeros((2,3,4,5,6)) In [2]: len(a) Out[2]: 2 In [8]: np.rollaxis(a,0,len(a.shape)).shape Out[8]: (3, 4, 5, 6, 2) So it behaves just like insert. But "len(a.shape)" is rather cumbersome, especially if you haven't given a a name yet: d = (a+b*c).rollaxis(2,'end') Anne > Ralf > > >> >> Anne >> >> On 21 September 2010 15:48, Ken Basye wrote: >> > Hi Numpy Folks, >> > A while back, I filed this ticket: >> > http://projects.scipy.org/numpy/ticket/1441 suggesting a change to >> > rollaxis() and some fixes to the doc and error reporting. Ralf Gommers >> > suggested I float the behavior change here, so that's what I'm doing. >> > >> > The motivation for the change comes because it seems like there should >> > be a simpler way to get some axis into the last position than to do >> > this: >> > >> > >>> a = np.ones((3,4,5,6)) >> > >>> b = np.rollaxis(a, axis=0, start=len(a.shape)) >> > >>> b.shape >> > (4, 5, 6, 3) >> > >> > But currently it seems there isn't because when you specify -1 as the >> > 'start' argument, the axis is moved into the second-to-last position. >> > My proposed change, which you can see on the ticket, would change that >> > so that using -1 referred to the end position. Note that the use of >> > negative 'start' arguments isn't currently documented and, in its >> > current form, doesn't seem very useful. My proposal wouldn't change the >> > behavior for positive 'start' values at all, and the interpretation of >> > 'axis' arguments is also unaffected. >> > >> > If that's going to break too much code, here's a pathway that might be >> > acceptable: Add a new function moveaxis() which works the way >> > rollaxis() does for positive arguments but in the new way for negative >> > arguments. Eventually, rollaxis could be deprecated to keep things >> > tidy. This has the added advantage of using a name that seems to fit >> > what the function does better - 'rollaxis' suggests a behavior like the >> > roll() function which affects other axes, which isn't what happens. >> > >> > Thanks for listening; I'm a big fan of Numpy. >> > >> > Best, >> > Ken Basye >> > >> > >> > ___ >> > 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 > > > ___ > 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] Asking for opinions: Priops
Dag Sverre Seljebotn wrote: > Friedrich Romstedt wrote: > >> I just ran across the problem of priorities with ndarrays again and it >> keeps biting me. I did once ago a workaround to get my ``undarray`` >> class's methods be called when being the second operand of e.g. >> + . But since I wrote it, always Python crashes >> on exit with the message: >> >> Python-32(68665) malloc: *** error for object 0x239680: incorrect >> checksum for freed object - object was probably modified after being >> freed. >> *** set a breakpoint in malloc_error_break to debug >> >> (Of course only if I imported the module. Occasionally I also >> observed Bus errors, and even segfaults.) >> I overloaded the numpy ops via numpy.set_numeric_ops() with >> self-written classes, which are *not* derived from numpy.ufunc, and do >> not resemble numpy ufuncs completely. >> >> So I want to do it properly this time. >> >> I therefore started with writing a Letter of Intent, and put it online >> on http://github.com/friedrichromstedt/priops . >> >> Opinions? >> >> > I haven't had time to go into the details, but I love the fact that > somebody is about to deal with this problem, it's been bothering me as well. > > Something that is slightly related that one might as well test is the > Sage coercion model. If you haven't, you may want to see if you get > anything useful out of http://wiki.sagemath.org/coercion. > > Essentially, perhaps what you have sketched up + an ability to extend > the graph with object conversion routes would be perfect for my own > uses. So you can define a function with overloads (A, B) and (A, C), but > also that objects of type D can be converted to C (and how). For > instance, consider: > > np.array([1,2,3]) + [1,2,3] > > Here, list-> array could be handled through a defined coercion to array, > rather than having to add an overload for list for every method taking > an array. > > Btw, I was just using numPy as an example, not suggesting that NumPy adopt priops (we can "eliminate" NumPy through __array_priority__ , as long as everyone else use priops?). MyObject() + [1,2,3], with MyObject only knowing about np.ndarray, would have been better... Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Asking for opinions: Priops
Friedrich Romstedt wrote: > I just ran across the problem of priorities with ndarrays again and it > keeps biting me. I did once ago a workaround to get my ``undarray`` > class's methods be called when being the second operand of e.g. > + . But since I wrote it, always Python crashes > on exit with the message: > > Python-32(68665) malloc: *** error for object 0x239680: incorrect > checksum for freed object - object was probably modified after being > freed. > *** set a breakpoint in malloc_error_break to debug > > (Of course only if I imported the module. Occasionally I also > observed Bus errors, and even segfaults.) > I overloaded the numpy ops via numpy.set_numeric_ops() with > self-written classes, which are *not* derived from numpy.ufunc, and do > not resemble numpy ufuncs completely. > > So I want to do it properly this time. > > I therefore started with writing a Letter of Intent, and put it online > on http://github.com/friedrichromstedt/priops . > > Opinions? > I haven't had time to go into the details, but I love the fact that somebody is about to deal with this problem, it's been bothering me as well. Something that is slightly related that one might as well test is the Sage coercion model. If you haven't, you may want to see if you get anything useful out of http://wiki.sagemath.org/coercion. Essentially, perhaps what you have sketched up + an ability to extend the graph with object conversion routes would be perfect for my own uses. So you can define a function with overloads (A, B) and (A, C), but also that objects of type D can be converted to C (and how). For instance, consider: np.array([1,2,3]) + [1,2,3] Here, list-> array could be handled through a defined coercion to array, rather than having to add an overload for list for every method taking an array. Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A proposed change to rollaxis(), behavior for negative 'start' values
Anne says: This is a tricky one. The current behaviour of rollaxis is to remove the requested axis from the list of axes and then insert it before the axis specified. This is exactly how python's list insertion works: In [1]: a = range(10) In [3]: a.insert(-1,'a') In [4]: a Out[4]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 'a', 9] And indeed, there's no clean way to add something to the end of a list using insert (apart from the obvious a.insert(len(a),'b') ). For this you have .append(). Unfortunately numpy's rollaxis, while it agrees with insert in its behaviour, doesn't have a move_axis_to_end. The situation is also somewhat muddied by the fact that rollaxis also removes the axis from the original list of axes, so that the interpretation of index numbers is a little more subtle. But I think your suggested behaviour would be confusing because of the conflict with python's insert. How about allowing the string "end" as an argument to rollaxis to specify that the axis should go at the end? Anne Ralf says: Allowing "end" is an easy solution, but note that moving an axis to the end > is already possible: > > > >>> a = np.ones((3,4,5,6)) > >>> np.rollaxis(a, 2, len(a)+1).shape # roll axis to to last position > (3, 4, 6, 5) > > Not consistent with insert though, there you would use len(a) instead of > len(a)+1. It's a little ugly, but perhaps just documenting this is no worse > than allowing a string or adding yet another function. > > Chuck says: It is a common enough operation that it would be nice to have a less cumbersome way to specify it. Ralf, that's not going to work generally, because len(a) is a.shape[0], right? It works in the example above but if I had done a = np.ones((1,2,3,4)) it wouldn't work. In my original posting, I suggested >>> np.rollaxis(a, 2, len(a.shape)) which I think will work fine, but it still seems cumbersome, as Chuck points out. I'm going to take one more tilt at the windmill. To me, the connection with Python's insert() is tenuous: insert() is a destructive operation whereas rollaxis() returns a new array with the requested change, also rollaxis is doing the delete and insert in one step. I know the implementation uses insert() and delete(), but I think the natural way to think about rollaxis() is in terms of moving an axis from one position to another and there is no Python analog to that. Anne's comment that "the situation is somehat muddied..." is precisely why I think the change is worth making - if the meaning of the 'start' argument were changed from "The axis is rolled until it lies before this position." to "The axis is rolled until it lies *at* this position." then it seems to me there's no confusion. The current description "The axis is rolled until it lies before this position." is ambiguous because "this position" seems like it means "position in the shape of the array" but then what's the position before 0? So how about "The axis is rolled until it lies before the axis currently at this position." That's much closer, but now it's hard to make sense of using len(a.shape) as an argument, since there is no axis currently at len(a.shape). To really capture the muddiness, we need to say something like "The axis is rolled until it lies before the axis currently at this position, unless the value is len(a.shape), in which case the axis is rolled to the end" - yuck. Again, note that the proposed change applies only to positions specified with negative indices; positive indices will all work as before. Best, Ken ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Asking for opinions: Priops
Hi Sebastian, Thanks for your reply! 2010/9/22 Sebastian Walter : > [...] I think the issue is not so much numpy but rather the > way Python implements operator overloading using methods like __add__ > and __radd__. Hence, your suggestion seems to be a Python Enhancement > Proposal and should be discussed without any references to numpy or > bugs related to numpy.set_numeric_ops. Yeah, I agree, but i refrained from spamming the list with two separate mails, although I see now it would have been better, and would have brought more eyes on it. For the PEP, I will look into this and will check the mailing lists. For the technical things, I think the implementation of the operations must lie in the classes, and thus __add__ etc. are in principle okay. But as described in the new README, there is need to organise this functions. priop (note the rename, "priops" turned out to be always spelled "priop" in the source code) could define this new layer. > Maybe you could also have a look at Go's interfaces (Googles > programming language) which seems to be somewhat related to your > approach. I will try. Can you provide an URL? > On a more practical note: Why exactly do you use set_numeric_ops? You > could also > 1) use numpy.ndarrays with dtype=object This is too slow. And it's eating up memory because of the Python objects stored with all their bells and whistles. > 2) or create new numpy.ndarray -like class and set __array_priority__ > 2 > both approaches work well for me. I wanted to avoid exactly this because I think priop is a better approach, via set_numeric_ops(). The new URL is: http://github.com/friedrichromstedt/priop (just for the rename, which may be discussable). It contains now also an implementation, which was much less hard than expected ... Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] A proposed change to rollaxis() behavior for negative 'start' values
On Thu, Sep 23, 2010 at 12:20 AM, Ralf Gommers wrote: > > > On Wed, Sep 22, 2010 at 4:14 AM, Anne Archibald < > aarch...@physics.mcgill.ca> wrote: > >> Hi Ken, >> >> This is a tricky one. The current behaviour of rollaxis is to remove >> the requested axis from the list of axes and then insert it before the >> axis specified. This is exactly how python's list insertion works: >> >> In [1]: a = range(10) >> >> In [3]: a.insert(-1,'a') >> >> In [4]: a >> Out[4]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 'a', 9] >> >> And indeed, there's no clean way to add something to the end of a list >> using insert (apart from the obvious a.insert(len(a),'b') ). For this >> you have .append(). Unfortunately numpy's rollaxis, while it agrees >> with insert in its behaviour, doesn't have a move_axis_to_end. The >> situation is also somewhat muddied by the fact that rollaxis also >> removes the axis from the original list of axes, so that the >> interpretation of index numbers is a little more subtle. But I think >> your suggested behaviour would be confusing because of the conflict >> with python's insert. How about allowing the string "end" as an >> argument to rollaxis to specify that the axis should go at the end? >> > > Allowing "end" is an easy solution, but note that moving an axis to the end > is already possible: > > > >>> a = np.ones((3,4,5,6)) > >>> np.rollaxis(a, 2, len(a)+1).shape # roll axis to to last position > (3, 4, 6, 5) > > Not consistent with insert though, there you would use len(a) instead of > len(a)+1. It's a little ugly, but perhaps just documenting this is no worse > than allowing a string or adding yet another function. > > It is a common enough operation that it would be nice to have a less cumbersome way to specify it. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
