numpy-discussion — Discussion list for all users of Numerical Python

Re[3]: [Numpy-discussion] nonzero() behaviour has changed

[Alan G I. <ai...@am...>]

On Tue, 16 May 2006, Alan G Isaac apparently wrote: 
> 2. How are people using this?  I trust that the numarray 
> behavior was well considered, but I would have expected 
> coordinates to be grouped rather than spread across the 
> arrays in the tuple. 

OK, just to satisfy my curiosity:
does the silence mean that nobody is using
'nonzero' in a fashion that leads them to
prefer the current behavior to the "obvious"
alternative of grouping the coordinates?
Is the current behavior just an inherited
convention, or is it useful in specific applications?

Sorry to ask again,
but I'm interested to know the application that
is facilitated by getting one coordinate at a time,
or possibly by getting e.g. an array of first
coordinates without the others.

Thank you,
Alan Isaac

Re: [Numpy-discussion] Distutils/NAG compiler problems

[<co...@ph...>]

James Graham <jg...@ca...> writes:

> I have been experiencing difficulty with the final linking step when
> using f2py and the NAG Fortran 95 compiler, using the latest release
> version of numpy (0.9.6). I believe this is caused by a typo in the
> options being passed to the compiler (at least, making this change
> fixes the problem):
>
> --- /usr/lib/python2.3/site-packages/numpy/distutils/fcompiler/nag.py
> 2006-01-06 21:29:40.000000000 +0000
> +++ /scratch/jgraham/nag.py     2006-05-17 10:46:38.000000000 +0100
> @@ -22,7 +22,7 @@
>      def get_flags_linker_so(self):
>          if sys.platform=='darwin':
>              return
> ['-unsharedf95','-Wl,-bundle,-flat_namespace,-undefined,suppress']
> -        return ["-Wl,shared"]
> +        return ["-Wl,-shared"]
>      def get_flags_opt(self):
>          return ['-O4']
>      def get_flags_arch(self):
>
> (that may be incorrectly wrapped)

I've applied that to svn. It'll be in 0.9.8.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] Getting 0.9.8 out this week

[<co...@ph...>]

co...@ph... (David M. Cooke) writes:

> Travis Oliphant <oli...@ie...> writes:
>
>> I'd like to get 0.9.8 of NumPy released by the end of the week.
>> There are a few Trac tickets that need to be resolved by then.
>>
>> In particular #83 suggests returning scalars instead of 1x1 matrices
>> from certain reduce-like methods.  Please chime in on your preference.
>> I'm waiting to here more feedback before applying the patch.
>>
>> If you can help out on any other ticket that would be much
>> appreciated.
>
> I'd like to fix up #81 (Numpy should be installable with setuptool's
> easy_install), but I'm not going to have anytime to work on it before
> the weekend.

I'm good to go now. #81 is fixed with a hack, but it's the only way I
can see to do it (without a major restructuring of numpy.distutils).

Only showstopper I can see is probably #110, which seems to show we're
leaking memory in the ufunc machinery (haven't looked into it, though).

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] NumPy, Numeric or numarray or all of them?

[Mateusz L. <ma...@lo...>]

Christopher Barker wrote:
> Mateusz Łoskot wrote:
>> Christopher Barker wrote:
>> 
>>> Speaking as a long time numpy (Numeric, etc.) user, and a new
>>> user of GDAL, I had no idea GDAL worked with num* at all! at
>>> least not directly.
>> 
>> 
>> Yes, it is :-)
>> 
>>> In fact, I thought I was going to have to write that code myself.
>>> Where do I find docs for this? I'm sure I've just missed
>>> something, but I'm finding the docs a bit sparse.
>> 
>> 
>> Do you mean docs for Python bindings of GDAL?
> 
> 
> I meant docs for the num* part.

Yes, agreed.

>> AFAIK the only docs for Python oriented users is the "GDAL API
>> Tutorial" (http://www.gdal.org/gdal_tutorial.html).
> 
> 
> That's all I've found. And there was no indication of what datatypes 
> were being returned (or accepted). So far, all I'm doing it reading 
> images, and it looks to me like ReadRaster() is returning a string,
> for instance. I'd love to have it return a numpy array.

Now, it's using Numeric package.
NumPy will be used soon.

>> In the meantime, I'd suggest to use epydoc tool to generate some
>> manual - it won't be a complete reference but it can be usable.
> 
> 
> Good idea. Someone should get around to doing that, and post it 
> somewhere. I if do it, I'll let you know.

I'm going to include epydoc configuration file in GDAL source tree.
Such file is similar to doxygen config and can be used to generate
html/pdf documentations with single command.
I think including generated docs is not necessary.

>> There are two separate bindings to Python in GDAL: - native, called
>> traditional - SWIG based, called New Generation Python
> 
> 
> How do I know which ones I'm using?

When you're building GDAL you can use appropriate options for
./configure script.

> Were the "tradition" ones done my hand?

Yes, traditional pymod.

Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net

[Numpy-discussion] Distutils/NAG compiler problems

[James G. <jg...@ca...>]

I have been experiencing difficulty with the final linking step when 
using f2py and the NAG Fortran 95 compiler, using the latest release 
version of numpy (0.9.6). I believe this is caused by a typo in the 
options being passed to the compiler (at least, making this change fixes 
the problem):

--- /usr/lib/python2.3/site-packages/numpy/distutils/fcompiler/nag.py 
2006-01-06 21:29:40.000000000 +0000
+++ /scratch/jgraham/nag.py     2006-05-17 10:46:38.000000000 +0100
@@ -22,7 +22,7 @@
      def get_flags_linker_so(self):
          if sys.platform=='darwin':
              return 
['-unsharedf95','-Wl,-bundle,-flat_namespace,-undefined,suppress']
-        return ["-Wl,shared"]
+        return ["-Wl,-shared"]
      def get_flags_opt(self):
          return ['-O4']
      def get_flags_arch(self):

(that may be incorrectly wrapped)

-- 
"You see stars that clear have been dead for years
But the idea just lives on..." -- Bright Eyes

[Numpy-discussion] numpy docs

[<jo...@st...>]

On Tuesday 16 May 2006 16:32, you wrote:
> That's great!
> I think it would be nice if it could somehow become a gateway for
> docstrings.  Are you only interested in examples?  I'm not sure what your
>  intentions are, but it would be nice if there were a Wiki page like yours
> where people could contribute docstring fixes and then those fixes would
> eventually find their way into the source with the help of someone with CVS
> write access.  Usage examples like the ones on your page are needed in the
> docstrings too.   My fear though is that with a wiki page, there's no real
> incentive to be concise.  People tend to just add more rather than erasing
> something someone else wrote.  I don't really want to read a flame war in my
> docstrings about whether the sum() method is superior to the sum() function,
>  etc.
>  
>  --bill


+1 on the docstrings. At the moment I will put my efforts in making the
example list more complete, though. It's actually a great way to learn
about the numpy features. I recommend numarray users to simply browse 
through the example list and pick up the new numpy features by reading 
some of the examples. But be aware that there are actually many more
as the list is not yet complete.

And don't hesitate to contribute! ;-)

Cheers,
Joris


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Numpy-discussion] Argument of complex number array?

[Sidney C. <ca...@sc...>]

On May 17, 2006, at 6:23, Tim Leslie wrote:

>  angle(z, deg=0)

Great, I missed that completely. Thanks!

Sidney

Re: [Numpy-discussion] nonzero() behaviour has changed

[Francesc A. <fa...@ca...>]

A Dimecres 17 Maig 2006 03:17, Simon Burton va escriure:
> On Tue, 16 May 2006 15:15:23 -0400
>
> Alan G Isaac <ai...@am...> wrote:
> > 2. How are people using this?  I trust that the numarray
> >    behavior was well considered, but I would have expected
> >    coordinates to be grouped rather than spread across
> >    the arrays in the tuple.
>
> Yes, this strikes me as bizarre.
> How about we make a new function, eg. argwhere, that
> returns an array of indices ?
>
> argwhere( array( [[0,1],[0,1]] ) ) -> [[0,1],[1,1]]

+1 That could be quite useful.

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] Argument of complex number array?

[Tim L. <tim...@gm...>]

On 5/16/06, Sidney Cadot <ca...@sc...> wrote:
>
> Hi all,
>
> I am looking for a function to calculate the argument (i.e., the
> 'phase') from a numarray containing complex numbers. A bit to my
> surprise, I don't see this listed under the ufunc's.
>
> Now of course I can do something like
>
>     arg =3D arctan2(z.real, z.imag)
>
> ... But I would have hoped for a direct function that does this.
>
> Any thoughts? (Perhaps I am missing something?)


 angle(z, deg=3D0)
    Return the angle of the complex argument z.

>>> z =3D complex(1, 1)
>>> angle(z)=3D=3Dpi/4
True

Cheers,

Timl

Cheerio, Sidney
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: Re[2]: [Numpy-discussion] nonzero() behaviour has changed

[Simon B. <si...@ar...>]

On Tue, 16 May 2006 15:15:23 -0400
Alan G Isaac <ai...@am...> wrote:

> 2. How are people using this?  I trust that the numarray
>    behavior was well considered, but I would have expected
>    coordinates to be grouped rather than spread across
>    the arrays in the tuple.

Yes, this strikes me as bizarre.
How about we make a new function, eg. argwhere, that
returns an array of indices ?

argwhere( array( [[0,1],[0,1]] ) ) -> [[0,1],[1,1]]


Simon.


-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re: [Numpy-discussion] Sourceforge delaying emails to list?

[Simon B. <si...@ar...>]

On Tue, 16 May 2006 15:39:33 +0200
Stephan Tolksdorf <st...@si...> wrote:

> 
> Hi all,
> 
> am I the only one who is sometimes (particularly today) receiving emails 
> from the numpy-discussion list up to one day after they have been sent? 
> Or is there a problem with sf.net?

Yes, me too. It's very confusing, and rather random.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re[2]: [Numpy-discussion] nonzero() behaviour has changed

[Alan G I. <ai...@am...>]

1. I hope for an array 'a' that nonzero(a) and a.nonzero() 
   will produce the same result, whatever convention is 
   chosen.  For 1d arrays only the numarray behavior can be 
   consistent with nd arrays (which Numeric's 'nonzero' did 
   not handle).  But ...
2. How are people using this?  I trust that the numarray
   behavior was well considered, but I would have expected
   coordinates to be grouped rather than spread across
   the arrays in the tuple.

Thank you for any insight,
Alan Isaac

Re: [Numpy-discussion] Who uses matrix?

[Tim H. <tim...@co...>]

Bill Baxter wrote:

> On 5/13/06, *Tim Hochberg* <tim...@co... 
> <mailto:tim...@co...>> wrote:
>
>     Bill Baxter wrote:
>
>     >
>     > +1 on a .T shortcut for arrays.
>     > +1 on a .H shortcut for arrays, too.  (Instead of
>     .conj().transpose())
>
>     -1.
>
>     These are really only meaningul for 2D arrays. Without the axis
>     keyword
>     they generally do the wrong things for arrays of other dimensionality
>     (there I usually, but not always, want to transpose the first two or
>     last two axes). In addition, ndarray is already overstuffed with
>     methods
>     and attributes, let's not add any more without careful consideration.
>
>
> What am I missing here?  There's already a .transpose() method on array.
> From my quick little test it doesn't seem like the argument is useful:
> >>> a = num.rand(2,2)
> >>> a
> array([[ 0.96685836,  0.55643033],
>        [ 0.86387107,  0.39331451]])
> >>> a.transpose(1)
> array([ 0.96685836,  0.55643033])
> >>> a
> array([[ 0.96685836,  0.55643033],
>        [ 0.86387107,  0.39331451]])
> >>> a.transpose(0)
> array([ 0.96685836,  0.86387107])
> >>> a.transpose()
> array([[ 0.96685836,  0.86387107],
>        [ 0.55643033 ,  0.39331451]])
>
> (Python 2.4 / Windows XP)
>
> But maybe I'm using it wrong.  The docstring isn't much help:
> ---------------------------
> >>> help(a.transpose)
> Help on built-in function transpose:
>
> transpose(...)
>     m.transpose(<None>)
> ---------------------------

No, the docstring does not appear to be useful. I'm not sure what's 
happening to your argument there, something bogus I assume; you are 
supposed to pass a sequence, which becomes the new axis order. For example.

 >>> import numpy
 >>> a = numpy.arange(6).reshape([3,2,1])
 >>> a.shape
(3, 2, 1)
 >>> a.copy().transpose().shape # By default, the axes are just reversed
(1, 2, 3)
 >>> a.copy().transpose([0,2,1]).shape  # Transpose last two axes
(3, 1, 2)
 >>> a.copy().transpose([1,0,2]).shape # Transpose first two axes
(2, 3, 1)


Most of the time, when I'm using 3D arrays, I use one of the last two 
versions of transpose.

Back to passing a single number. Looking at array_transponse, it appears 
that a.transpose(1) and a.transpose([1]) are equivalent. The problem is 
that transpose is accepting sequences of the lengths other than 
len(a.shape). The results appear bogus: chunks of the array actually 
disappear as you illustrate. It looks like this can be fixed by just 
adding a check in PyArray_Transpose that permute->len is the same as 
ap->nd. I won't have time to get to this today; if possible, could you 
enter a ticket on this so it doesn't fall through the cracks?

>
> Assuming I'm missing something about transpose(), that still doesn't 
> rule out a shorter functional form, like a.T() or a.t().  
>
> The T(a) that you suggest is short, but it's just not the order people 
> are used to seeing things in their math.  Besides, having a global 
> function with a name like T is just asking for trouble.  And defining 
> it in every function that uses it would get tedious.
>
> Even if the .T shortcut were added as an attribute and not a function, 
> you could still use .transpose() for N-d arrays when the default two 
> axes weren't the ones you wanted to swap.  Yes, 2-D *is* a special 
> case of array, but -- correct me if I'm wrong -- it's a very common 
> special case.

Not in my experience. I can't claim that this is typical for everyone, 
but my usage is most often of 3D arrays that represent arrays of 
matrices. Also common is representing an array of 2x2 (or 4x4) matrices 
as [[X00, X01], [X10, X11]], where the various Xs are (big) 1D arrays or 
scalars. This is because I often know that one of the Xs is either all 
ones or all zeros and by storing them as a scalar values I can save 
space, and by eliding subsequent operations by special casing one and 
zero, time. My usage of vanilla 2D arrays is relatively limited and 
occurs mostly where I interface with the outside world.

> Matlab's transpose operator, for instance, just raises an error if 
> it's used on anything other than a 1D- or 2D- array.  There's some 
> other way to shuffle axes around for N-d arrays in matlab, but I 
> forget what.  Not saying that the way Matlab does it is right, but my 
> own experience reading and writing code of various sorts is that 2D 
> stuff is far more common than arbitrary N-d.  But for some reason it 
> seems like most people active on this mailing list see things as just 
> the opposite.  Perhaps it's just my little niche of the world that is 
> mostly 2D. The other thing is that I suspect you don't get so many 
> transposes when doing arbitrary N-d array stuff so there's not as much 
> need for a shortcut.  But again, not much experience with typical N-d 
> array usages here.

It's hard to say. People coming from Matlab etc tend to see things in 
terms of 2D. Some of that may be just that they work in different 
problem domains than, for instance, I do. Image processing for example 
seems to be mostly 2D. Although in some cases you might actually want to 
work on stacks of images, in which case you're back to the 3D regime. 
Part of it may also be that once you work an ND array language for a 
while you see ND solutions to some problems that previously you only saw 
2D solutions for.

>
>  
>
>     > And some briefer way to make a new axis than 'numpy.newaxis'
>     would be
>     > nice too (I'm trying to keep my global namespace clean these days).
>     > --- Whoa I just noticed that a[None,:] has the same effect as
>     > 'newaxis'.  Is that a blessed way to do things?
>
>     numpy.newaxis *is* None. I don't think that I'd spell it that way
>     since
>     None doesn't really have the same conotations as newaxis, so I think
>     I'll stick with np.newaxis, which is how I spell these things.
>
>
> Well, to a newbie, none of the notation used for indexing has much of 
> any connotation.  It's all just arbitrary symbols.  ":" means the 
> whole range? 2:10 means a range from 2 to 9?  Sure, most of those are 
> familiar to Python users (even '...'?) but even a heavy python user 
> would be puzzled by something like r_[1:2:3j].  Or reshape(-1,2).  The 
> j is a convention, the -1 is a convention.   NewAxis seems common 
> enough to me that it's worth just learning None as another numpy 
> convention. 
>
> As long as "numpy.newaxis *is* None", as you say, and not "is 
> *currently* None, but subject to change without notice" ,

It's been None since the beginning, so I don't think it's likely to 
change. Not being in charge, I can't guarantee that, but it would likely 
be a huge pain to do so I don't see it happening.

> then I think I'd rather use None.  It has the feel of being something 
> that's a fundamental part of the language.  The first few times I saw 
> indexing with numpy.newaxis it made no sense to me.  How can you index 
> with a new axis?  What's the new axis'th element of an array?  "None" 
> says to me the index we're selecting is "None" as in "None of the 
> above", i.e. we're not taking from the elements that are there, or not 
> using up any of our current axes on this index.  Also when you see 
> None, it's clear to a Python user that there's some trickery going on, 
> but when you see  a[NewAxis,:] (as it was the first time I saw it) 
> it's not clear if NewAxis is some numeric value defined in the code 
> you're reading or by Numpy or what.  For whatever reason None seems 
> more logical and symmetrical to me than numpy.newaxis.   Plus it seems 
> that documentation can't be attached to numpy.newaxis because of it 
> being None, which I recall also confused me at first.  
> "help(numpy.newaxis)" gives you a welcome to Python rather than 
> information about using numpy.newaxis.

In abstract, I don't see any problem with that, but assuming that your 
sharing code with others, everyone's likely to be happier if you spell 
newaxis as newaxis, just for consistencies sake. On a related note, I 
think newaxis is probably overused. at least by me, I just grepped my 
code for newaxis, and I'd say at least half the uses of newaxis would 
have been clearer as reshape.

-tim

Re: [Numpy-discussion] Sourceforge delaying emails to list?

[<sk...@po...>]

    Stephan> am I the only one who is sometimes (particularly today)
    Stephan> receiving emails from the numpy-discussion list up to one day
    Stephan> after they have been sent?  Or is there a problem with sf.net?

I suspect it's just the status quo.  sf.net is rarely "speedy".

Skip

Re: [Numpy-discussion] Who uses matrix?

[Bill B. <wb...@gm...>]

On 5/13/06, Tim Hochberg <tim...@co...> wrote:
>
> Bill Baxter wrote:
>
> >
> > +1 on a .T shortcut for arrays.
> > +1 on a .H shortcut for arrays, too.  (Instead of .conj().transpose())
>
> -1.
>
> These are really only meaningul for 2D arrays. Without the axis keyword
> they generally do the wrong things for arrays of other dimensionality
> (there I usually, but not always, want to transpose the first two or
> last two axes). In addition, ndarray is already overstuffed with methods
> and attributes, let's not add any more without careful consideration.


What am I missing here?  There's already a .transpose() method on array.
From my quick little test it doesn't seem like the argument is useful:
>>> a =3D num.rand(2,2)
>>> a
array([[ 0.96685836,  0.55643033],
       [ 0.86387107,  0.39331451]])
>>> a.transpose(1)
array([ 0.96685836,  0.55643033])
>>> a
array([[ 0.96685836,  0.55643033],
       [ 0.86387107,  0.39331451]])
>>> a.transpose(0)
array([ 0.96685836,  0.86387107])
>>> a.transpose()
array([[ 0.96685836,  0.86387107],
       [ 0.55643033,  0.39331451]])

(Python 2.4 / Windows XP)

But maybe I'm using it wrong.  The docstring isn't much help:
---------------------------
>>> help(a.transpose)
Help on built-in function transpose:

transpose(...)
    m.transpose(<None>)
---------------------------


Assuming I'm missing something about transpose(), that still doesn't rule
out a shorter functional form, like a.T() or a.t().

The T(a) that you suggest is short, but it's just not the order people are
used to seeing things in their math.  Besides, having a global function wit=
h
a name like T is just asking for trouble.  And defining it in every functio=
n
that uses it would get tedious.

Even if the .T shortcut were added as an attribute and not a function, you
could still use .transpose() for N-d arrays when the default two axes
weren't the ones you wanted to swap.  Yes, 2-D *is* a special case of array=
,
but -- correct me if I'm wrong -- it's a very common special case.  Matlab'=
s
transpose operator, for instance, just raises an error if it's used on
anything other than a 1D- or 2D- array.  There's some other way to shuffle
axes around for N-d arrays in matlab, but I forget what.  Not saying that
the way Matlab does it is right, but my own experience reading and writing
code of various sorts is that 2D stuff is far more common than arbitrary
N-d.  But for some reason it seems like most people active on this mailing
list see things as just the opposite.  Perhaps it's just my little niche of
the world that is mostly 2D. The other thing is that I suspect you don't ge=
t
so many transposes when doing arbitrary N-d array stuff so there's not as
much need for a shortcut.  But again, not much experience with typical N-d
array usages here.



> > And some briefer way to make a new axis than 'numpy.newaxis' would be
> > nice too (I'm trying to keep my global namespace clean these days).
> > --- Whoa I just noticed that a[None,:] has the same effect as
> > 'newaxis'.  Is that a blessed way to do things?
>
> numpy.newaxis *is* None. I don't think that I'd spell it that way since
> None doesn't really have the same conotations as newaxis, so I think
> I'll stick with np.newaxis, which is how I spell these things.


Well, to a newbie, none of the notation used for indexing has much of any
connotation.  It's all just arbitrary symbols.  ":" means the whole range?
2:10 means a range from 2 to 9?  Sure, most of those are familiar to Python
users (even '...'?) but even a heavy python user would be puzzled by
something like r_[1:2:3j].  Or reshape(-1,2).  The j is a convention, the -=
1
is a convention.   NewAxis seems common enough to me that it's worth just
learning None as another numpy convention.

As long as "numpy.newaxis *is* None", as you say, and not "is *currently*
None, but subject to change without notice" , then I think I'd rather use
None.  It has the feel of being something that's a fundamental part of the
language.  The first few times I saw indexing with numpy.newaxis it made no
sense to me.  How can you index with a new axis?  What's the new axis'th
element of an array?  "None" says to me the index we're selecting is "None"
as in "None of the above", i.e. we're not taking from the elements that are
there, or not using up any of our current axes on this index.  Also when yo=
u
see None, it's clear to a Python user that there's some trickery going on,
but when you see  a[NewAxis,:] (as it was the first time I saw it) it's not
clear if NewAxis is some numeric value defined in the code you're reading o=
r
by Numpy or what.  For whatever reason None seems more logical and
symmetrical to me than numpy.newaxis.   Plus it seems that documentation
can't be attached to numpy.newaxis because of it being None, which I recall
also confused me at first.  "help(numpy.newaxis)" gives you a welcome to
Python rather than information about using numpy.newaxis.

Regards,
--Bill

Re: [Numpy-discussion] Bug in ndarray.argmax

[Pau G. <pau...@gm...>]

On 5/1/06, Pierre Barbier de Reuille <p.b...@ue...> wrote=
:
> Hello,
>
> I notices a bug in ndarray.argmax which prevent from getting the argmax
> from any axis but the last one.
> I join a patch to correct this.
> Also, here is a small python code to test the behaviour of argmax I
> implemented :
>
> =3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D=
=3D8<=3D=3D=3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D
>
> from numpy import array, random, all
>
> a =3D random.normal( 0, 1, ( 4,5,6,7,8 ) )
> for i in xrange( a.ndim ):
>   amax =3D a.max( i )
>   aargmax =3D a.argmax( i )
>   axes =3D range( a.ndim )
>   axes.remove( i )
>   assert all( amax =3D=3D aargmax.choose( *a.transpose( i, *axes ) ) )
>
> =3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D=
=3D8<=3D=3D=3D=3D8<=3D=3D=3D=3D8<=3D=3D=3D8<=3D=3D=3D
>
> Pierre
>
>
> diff numpy-0.9.6/numpy/core/src/multiarraymodule.c numpy-0.9.6.mod/numpy/=
core/src/multiarraymodule.c
> 1952a1953,1955
> >    If orign > ap->nd, then we cannot "swap it back"
> >    as the dimension does not exist anymore. It means
> >    the axis must be put back at the end of the array.
> 1956c1959,1979
> <                       (op) =3D (PyAO *)PyArray_SwapAxes((ap), axis, ori=
gn); \
> ---
> >                       int nb_dims =3D (ap)->nd;                        =
 \
> >                       if (orign > nb_dims-1 ) {                       \
> >                               PyArray_Dims dims;                      \
> >                               int i;                                  \
> >                               dims.ptr =3D ( intp* )malloc( sizeof( int=
p )*nb_dims );\
> >                               dims.len =3D nb_dims;                    =
 \
> >                               for(i =3D 0 ; i < axis ; ++i)            =
 \
> >                               {                                       \
> >                                       dims.ptr[i] =3D i;               =
 \
> >                               }                                       \
> >                               for(i =3D axis ; i < nb_dims-1 ; ++i)    =
 \
> >                               {                                       \
> >                                       dims.ptr[i] =3D i+1;             =
 \
> >                               }                                       \
> >                               dims.ptr[nb_dims-1] =3D axis;            =
 \
> >                               (op) =3D (PyAO *)PyArray_Transpose((ap), =
&dims ); \
> >                       }                                               \
> >                       else                                            \
> >                       {                                               \
> >                               (op) =3D (PyAO *)PyArray_SwapAxes((ap), a=
xis, orign); \
> >                       }                                               \
>
>
>

The bug seems to be still there in the current svn version, so I
filled out a ticket for this.

Is the first time i do such a thing, so someone competent should
_please_ take a look at it.

Thanks, and sorry in advance if i did something wrong.
pau

[Numpy-discussion] numpy documentation

[<jo...@st...>]

Hi,

I've started a numpy documentation wikipage with a list of examples
illustrating the use of each numpy function. Although far from complete, 
you can have a look at what I currently have: http://scipy.org/JorisDeRidder

I would like to make the example list more visible for the numpy
community, though. Any suggestions? And, needless to say, if anyone 
likes to contribute, please jump in!

Cheers,
Joris



Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[Numpy-discussion] Sourceforge delaying emails to list?

[Stephan T. <st...@si...>]

Hi all,

am I the only one who is sometimes (particularly today) receiving emails 
from the numpy-discussion list up to one day after they have been sent? 
Or is there a problem with sf.net?

Stephan

[Numpy-discussion] Argument of complex number array?

[Sidney C. <ca...@sc...>]

Hi all,

I am looking for a function to calculate the argument (i.e., the  
'phase') from a numarray containing complex numbers. A bit to my  
surprise, I don't see this listed under the ufunc's.

Now of course I can do something like

    arg = arctan2(z.real, z.imag)

... But I would have hoped for a direct function that does this.

Any thoughts? (Perhaps I am missing something?)

Cheerio, Sidney

Re: [Numpy-discussion] nonzero() behaviour has changed

[Simon B. <si...@ar...>]

On Mon, 15 May 2006 22:13:57 -0600
Travis Oliphant <oli...@ie...> wrote:

> 
> Chris Fonnesback releases quite up-to-date binary releases of NumPy and 
> SciPy for Mac OSX.

Yes:
http://homepage.mac.com/fonnesbeck/mac/index.html

> 
> An alternative solution is to use the functional form:
> 
> nonzero(a) works the same as a.nonzero() did before for backwards 
> compatibility. 
> 
> The behavior of a.nonzero() was changed for compatibility with numarray.

Is this a general strategy employed by numpy ? Ie. functions have old semantics,
methods have numarray semantics ?  Scary.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re: [Numpy-discussion] nonzero() behaviour has changed

[Travis O. <oli...@ie...>]

Simon Burton wrote:
> Sometime between 0.9.5 and 0.9.7.2502 the behaviour of nonzero changed:
>
>   
>>>> a=numpy.array([1,1,0,1,1])
>>>> a.nonzero()
>>>>         
> array([0, 1, 3, 4])
>   
>
> now it returns a tuple:
>
>   
>>>> a=numpy.array((0,1,1,0,0))
>>>> a.nonzero()
>>>>         
> (array([1, 2]),)
>
> This is rather unpleasant for me. For example, my collegue
> uses OSX and finds only numpy 0.9.5 under darwinports.
>
>   

Chris Fonnesback releases quite up-to-date binary releases of NumPy and 
SciPy for Mac OSX.

An alternative solution is to use the functional form:

nonzero(a) works the same as a.nonzero() did before for backwards 
compatibility. 

The behavior of a.nonzero() was changed for compatibility with numarray.


-Travis

[Numpy-discussion] nonzero() behaviour has changed

[Simon B. <si...@ar...>]

Sometime between 0.9.5 and 0.9.7.2502 the behaviour of nonzero changed:

>>> a=numpy.array([1,1,0,1,1])
>>> a.nonzero()
array([0, 1, 3, 4])
>>> 

now it returns a tuple:

>>> a=numpy.array((0,1,1,0,0))
>>> a.nonzero()
(array([1, 2]),)

This is rather unpleasant for me. For example, my collegue
uses OSX and finds only numpy 0.9.5 under darwinports.

:(

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re: [Numpy-discussion] Creating small arrays from strings and concatenating with empty arrays

[Bill B. <wb...@gm...>]

On 5/13/06, Charles R Harris <cha...@gm...> wrote:
>
>
>
> On 5/11/06, Bill Baxter <wb...@gm...> wrote:
> >
> > Ahh, I hadn't noticed the fromstring/fromfile methods.
> >
> > Hmm.  That seems ok for making a row-at-a-time, but it doesn't support
> > the full syntax of the matrix string constructor,  which allows for thi=
ngs
> > like
> >
> > >>> numpy.matrix("[1 2; 2 3;3 4]")
> > matrix([[1, 2],
> >        [2, 3],
> >        [3, 4]])
> >
>
> You can reshape the array returned by fromstring, i.e.,
>
> In [6]: fromstring("1 2 2 3 3 4", sep=3D" ").reshape(-1,2)
> Out[6]:
> array([[1, 2],
>        [2, 3],
>        [3, 4]])
>

But if the string comes from someplace other than a literal right there in
the code (like loaded from a file or passed in as an argument or something)=
,
I may not know the shape in advance.  I'll just stick with the matrix
constructor, since for my case, I do know the array dim is 2.

--bill

Re: [Numpy-discussion] basearray / arraykit

[Karol L. <kar...@kn...>]

On Thursday 11 May 2006 18:28, Travis Oliphant wrote:
> Christopher Barker wrote:
> > Travis Oliphant wrote:
> >> 1) Implement a base-array with no getitem method nor setitem method
> >> at all
> >>
> >> 2) Implement a sub-class that supports only creation of data-types
> >> corresponding to existing Python scalars (Boolean, Long-based
> >> integers, Double-based floats, complex and object types).  Then, all
> >> array accesses should return the underlying Python objects.
> >> This sub-class should also only do view-based indexing (basically
> >> it's old Numeric behavior inside of NumPy).
> >>
> >> Item 1) should be pushed for inclusion in 2.6  and possibly even
> >> something like 2)
> >
> > + sys.maxint
> >
> > Having even this very basic n-d object in the standard lib would be a
> > MAJOR boon to python.
>
> I totally agree.   I've been advertising this for at least 8 months, but
> nobody is really willing to work on it (or fund it).   At least we have
> a summer student who is going to try and get Google summer-of-code money
> for it.  If you have any ability to bump up the ratings of summer of
> code applications.  Please consider bumping up his application.

I am this student Travis mentioned. Right now I am intently looking through 
past archives and slowly digging into the basearray stuff. If I get the SoC 
money, I officially start working on this May 23rd, in close contact with 
eveyone connected with numpy I hope. If I don't get it, I may still go ahead, 
but not so eagerly for sure, as then I'll need to take up a summer job.

Those interested that don't have inside access to SoC ;) can find my 
application here:
http://www.mml.ch.pwr.wroc.pl/langner/SoC-NDarray.txt

Karol

-- 
written by Karol Langner
pon maj 15 22:29:43 CEST 2006

[Numpy-discussion] bug in argmax (?)

[Pau G. <pau...@gm...>]

hi all,

argmax gives me some errors for arrays with more than 2 dimensions:

>>> import numpy
>>> numpy.__version__
'0.9.7.2503'
>>> x =3D numpy.zeros((2,3,4))
>>> x.argmax(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: bad axis2 argument to swapaxes
>>> x.argmax(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: bad axis2 argument to swapaxes
>>> x.argmax(2)
array([[0, 0, 0],
       [0, 0, 0]])


does this happens to anyone else?

pau