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

Re: [Numpy-discussion] Use of numarray from numpy package [# INC NO 24609]

[LANDRIU D. S. <la...@di...>]

Hello,
 =20
  I come back to my question : how to use numarray=20
 with the numpy installation ?
 =20
 =20
  After some update in the system there is another=20
 error message :

>> AttributeError: 'module' object has no attribute 'NewAxis'

 It seems , from advice of the system manager, that an kind of=20
alias failed to execute the right action.
     =20

Thanks in advance for your answer,

   Cheers,
  =20
     David Landriu

------------- Begin Forwarded Message -------------


>Date: Wed, 30 Aug 2006 14:14:27 +0200 (MEST)
>To: LANDRIU David SAp <la...@di...>
>Subject: Re: Use of numarray from numpy package [# INC NO 24609]
>From: User Support <use...@cc...>
>Error-to: Jean-Rene Rouet <ro...@in...>
>X-CEA-Source: externe
>X-CEA-DebugSpam: 7%
>X-CEA-Spam-Report: No antispam rules were triggered by this message
>X-CEA-Spam-Hits: __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __SANE_MSGID 0, __STOC=
K_CRUFT 0
>MIME-Version: 1.0
>Content-Transfer-Encoding: 8bit
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on discovery
>X-Spam-Status: No, hits=3D0.1 required=3D4.0 tests=3DAWL autolearn=3Dno ve=
rsion=3D2.63
>X-Spam-Level:=20
>
>
>R=E9ponse de User-Support =E0 votre question :
>------------------------------------------
>
>Rebonjour
>Essayez maintenat svp
>
>WW

Voici ce que j'obtiens maintenant :

{ccali22}~(0)>setenv PYTHONPATH /usr/local/lib/python2.3/site-packages/nump=
y
{ccali22}~(0)>
{ccali22}~(0)>
{ccali22}~(0)>python
Python 2.3.5 (#2, Oct 17 2005, 17:20:02)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from numarray import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'NewAxis'
>>>


##############################################
##############################################

Hello,

   is it necessary to install numarray separately to use numpy ?
  =20
  Indeed, after numpy installation, when I try to use it in the code,
 I get the same error as below :
=20
.../...=20
Python 2.4.1 (#1, May 13 2005, 13:45:18)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from numarray import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/site-packages/numpy/numarray/__init__.py",=
 line 1, in ?
    from util import *
  File "/usr/local/lib/python2.3/site-packages/numpy/numarray/util.py", lin=
e 2, in ?
    from numpy import geterr
ImportError: No module named numpy
>>>

  Thanks for your answer,
 =20
     Cheers,
    =20
       David Landriu
=20




--------------------------------------------------------------------

David Landriu                 DAPNIA/SAp CEA SACLAY  (France)              =
    =20

Phone  : (33|0)169088785=20
Fax    : (33|0)169086577=20

---------------------------------------------------------------------

Re: [Numpy-discussion] stumped numpy user seeks help

[Sven S. <sve...@gm...>]

Mathew Yeates schrieb:
> My head is about to explode.
> 
> I have an M by N array of floats. Associated with the columns are 
> character labels
> ['a','b','b','c','d','e','e','e']  note: already sorted so duplicates 
> are contiguous
> 
> I want to replace the 2 'b' columns with the sum of the 2 columns. 
> Similarly, replace the 3 'e' columns with the sum of the 3 'e' columns.
> 
> The resulting array still has M rows but less than N columns. Anyone? 
> Could be any harder than Sudoku.
> 


Hi,
I don't have time for this ;-) , but I learnt something useful along the
way...

import numpy as n
m = n.ones([2,6])
a = ['b', 'c', 'c', 'd', 'd', 'd']

startindices = set([a.index(x) for x in a])
out = n.empty([m.shape[0], 0])
for i in startindices:
    temp = n.mat(m[:, i : i + a.count(a[i])]).sum(axis = 1)
    out = n.hstack([out, temp])

print out

Not sure if axis = 1 is needed, but until the defaults have settled a
bit it can't hurt. You need python 2.4 for the built-in <set>, and <out>
will be a numpy matrix, use <asarray> if you don't like that. But here
it's really nice to work with matrices, because otherwise .sum() will
give you a 1-d array sometimes, and that will suddenly look like a row
to <hstack> (instead of a nice column vector) and wouldn't work --
that's why matrices are so great and everybody should be using them ;-)

hth,
sven

Re: [Numpy-discussion] possible bug with numpy.object_

[Stefan v. d. W. <st...@su...>]

On Tue, Aug 29, 2006 at 10:49:58AM -0600, Travis Oliphant wrote:
> Matt Knox wrote:
> > is the following behaviour expected? or is this a bug with=20
> > numpy.object_  ?  I'm using numpy 1.0b1
> > =20
> > >>> print numpy.array([],numpy.float64).size
> > 0
> >
> > >>> print numpy.array([],numpy.object_).size
> > 1
> >
> > Should the size of an array initialized from an empty list not always=
=20
> > be 1 ? or am I just crazy?
> > =20
> Not in this case.  Explictly creating an object array from any object=20
> (even the empty-list object) gives you a 0-d array containing that=20
> object.   When you explicitly create an object array a different sectio=
n=20
> of code handles it and gives this result.  This is a recent change, and=
=20
> I don't think this use-case was considered as a backward incompatibilit=
y=20
> (which I believe it is).   Perhaps we should make it so array([],....)=20
> always returns an empty array.   I'm not sure.   Comments?

The current behaviour makes sense, but is maybe not consistent:

N.array([],dtype=3Dobject).size =3D=3D 1
N.array([[],[]],dtype=3Dobject).size =3D=3D 2

Regards
St=E9fan

Re: [Numpy-discussion] fftfreq very slow; rfftfreq incorrect?

[Andrew J. <a.h...@gm...>]

[copied to the scipy list since rfftfreq is only in scipy]

Andrew Jaffe wrote:
> Hi all,
> 
> the current implementation of fftfreq (which is meant to return the 
> appropriate frequencies for an FFT) does the following:
> 
>      k = range(0,(n-1)/2+1)+range(-(n/2),0)
>      return array(k,'d')/(n*d)
> 
> I have tried this with very long (2**24) arrays, and it is ridiculously 
> slow. Should this instead use arange (or linspace?) and concatenate 
> rather than converting the above list? This seems to result in 
> acceptable performance, but we could also perhaps even pre-allocate the 
> space.
> 
> The numpy.fft.rfftfreq seems just plain incorrect to me. It seems to 
> produce lots of duplicated frequencies, contrary to the actual output of 
> rfft:
> 
> def rfftfreq(n,d=1.0):
>      """ rfftfreq(n, d=1.0) -> f
> 
>      DFT sample frequencies (for usage with rfft,irfft).
> 
>      The returned float array contains the frequency bins in
>      cycles/unit (with zero at the start) given a window length n and a
>      sample spacing d:
> 
>        f = [0,1,1,2,2,...,n/2-1,n/2-1,n/2]/(d*n)   if n is even
>        f = [0,1,1,2,2,...,n/2-1,n/2-1,n/2,n/2]/(d*n)   if n is odd
> 
>        **** None of these should be doubled, right?
> 
>      """
>      assert isinstance(n,int)
>      return array(range(1,n+1),dtype=int)/2/float(n*d)
> 
> Thanks,
> 
> Andrew
> 
> 
> -------------------------------------------------------------------------
> 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 Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[Numpy-discussion] fftfreq very slow; rfftfreq incorrect?

[Andrew J. <a.h...@gm...>]

Hi all,

the current implementation of fftfreq (which is meant to return the 
appropriate frequencies for an FFT) does the following:

     k = range(0,(n-1)/2+1)+range(-(n/2),0)
     return array(k,'d')/(n*d)

I have tried this with very long (2**24) arrays, and it is ridiculously 
slow. Should this instead use arange (or linspace?) and concatenate 
rather than converting the above list? This seems to result in 
acceptable performance, but we could also perhaps even pre-allocate the 
space.

The numpy.fft.rfftfreq seems just plain incorrect to me. It seems to 
produce lots of duplicated frequencies, contrary to the actual output of 
rfft:

def rfftfreq(n,d=1.0):
     """ rfftfreq(n, d=1.0) -> f

     DFT sample frequencies (for usage with rfft,irfft).

     The returned float array contains the frequency bins in
     cycles/unit (with zero at the start) given a window length n and a
     sample spacing d:

       f = [0,1,1,2,2,...,n/2-1,n/2-1,n/2]/(d*n)   if n is even
       f = [0,1,1,2,2,...,n/2-1,n/2-1,n/2,n/2]/(d*n)   if n is odd

       **** None of these should be doubled, right?

     """
     assert isinstance(n,int)
     return array(range(1,n+1),dtype=int)/2/float(n*d)

Thanks,

Andrew

[Numpy-discussion] Use of numarray from numpy package

[LANDRIU D. S. <la...@di...>]

Hello,

   is it necessary to install numarray separately to use numpy ?
   
  Indeed, after numpy installation, when I try to use it in the code,
 I get the same error as below :
 
.../... 
Python 2.4.1 (#1, May 13 2005, 13:45:18)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from numarray import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/site-packages/numpy/numarray/__init__.py", line 1, in ?
    from util import *
  File "/usr/local/lib/python2.3/site-packages/numpy/numarray/util.py", line 2, in ?
    from numpy import geterr
ImportError: No module named numpy
>>>

  Thanks for your answer,
  
     Cheers,
     
       David Landriu
 


--------------------------------------------------------------------

David Landriu                 DAPNIA/SAp CEA SACLAY  (France)                   

Phone  : (33|0)169088785 
Fax    : (33|0)169086577 

---------------------------------------------------------------------

Re: [Numpy-discussion] array indexing problem

[Sven S. <sve...@gm...>]

Charles R Harris schrieb:

> You can get what you expect using matrices:
> 
...
> But generally it is best to just use arrays and get used to the conventions.
> 

Well, there are different views on this subject, and I'm happy that the
numpy crew is really trying (and good at it) to make array *and* matrix
users happy. So please let us coexist peacefully.
-sven

Re: [Numpy-discussion] Irregular arrays

[<rw6...@sn...>]

Travis,

A sparse matrix is a different animal serving a different purpose, i.e.,
solution of linear systems.  Those storage formats are geared for that
application: upper diagonal, block diagonal, stripwise, etc.

To be more specific: here tight numerical arrays are presumably
discussed.  Python and other languages could define an "irregular list
of irregular lists" or "aggregation of objects" configuration.  Probably
Lisp would be better for that.  But it is not my driving interest.  My
interest is packed storage minimizing memory consumption and access
time, with bonus points for integration with numerical recipes and
element-wise operations.

Again, actual demonstration would be appreciated.  I selected an example
with minimal deviation from a regular array to simplify things.  The
shape is essentially a cube with a planar cut across one corner.  The
Mathematica code shows it is very easy to define in that language.  (I
am not sure whether it is tightly packed but it shows O(N) performance
graphs.)

Re: [Numpy-discussion] [ANN] NumPy 1.0b4 now available

[bruce.who.hk <bru...@gm...>]

Hi, Travis

I tried numpy1.0b4 and add this to setup.py

includes = ["numpy.core._internal"]

then it works! And all scripts can be packed into a single executables with 
        "bundle_files":2,
        "skip_archive":0,
        zipfile = None,

--skip_archive option is not needed now.


-------------------------------------------------------------
>I suspect you need to force-include the numpy/core/_internal.py file by 
>specifying it in your setup.py file as explained on the py2exe site. 
>That module is only imported by the multiarraymodule.c file which I 
>suspect py2exe can't automatically discern.
>
>In 1.0 we removed the package-loader issues which are probably giving 
>the scipy-style subpackage errors.  So, very likely you might be O.K. 
>with the beta releases of 1.0 as long as you tell py2exe about 
>numpy/core/_internal.py so that it gets included in the distribution.
>
>Please post any successes.
>
>Best,
>
>-Travis
>
>-- 
>http://mail.python.org/mailman/listinfo/python-list

------------------				 
bruce.who.hk
2006-08-30

Re: [Numpy-discussion] Irregular arrays

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

rw6...@sn... wrote:
> Many problems are best solved with irregular array structures.  These
> are aggregations not having a rectangular shape.  To motivate, here's
> one example,
>
>    http://lambda-the-ultimate.org/files/HammingNumbersDeclarative.7z
>          - from http://lambda-the-ultimate.org/node/608#comment-5746
>
> Irregularity here changes an O(N^3) solution to O(N).  (The file format
> is a 7zip archive with a MathReader file inside, readable in Windows or
> Unix with free software.)
>
> These cases also arise in simulations where physical geometry determines
> array shape.  Here memory consumption is the minimization goal that
> makes irregularity desirable.  The access function will return NaN or
> zero for out-of-bounds requests.  There is no need to consume memory
> storing NaNs and zeros
>   

> Please advise how much support numpy/Scipy has for these structures, if
> any, including future plans.  If support exists, could you kindly supply
> a Scipy declaration matching the first example.
>   

SciPy has sparse matrix support (scipy.sparse) with several storage formats

You can also construct irregular arrays using arrays of objects or just 
lists of lists. 

-Travis

[Numpy-discussion] Irregular arrays

[<rw6...@sn...>]

Many problems are best solved with irregular array structures.  These
are aggregations not having a rectangular shape.  To motivate, here's
one example,

   http://lambda-the-ultimate.org/files/HammingNumbersDeclarative.7z
         - from http://lambda-the-ultimate.org/node/608#comment-5746

Irregularity here changes an O(N^3) solution to O(N).  (The file format
is a 7zip archive with a MathReader file inside, readable in Windows or
Unix with free software.)

These cases also arise in simulations where physical geometry determines
array shape.  Here memory consumption is the minimization goal that
makes irregularity desirable.  The access function will return NaN or
zero for out-of-bounds requests.  There is no need to consume memory
storing NaNs and zeros.

Please advise how much support numpy/Scipy has for these structures, if
any, including future plans.  If support exists, could you kindly supply
a Scipy declaration matching the first example.

Thank you very much.

Re: [Numpy-discussion] array indexing problem

[Robert K. <rob...@gm...>]

Rahul Kanwar wrote:
> Hello,
> 
>    I am trying to extract a column from a 2D array here is what is have
> done:
> 
> --------------------------------------------
> In [3]: a = array([[1,2,3],[1,2,3]])
> 
> In [4]: a
> Out[4]:
> array([[1, 2, 3],
>        [1, 2, 3]])
> 
> In [5]: a[:, 1]
> Out[5]: array([2, 2])
> 
> In [6]: a[:, 1:2]
> Out[6]:
> array([[2],
>        [2]])
> --------------------------------------------
> 
> when i use a[:, 1] i get a 1x2 array where as when i use a[:, 1:2] i get
> a 2x1 array. The intuitive behavior of a[:, 1] should be a 2x1 array. Am
> i doing something wrong here or is there some reason for this behavior ?

Indexing reduces the rank of the array. Slicing does not. In the first instance, 
you do not get a 1x2 array; you get an array with shape (2,).

This choice dates from the earliest days of Numeric. It ends up being quite 
useful in most contexts. However, it is somewhat less so when you want to treat 
these arrays as matrices and row and column vectors.

-- 
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

Re: [Numpy-discussion] array indexing problem

[Charles R H. <cha...@gm...>]

On 8/29/06, Rahul Kanwar <rk...@ge...> wrote:
>
> Hello,
>
>    I am trying to extract a column from a 2D array here is what is have
> done:
>
> --------------------------------------------
> In [3]: a = array([[1,2,3],[1,2,3]])
>
> In [4]: a
> Out[4]:
> array([[1, 2, 3],
>        [1, 2, 3]])
>
> In [5]: a[:, 1]
> Out[5]: array([2, 2])
>
> In [6]: a[:, 1:2]
> Out[6]:
> array([[2],
>        [2]])
> --------------------------------------------
>
> when i use a[:, 1] i get a 1x2 array where as when i use a[:, 1:2] i get
> a 2x1 array. The intuitive behavior of a[:, 1] should be a 2x1 array. Am
> i doing something wrong here or is there some reason for this behavior ?


The behaviour is expected. a[:,1] is returned with one less dimension, just
as for a one dimensional array b[1] is zero dimensional (a scalar). For
instance

In [65]: int64(2).shape
Out[65]: ()

You can get what you expect using matrices:

In [67]: a = mat(arange(6).reshape(2,3))

In [68]: a[:,1]
Out[68]:
matrix([[1],
        [4]])

But generally it is best to just use arrays and get used to the conventions.

regards,
> Rahul


Chuck

[Numpy-discussion] array indexing problem

[Rahul K. <rah...@gm...>]

Hello,

   I am trying to extract a column from a 2D array here is what is have
done:

--------------------------------------------
In [3]: a = array([[1,2,3],[1,2,3]])

In [4]: a
Out[4]:
array([[1, 2, 3],
       [1, 2, 3]])

In [5]: a[:, 1]
Out[5]: array([2, 2])

In [6]: a[:, 1:2]
Out[6]:
array([[2],
       [2]])
--------------------------------------------

when i use a[:, 1] i get a 1x2 array where as when i use a[:, 1:2] i get
a 2x1 array. The intuitive behavior of a[:, 1] should be a 2x1 array. Am
i doing something wrong here or is there some reason for this behavior ?

regards,
Rahul

Re: [Numpy-discussion] array indexing problem

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

That's just the way it works in numpy.  Slices return arrays of lower rank.
If you want arrays that behave like they do in linear algebra you can
use 'matrix' instead.  Check out the Numpy for Matlab users page for
more info on array vs. matrix.
http://www.scipy.org/NumPy_for_Matlab_Users

--bb

On 8/30/06, Rahul Kanwar <rk...@ge...> wrote:
> Hello,
>
>    I am trying to extract a column from a 2D array here is what is have
> done:
>
> --------------------------------------------
> In [3]: a = array([[1,2,3],[1,2,3]])
>
> In [4]: a
> Out[4]:
> array([[1, 2, 3],
>        [1, 2, 3]])
>
> In [5]: a[:, 1]
> Out[5]: array([2, 2])
>
> In [6]: a[:, 1:2]
> Out[6]:
> array([[2],
>        [2]])
> --------------------------------------------
>
> when i use a[:, 1] i get a 1x2 array where as when i use a[:, 1:2] i get
> a 2x1 array. The intuitive behavior of a[:, 1] should be a 2x1 array. Am
> i doing something wrong here or is there some reason for this behavior ?
>
> regards,
> Rahul
>
>
>
> -------------------------------------------------------------------------
> 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 Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

[Numpy-discussion] array indexing problem

[Rahul K. <rk...@ge...>]

Hello,

   I am trying to extract a column from a 2D array here is what is have
done:

--------------------------------------------
In [3]: a = array([[1,2,3],[1,2,3]])

In [4]: a
Out[4]:
array([[1, 2, 3],
       [1, 2, 3]])

In [5]: a[:, 1]
Out[5]: array([2, 2])

In [6]: a[:, 1:2]
Out[6]:
array([[2],
       [2]])
--------------------------------------------

when i use a[:, 1] i get a 1x2 array where as when i use a[:, 1:2] i get
a 2x1 array. The intuitive behavior of a[:, 1] should be a 2x1 array. Am
i doing something wrong here or is there some reason for this behavior ?

regards,
Rahul

Re: [Numpy-discussion] stumped numpy user seeks help

[Charles R H. <cha...@gm...>]

On 8/29/06, Keith Goodman <kwg...@gm...> wrote:
>
> On 8/29/06, Mathew Yeates <my...@jp...> wrote:
>
> > I have an M by N array of floats. Associated with the columns are
> > character labels
> > ['a','b','b','c','d','e','e','e']  note: already sorted so duplicates
> > are contiguous
> >
> > I want to replace the 2 'b' columns with the sum of the 2 columns.
> > Similarly, replace the 3 'e' columns with the sum of the 3 'e' columns.
>
> Make a cumsum of the array. Find the index of the last 'a', last 'b',
> etc and make the reduced array from that. Then take the diff of the
> columns.
>
> I know that's vague, but so is my understanding of python/numpy.
>
> Or even more vague: make a function that does what you want.


Or you could use searchsorted on the labels to get a sequence of ranges.
What you have is a sort of binning applied to columns instead of values in a
vector. Or, if the overhead isn't to much, use a dictionary of with (keys:
array) entries. Index thru the columns adding keys, when the key is new
insert a column copy, when it is already present add the new column to the
old one.

Chuck

Re: [Numpy-discussion] Release of 1.0b5 this weekend

[Fernando P. <fpe...@gm...>]

On 8/29/06, Travis Oliphant <oli...@ie...> wrote:
>
> Hi all,
>
> Classes start for me next Tuesday, and I'm teaching a class for which I
> will be using NumPy / SciPy extensively.  I need to have a release of
> these two (and hopefully matplotlib) that work with each other.
>
> Therefore, I'm going to make a 1.0b5 release of NumPy over the weekend
> (probably Monday), and also get a release of SciPy out as well.  At that
> point, I'll only be available for bug-fixes to 1.0.  Therefore, the next
> release after 1.0b5 I would like to be 1.0rc1 (release-candidate 1).

What's the status of these 'overwriting' messages?

planck[/tmp]> python -c 'import scipy;scipy.test()'
Overwriting info=<function info at 0x40ba748c> from scipy.misc (was
<function info at 0x4080409c> from numpy.lib.utils)
Overwriting fft=<function fft at 0x430ae33c> from scipy.fftpack.basic
(was <module 'numpy.fft' from
'/home/fperez/tmp/local/lib/python2.3/site-packages/numpy/fft/__init__.pyc'>
from /home/fperez/tmp/local/lib/python2.3/site-packages/numpy/fft/__init__.pyc)
...

I was under the impression you'd decided to quiet them out, but they
seem to be making a comeback.

Cheers,

f

Re: [Numpy-discussion] A minor annoyance with MA

[PGM <pgm...@gm...>]

Travis,
> This bug has hopefully been fixed (in SVN).    Please let us know if it
> still persists.

It seems to work quite fine with the latest version of ma.
Thanks a lot !
P.

Re: [Numpy-discussion] Release of 1.0b5 this weekend

[Charles R H. <cha...@gm...>]

On 8/29/06, Charles R Harris <cha...@gm...> wrote:
>
> On 8/29/06, Tim Hochberg <tim...@ie...> wrote:
>
> > David M. Cooke wrote:
> > > On Tue, 29 Aug 2006 14:03:39 -0700
> > > Tim Hochberg <tim...@ie...> wrote:
> > >
> > >
> > >> Of these,  clip, conjugate and round support an 'out' argument like
> > that
> > >> supported by ufunces;  byteswap has a boolean argument telling it
> > >> whether to perform operations in place; and sort always operates in
> > >> place. Noting that the ufunc-like methods (max, argmax, etc) appear
> > to
> > >> support the 'out' argument as well although it's not documented for
> > most
> > >> of them, it looks to me as if the two odd methods are byteswap and
> > sort.
> > >> The method situation could be made more consistent by swapping the
> > >> boolean inplace flag in byteswapped with another 'out' argument and
> > also
> > >> having sort not operate in place by default, but also supply an out
> > >> argument there. Thus:
> > >>
> > >> b = a.sort()   # Returns a copy
> > >> a.sort(out=a) # Sorts a in place
> > >> a.sort(out=c) # Sorts a into c (probably just equivalent to c =
> > a.sort()
> > >> in this case since we don't want to rewrite the sort routines)
> > >>
> > >
> > > Ugh. That's completely different semantics from sort() on lists, so I
> > think
> > > it would be a source of bugs (at least, it would mean keeping two
> > different
> > > ideas of .sort() in my head).
> > >
> > Thinking about it a bit more, I'd leave sort alone (returning None and
> > all).. I was (over)reacting to changing to sort to return self, which
> > makes the set of methods both less consistent within itself, less
> > consistent with python and more error prone IMO, which seems the worst
> > possibility.
>
>
> Here is Guido on sort:
>
> I'd like to explain once more why I'm so adamant that *
> sort*() shouldn't
> *return* 'self'.
>
> This comes from a coding style (popular in various other languages, I
> believe especially Lisp revels in it) where a series of side effects
>
> on a single object can be chained like this:
>
>   x.compress().chop(y).*sort*(z)
>
> which would be the same as
>
>   x.compress()
>   x.chop
> (y)
>   x.*sort*(z)
>
> I find the chaining form a threat to readability; it requires that the
> reader must be intimately familiar with each of the methods.  The
>
> second form makes it clear that each of these calls acts on the same
> object, and so even if you don't know the class and its methods very
> well, you can understand that the second and third call are applied to
>
> x (and that all calls are made for their side-effects), and not to
> something else.
>
> I'd like to reserve chaining for operations that *return* new values,
>
> like string processing operations:
>
>   y = x.rstrip("\n").split(":").lower()
>
> There are a few standard library modules that encourage chaining of
> side-effect calls (pstat comes to mind).  There shouldn't be any new
>
> ones; pstat slipped through my filter when it was weak.
>
> So it seems you are correct in light of the Python philosophy. For those
> operators that allow specification of out I would still like to see a
> special value that means inplace, I think it would make the code clearer. Of
> course, merely having the out flag violates Guido's intent. The idea seems
> to be that we want some way to avoid allocating new memory. So maybe
> byteswap should be inplace and return None, while a copyto method could be
> added. Then one would do
>
> a.copyto(b)
> b.byteswap()
>
> instead of
>
> b = a.byteswap()
>
>

To expand on this a bit. Guidos philosophy, combined with a desire for
memory efficiency, means that methods like byteswap and clip, which use the
same memory, should operate inplace and return None. Thus, instead of

b = a.clip(...)

use

b = a.copy()
b.clip(...)

Hey, it's a risc machine. If we did this, then functions could always return
copies:

b = clip(a,...)

Chuck

Re: [Numpy-discussion] stumped numpy user seeks help

[Keith G. <kwg...@gm...>]

On 8/29/06, Mathew Yeates <my...@jp...> wrote:

> I have an M by N array of floats. Associated with the columns are
> character labels
> ['a','b','b','c','d','e','e','e']  note: already sorted so duplicates
> are contiguous
>
> I want to replace the 2 'b' columns with the sum of the 2 columns.
> Similarly, replace the 3 'e' columns with the sum of the 3 'e' columns.

Make a cumsum of the array. Find the index of the last 'a', last 'b',
etc and make the reduced array from that. Then take the diff of the
columns.

I know that's vague, but so is my understanding of python/numpy.

Or even more vague: make a function that does what you want.

[Numpy-discussion] stumped numpy user seeks help

[Mathew Y. <my...@jp...>]

My head is about to explode.

I have an M by N array of floats. Associated with the columns are 
character labels
['a','b','b','c','d','e','e','e']  note: already sorted so duplicates 
are contiguous

I want to replace the 2 'b' columns with the sum of the 2 columns. 
Similarly, replace the 3 'e' columns with the sum of the 3 'e' columns.

The resulting array still has M rows but less than N columns. Anyone? 
Could be any harder than Sudoku.

Mathew

Re: [Numpy-discussion] Release of 1.0b5 this weekend

[Charles R H. <cha...@gm...>]

On 8/29/06, Tim Hochberg <tim...@ie...> wrote:
>
> David M. Cooke wrote:
> > On Tue, 29 Aug 2006 14:03:39 -0700
> > Tim Hochberg <tim...@ie...> wrote:
> >
> >
> >> Of these,  clip, conjugate and round support an 'out' argument like
> that
> >> supported by ufunces;  byteswap has a boolean argument telling it
> >> whether to perform operations in place; and sort always operates in
> >> place. Noting that the ufunc-like methods (max, argmax, etc) appear to
> >> support the 'out' argument as well although it's not documented for
> most
> >> of them, it looks to me as if the two odd methods are byteswap and
> sort.
> >> The method situation could be made more consistent by swapping the
> >> boolean inplace flag in byteswapped with another 'out' argument and
> also
> >> having sort not operate in place by default, but also supply an out
> >> argument there. Thus:
> >>
> >> b = a.sort()   # Returns a copy
> >> a.sort(out=a) # Sorts a in place
> >> a.sort(out=c) # Sorts a into c (probably just equivalent to c = a.sort
> ()
> >> in this case since we don't want to rewrite the sort routines)
> >>
> >
> > Ugh. That's completely different semantics from sort() on lists, so I
> think
> > it would be a source of bugs (at least, it would mean keeping two
> different
> > ideas of .sort() in my head).
> >
> Thinking about it a bit more, I'd leave sort alone (returning None and
> all).. I was (over)reacting to changing to sort to return self, which
> makes the set of methods both less consistent within itself, less
> consistent with python and more error prone IMO, which seems the worst
> possibility.


Here is Guido on sort:

I'd like to explain once more why I'm so adamant that *sort*() shouldn't
*return* 'self'.

This comes from a coding style (popular in various other languages, I
believe especially Lisp revels in it) where a series of side effects
on a single object can be chained like this:

  x.compress().chop(y).*sort*(z)

which would be the same as

  x.compress()
  x.chop(y)
  x.*sort*(z)

I find the chaining form a threat to readability; it requires that the
reader must be intimately familiar with each of the methods.  The
second form makes it clear that each of these calls acts on the same
object, and so even if you don't know the class and its methods very
well, you can understand that the second and third call are applied to
x (and that all calls are made for their side-effects), and not to
something else.

I'd like to reserve chaining for operations that *return* new values,
like string processing operations:

  y = x.rstrip("\n").split(":").lower()

There are a few standard library modules that encourage chaining of
side-effect calls (pstat comes to mind).  There shouldn't be any new
ones; pstat slipped through my filter when it was weak.

So it seems you are correct in light of the Python philosophy. For those
operators that allow specification of out I would still like to see a
special value that means inplace, I think it would make the code clearer. Of
course, merely having the out flag violates Guido's intent. The idea seems
to be that we want some way to avoid allocating new memory. So maybe
byteswap should be inplace and return None, while a copyto method could be
added. Then one would do

a.copyto(b)
b.byteswap()

instead of

b = a.byteswap()

-tim


Chuck

Re: [Numpy-discussion] A minor annoyance with MA

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

PGM wrote:

>Folks, 
>I keep running into the following problem since some recent update (I'm 
>currently running 1.0b3, but the problem occurred roughly around 0.9.8):
>
>  
>
>>>>import numpy.core.ma as MA
>>>>x=MA.array([[1],[2]],mask=False)
>>>>x.sum(None)
>>>>        
>>>>
>/usr/lib64/python2.4/site-packages/numpy/core/ma.py in reduce(self, target, 
>axis, dtype)
>    393                 m.shape = (1,)
>    394         if m is nomask:
>--> 395             return masked_array (self.f.reduce (t, axis))
>    396         else:
>    397             t = masked_array (t, m)
>
>TypeError: an integer is required
>#................................
>  
>
This bug has hopefully been fixed (in SVN).    Please let us know if it 
still persists.

-Travis

Re: [Numpy-discussion] A minor annoyance with MA

[Paul D. <pfd...@gm...>]

Whatever the current state of the implementation, the original intention was
that ma be, where it makes sense, a "drop-in" replacement for numpy arrays.
Being retired I don't read this list all that carefully but I did see some
subjects concerning axis defaults (about the 98th time we have had that
discussion I suppose) and perhaps ma and numpy got out of sync, even if they
were in sync to begin with.

For sum, x.sum() should be the sum of the entire array, no? And that implies
a default of None, doesn't it? So a default of zero or one would be wrong.

Oh well, back to my nap.

On 28 Aug 2006 22:26:54 -0700, PGM <pgm...@gm...> wrote:
>
> Folks,
> I keep running into the following problem since some recent update (I'm
> currently running 1.0b3, but the problem occurred roughly around 0.9.8):
>
> >>> import numpy.core.ma as MA
> >>> x=MA.array([[1],[2]],mask=False)
> >>> x.sum(None)
> /usr/lib64/python2.4/site-packages/numpy/core/ma.py in reduce(self,
> target,
> axis, dtype)
>     393                 m.shape = (1,)
>     394         if m is nomask:
> --> 395             return masked_array (self.f.reduce (t, axis))
>     396         else:
>     397             t = masked_array (t, m)
>
> TypeError: an integer is required
> #................................
>
> Note that x.sum(0) and x.sum(1)  work fine. I know some consensus seems to
> be
> lacking with MA, but still, I can't see why axis=None is not recognized.
>
> Corollary: with masked array, the default axis for sum is 0, when it's
> None
> for regular arrays. Is there a reason for this inconsistency ?
>
> Thanks a lot
>
> -------------------------------------------------------------------------
> 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 Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>