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

[Numpy-discussion] Missing docstrings

[David H. <dav...@gm...>]

Hi,
For the beta release, it would be nice if every function had a docstring,
even a small one.  See Ticket
#174<http://projects.scipy.org/scipy/numpy/ticket/174>

Missing docstrings:
In [116]: ['issubsctype', 'unicode_', 'string', 'float96', 'pkgload',
'void', 'unicode0', 'void0', 'object0', 'memmap', 'nan_to_num',
'PackageLoader', 'object_', 'dtype', 'unsignedinteger', 'uintc', 'uint0',
'uint8', 'chararray', 'uint64', 'finfo', 'add_newdoc', 'array_repr',
'array_str', 'longlong', 'int16', 'mat', 'uint', 'correlate', 'int64',
'choose', 'complexfloating', 'recarray', 'mean', 'str_', 'ulonglong',
'matrix', 'uint32', 'byte', 'ctypes_load_library', 'signedinteger', 'ndim',
'number', 'bool8', 'msort', 'bool_', 'inexact', 'broadcast', 'short',
'ubyte', 'std', 'double', 'require', 'take', 'issubclass_', 'longfloat',
'deprecate', 'bincount', 'array2string', 'float64', 'ushort', 'float_',
'geterrobj', 'iterable', 'intp', 'flexible', 'sctype2char', 'longdouble',
'flatiter', 'generic', 'show_config', 'i0', 'uintp', 'character', 'uint16',
'float32', 'int32', 'integer', 'get_printoptions', 'seterrobj',
'add_docstring', 'intc', 'var', 'int_', 'histogram', 'issubdtype', 'int0',
'int8', 'record', 'obj2sctype', 'single', 'floating', 'test', 'string0']



In the process of adding docstrings, I noted some slight bugs:

bincount returns an error if the input array mixes float and ints, while it
accepts lists with mixed floats and ints.

histogram does not deal gracefully with the range attribute. All values
greater than range[1] are put in the last bin, which is probably not the
expected behavior.

Cheers,

David

[Numpy-discussion] ix_ and boolean indices

[Martin W. <mar...@gm...>]

Hi all,

for me

M [ix_(I, J)]

does not work if I, J are boolean arrays. Is this intended or a bug/missing 
feature?

And is there a way (other than I = where (I) [0] etc.) to make it work?

Thanks,
Martin

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

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

Does anyone use transpose for anything besides two dimensional arrays? For
arrays that aren't matrices at heart the meaning of transpose is pretty
arbitrary, so the only virtue I see in having an attribute would be less
typeing. So put it in the documentation. As an aside, being able to specify
axis in dot might obviate many cases of *.T and *.H and make inner a special
case.

>
> > 1) .T  Have some kind of .T attribute


 +1

>
> >    If >0 on this then:
> >
> >    a) .T == .swapaxes(-2,-1)


-1

>    b) .T == .transpose()


+1

>    c) .T raises error for ndim > 2


-1

>
> >    d) .T returns (N,1) array for length (N,) array


-1

>    e) .T returns self for ndim < 2


+1

>
> > 2) .H  returns .T.conj()


+1

>
> > 3) .M  returns matrix version of array


no opinion.

>
> > 4) .A  returns basearray (useful for sub-classes).


no opinion

Chuck

[Numpy-discussion] numpy book

[Jonathan T. <jon...@st...>]

I bought a copy of the numpy book sometime in January which I have since 
lost in a careless mistake.

Is there a way to get another (updated) copy?

I couldn't see how this was done on the website.

Thanks,

Jonathan

-- 

------------------------------------------------------------------------
Jonathan Taylor                           Tel:   650.723.9230
Dept. of Statistics                       Fax:   650.725.8977
Sequoia Hall, 137                         www-stat.stanford.edu/~jtaylo
390 Serra Mall
Stanford, CA 94305

Re: [Numpy-discussion] What's wrong with matrices?

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

On 7/7/06, Ed Schofield <sch...@ft...> wrote:
>
> Bill Baxter wrote:
> > I would be all for a matrix class that was on equal footing with array
> > and as easy to use as matrices in Matlab.  But my experience using
> > numpy.matrix was far from that, and, given the lack of enthusiasm for
> > matrices around here, that seems unlikely to change.  However, I'm
> > anxious to see what Ed has up his sleeves in the other thread.
>
> Okay ... <Ed rolls up his sleeves> ... let's make this the thread ;)
> I'd like to know why you, Sven, and anyone else on the list have gone
> back to using arrays after trying matrices.  What was inconvenient about
> them?  I'd like a nice juicy list.  The whole purpose of the matrix
> class is to simplify 2d linear algebra.  Where is it failing?


Okay, here are a few that come to mind.
1) Functions that take a matrix but return an array.  Maybe these are all
fixed now.  But they better be fixed not just in numpy but in scipy too.  To
me this implies there needs to be some standard idiom for how to write a
generic array-protocol-using function so that you don't have to think about
it.

2) At the time I was using matrix, scalar * matrix was broken.  Fixed now,
but that kind of thing just shouldn't happen.  There should be a tests for
basic operations like that if there aren't already.

3) mat() doesn't make sense as a shortcut for matrix construction.  It only
saves 3 letters over typing matrix(), and asmatrix is generally more
useful.  So mat() should be a synonym for asmatrix()

4) eye,empty,rand,ones,zeros,arange and anything else that builds an array
from scratch or from a python list should have a matrix equivalent.

5) I've got squeezes like crazy all over my matrix-using code.  Maybe this
was a bug in 0.9.5 or so that's been fixed?  I do seem to recall some
problem with indexing or c_ or something that was causing matrices to grow
extra levels of length 1 axes.  Again, like the scalar*matrix bug, things
like that shouldn't happen.

6) No good way to do elementwise operations?  Sometimes you just want to do
an elementwise mult or divide or exponentiation.  I guess you're supposed to
do  Z = asmatrix(X.A * Y.A).  Yah, right.

7) Finally, once all that is fixed, I find the slavish adherance to ndim=2
to be too restrictive.
    a) Sometimes it's useful to have a stack of matrices.  Pretty often, in
fact, for me.  I guess I could use a python list of matrices or an object
array of matrix or something, but I also think there are times when it's
useful to treat different pairs of axes as the 'matrix' part.   So I'd like
matrices to be able to have ndim>2.
    b) On the other end, I think ndim<2 is useful sometimes too.  Take a
function like mean(), for example.  With no arguments  the return value is a
1x1 matrix (as opposed to a scalar).  That just looks silly.  And it doesn't
work everywhere a scalar would, e.g. with a python built-in like round().
Or take indexing.  It seems odd to me that where() reurns a tuple of
shape==(1,N) objects instead of just (N,) .  Maybe I can get over that
though, as long as it works for indexing (which it seems it does).   But I
think the scalar return case is a real issue.  Here's another: sum().  For
an array you can do sum(sum(a)) and get a scalar if a is 2-d, but for matrix
sum(sum(m)) is the same as sum(m).   And along these lines, m[newaxis] just
silently doesn't do anything.  That doesn't seem right.

That's all I can think of for now.

Beyond that, looming in the back of my mind there's the question of what
happens when we decide we want to have sparse matrices?  Or masked sparse
matrices, for that matter.  These specialty array objects all seem to me
like they should be some sort of mix-ins.  The features they provide are
(conceptually, anyway) independent.  Concrete sibling classes doesn't really
seem like the right inheritance relationship.


> I'd like to help to make matrices more usable.  Tell me what you want,
> and I'll work on some patches.


Thanks for giving it a shot.  I'm currently trying to compile numpy from svn
on Win32 for the first time myself.  If it goes well I can probably help run
tests or maybe even on some coding.  But I still have yet to get past ATLAS.

--Bill

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

[Gary R. <gr...@bi...>]

Sasha wrote:
> On 7/6/06, Bill Baxter <wb...@gm...> wrote:
>> ...
>> Yep, like Tim said.  The usage is say a N sets of basis vectors.  Each set
>> of basis vectors is a matrix.
> 
> This brings up a feature that I really miss from numpy: an ability to do
> 
> array([f(x) for x in a])
> 
> without python overhead.

I'd find this really useful too. I'm doing lots of this in my recent code:
array([f(x,y) for x in a for y in b]).reshape(xxx)


Gary R.

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

[George N. <gn...@go...>]

On 07/07/06, Travis Oliphant <oli...@ie...> wrote:
>
> This is a call for a vote on each of the math attributes.  Please post
> your vote as
>
> +1 :  support
> +0 :  don't care so go ahead
> -0 :  don't care so why do it
> -1 :  against
>
> Vote on the following issues separately:
>
>
>
> 1) .T  Have some kind of .T attribute
+1
>
>    If >0 on this then:
>
>    a) .T == .swapaxes(-2,-1)
-1
>
>    b) .T == .transpose()
>
>    c) .T raises error for ndim > 2
-1
>
>    d) .T returns (N,1) array for length (N,) array
-1
>
>    e) .T returns self for ndim < 2
+1
>
>
> 2) .H  returns .T.conj()
-1
>
>
> 3) .M  returns matrix version of array
-1
>
>
> 4) .A  returns basearray (useful for sub-classes).
-0

George.

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

[George N. <gn...@go...>]

On 07/07/06, Robert Hetland <rhe...@ma...> wrote:
[snip]
> However, I use transpose often when not dealing with linear algebra, in
> particular with reading in data, and putting various columns into
> variables.  Also, occasional in plotting (which expects things in 'backward'
> order relative to x-y space), and communicating between fortran programs
> (which typically use 'forward' order (x, y, z)) and numpy (backward -- (z,
> x, y)).
>
This is my usage as well. Also my primitive knowledge of numpy
requires use of the transpose when iterating over indexes from where.
Moreover I think the notation .T is perfectly reasonable. So I agree
with:

> I am very much in favor of .T, but it should be a full .transpose(), not
> just swap the last two axes.  I don't care so much for the others.

+1 for .T == .transpose()

George Nurser.

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

[Paul B. <peb...@gm...>]

On 7/7/06, Travis Oliphant <oli...@ie...> wrote:
>
> This is a call for a vote on each of the math attributes.  Please post
> your vote as
>
> +1 :  support
> +0 :  don't care so go ahead
> -0 :  don't care so why do it
> -1 :  against
>
> Vote on the following issues separately:
>
>
>
> 1) .T  Have some kind of .T attribute

-1

>    If >0 on this then:
>
>    a) .T == .swapaxes(-2,-1)
>
>    b) .T == .transpose()
>
>    c) .T raises error for ndim > 2
>
>    d) .T returns (N,1) array for length (N,) array
>
>    e) .T returns self for ndim < 2
>
>
> 2) .H  returns .T.conj()

-1

> 3) .M  returns matrix version of array

-1

> 4) .A  returns basearray (useful for sub-classes).

-1

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

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

On Thu, Jul 06, 2006 at 10:26:12PM -0600, Travis Oliphant wrote:
> 1) .T  Have some kind of .T attribute

-1, since the expected behaviour of .T is different depending on
problem context.

>    a) .T =3D=3D .swapaxes(-2,-1)

The fact that this was proposed just demonstrates the fact.  If you
have a (10,5) array, .T gives the expected (5,10) array.  But if you
have a (10,10,3) RGB image as an ndarray, .T gives a (10,3,10)
array... which is certainly not what you'd expect in an image
processing context.

St=E9fan

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

[Robert H. <rhe...@ma...>]

+1    1b)  .T == .transpose()

-1     all others



On Jul 7, 2006, at 12:26 AM, Travis Oliphant wrote:

>
> This is a call for a vote on each of the math attributes.  Please post
> your vote as
>
> +1 :  support
> +0 :  don't care so go ahead
> -0 :  don't care so why do it
> -1 :  against
>
> Vote on the following issues separately:
>
>
>
> 1) .T  Have some kind of .T attribute
>
>    If >0 on this then:
>
>    a) .T == .swapaxes(-2,-1)
>
>    b) .T == .transpose()
>
>    c) .T raises error for ndim > 2
>
>    d) .T returns (N,1) array for length (N,) array
>
>    e) .T returns self for ndim < 2
>
>
> 2) .H  returns .T.conj()
>
>
> 3) .M  returns matrix version of array
>
>
> 4) .A  returns basearray (useful for sub-classes).
>
>
>
> -Travis
>
>
>
>
>
> 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

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

[Robert H. <rhe...@ma...>]

On Jul 6, 2006, at 2:54 PM, Robert Kern wrote:

> I don't think that just because arrays are often used for linear  
> algebra that
> linear algebra assumptions should be built in to the core array type.

True.  This argues against the MAH attributes.

However, I use transpose often when not dealing with linear algebra,  
in particular with reading in data, and putting various columns into  
variables.  Also, occasional in plotting (which expects things in  
'backward' order relative to x-y space), and communicating between  
fortran programs (which typically use 'forward' order (x, y, z)) and  
numpy (backward -- (z, x, y)).

I am very much in favor of .T, but it should be a full .transpose(),  
not just swap the last two axes.  I don't care so much for the others.

+1 for .T == .transpose()

-Rob

Re: [Numpy-discussion] What's wrong with matrices?

[Ed S. <sch...@ft...>]

Bill Baxter wrote:
> I think the thread to this point can be pretty much summarized by:
>
> while True:
>     Bill: "2D transpose is common so it should have a nice syntax"
>     Tim, Robert, Sasha, and Ed: "No it's not."
>
> Very well.  I think it may be a self fulfilling prophecy, though. 
> I.e. if matrix operations are cumbersome to use, then -- surprise
> surprise -- the large user base for matrix-like operations never
> materializes.  Potential converts just give numpy the pass, and go to
> Octave or Scilab, or stick with Matlab, R or S instead. 
>
> Why all the fuss about the .T?  Because any changes to functions (like
> making ones() return a matrix) can easily be worked around on the user
> side, as has been pointed out.  But as far as I know -- do correct me
> if I'm wrong -- there's no good way for a user to add an attribute to
> an existing class.  After switching from matrices back to arrays, .T
> was the only thing I really missed from numpy.matrix.
>
> I would be all for a matrix class that was on equal footing with array
> and as easy to use as matrices in Matlab.  But my experience using
> numpy.matrix was far from that, and, given the lack of enthusiasm for
> matrices around here, that seems unlikely to change.  However, I'm
> anxious to see what Ed has up his sleeves in the other thread.

Okay ... <Ed rolls up his sleeves> ... let's make this the thread ;) 
I'd like to know why you, Sven, and anyone else on the list have gone
back to using arrays after trying matrices.  What was inconvenient about
them?  I'd like a nice juicy list.  The whole purpose of the matrix
class is to simplify 2d linear algebra.  Where is it failing?

I also went back to arrays after trying out matrices for some 2d linear
algebra tasks, since I found that using matrices increased my code's
complexity.  I can describe the problems I had with them later, but
first I'd like to hear of others' experiences.

I'd like to help to make matrices more usable.  Tell me what you want,
and I'll work on some patches.

-- Ed

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

[Paulo J. da S. e S. <pjs...@im...>]

Em Qui, 2006-07-06 às 22:26 -0600, Travis Oliphant escreveu:
> This is a call for a vote on each of the math attributes.  Please
post 
> your vote as
> 
> +1 :  support
> +0 :  don't care so go ahead
> -0 :  don't care so why do it
> -1 :  against
> 
> Vote on the following issues separately: 
> 
> 
> 
> 1) .T  Have some kind of .T attribute
 
+1

> 
>    If >0 on this then:
> 
>    a) .T == .swapaxes(-2,-1)
> 

+0

>    b) .T == .transpose()
> 

-0

>    c) .T raises error for ndim > 2
> 

+0

>    d) .T returns (N,1) array for length (N,) array
> 

+0

>    e) .T returns self for ndim < 2

-1

> 2) .H  returns .T.conj()
> 

+0 

> 3) .M  returns matrix version of array
> 

-1

> 4) .A  returns basearray (useful for sub-classes).
> 

+0

Paulo
-- 
Paulo José da Silva e Silva 
Professor Assistente do Dep. de Ciência da Computação
(Assistant Professor of the Computer Science Dept.)
Universidade de São Paulo - Brazil

e-mail: pjs...@im...        Web: http://www.ime.usp.br/~pjssilva

Teoria é o que não entendemos o    (Theory is something we don't)
suficiente para chamar de prática. (understand well enough to call) 
                                   (practice)

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

[Bruce S. <bso...@gm...>]

On 7/6/06, Travis Oliphant <oli...@ie...> wrote:
>
> This is a call for a vote on each of the math attributes.  Please post
> your vote as
>
> +1 :  support
> +0 :  don't care so go ahead
> -0 :  don't care so why do it
> -1 :  against
>
> Vote on the following issues separately:
>
>
>
> 1) .T  Have some kind of .T attribute
-1 because I prefer what is already present although I would prefer
the option of inplace or a taking a copy. Also I don't find .T
particularly intuitive (for example,  R and SAS IML have a t()
function - SAS IML also uses a backtick but that has not been very
portable).

>
>    If >0 on this then:
>
>    a) .T == .swapaxes(-2,-1)
>
>    b) .T == .transpose()
>
>    c) .T raises error for ndim > 2
>
>    d) .T returns (N,1) array for length (N,) array
>
>    e) .T returns self for ndim < 2
>
>
> 2) .H  returns .T.conj()

-/+0 I don't care either way.

>
>
> 3) .M  returns matrix version of array

-1 as I think asmatrix etc is clearer.

>
>
> 4) .A  returns basearray (useful for sub-classes).

-1 as I think something like asarray etc is clearer and require
explicit calling.

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

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

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

I think the thread to this point can be pretty much summarized by:

while True:
    Bill: "2D transpose is common so it should have a nice syntax"
    Tim, Robert, Sasha, and Ed: "No it's not."

Very well.  I think it may be a self fulfilling prophecy, though.  I.e. if
matrix operations are cumbersome to use, then -- surprise surprise -- the
large user base for matrix-like operations never materializes.  Potential
converts just give numpy the pass, and go to Octave or Scilab, or stick with
Matlab, R or S instead.

Why all the fuss about the .T?  Because any changes to functions (like
making ones() return a matrix) can easily be worked around on the user side,
as has been pointed out.  But as far as I know -- do correct me if I'm wrong
-- there's no good way for a user to add an attribute to an existing class.
After switching from matrices back to arrays, .T was the only thing I really
missed from numpy.matrix.

I would be all for a matrix class that was on equal footing with array and
as easy to use as matrices in Matlab.  But my experience using
numpy.matrixwas far from that, and, given the lack of enthusiasm for
matrices around
here, that seems unlikely to change.  However, I'm anxious to see what Ed
has up his sleeves in the other thread.

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

[Ed S. <sch...@ft...>]

On 07/07/2006, at 6:26 AM, Travis Oliphant wrote:

> 1) .T  Have some kind of .T attribute

-1

The meaning of .T is unclear for ndim != 2, as the plethora of sub- 
vote options shows. And we already have a matrix object designed  
explicitly for the case ndim == 2. Let's make matrix objects more  
useful, rather than give up on matrices and hard-wire 2d concepts  
into arrays. I'm willing to help with this, and I'll post some ideas  
to a different thread.

>    If >0 on this then:
>
>    a) .T == .swapaxes(-2,-1)
>
>    b) .T == .transpose()
>
>    c) .T raises error for ndim > 2
>
>    d) .T returns (N,1) array for length (N,) array
>
>    e) .T returns self for ndim < 2

(Just for the record, I think option (d) is positively evil.)


> 2) .H  returns .T.conj()

-1

I'm against this for the same reasons I'm against .T, but more  
strongly, due to the extra memory allocation.


> 3) .M  returns matrix version of array

-0

This would have the advantage of making .T and .H redundant for 2-d  
arrays, since they'd be accessible as matrix attributes anyway. But I  
don't see a strong enough case for this as an extra attribute, since  
asmatrix() and mat() are available anyway.

I would like to deprecate mat() as an alias for matrix (by moving mat  
to the oldnumeric namespace); this would break the expectation that  
mat() perform a copy, and allow users to write

 >>> from numpy import asmatrix as mat

instead if they need a short, simple syntax that avoids the copy  
overhead.

It's also trivial for any serious user of matrices to write wrapper  
functions for ones, zeros, etc., such as

def matones(*args):
     return asmatrix(ones(*args))

There might be an argument for including these in e.g. the  
numpy.matrix namespace. This would make a .M attribute even less  
compelling.


> 4) .A  returns basearray (useful for sub-classes).

-0

This could be a good idea, but I'm not clear enough on its  
implications to vote either way.


-- Ed

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

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

Travis Oliphant schrieb:

> 
> 1) .T  Have some kind of .T attribute
> 

+0
(the discussion in the .T thread convinced me it's better to keep the
matrix playground as a separate subclass, and so it's not important for
me what happens with pure arrays)

> 
> 2) .H  returns .T.conj()

+0
> 
> 
> 3) .M  returns matrix version of array

+1 !!
(Either that, or I will soon get on your nerves demanding matrix
versions of ones, zeros, rand, eye etc.!)

> 
> 
> 4) .A  returns basearray (useful for sub-classes).

+0 ? (Already exists for matrix, doesn't it?)

-sven

[Numpy-discussion] Why is my array not contiguous?

[<je...@fy...>]

Hi!

With numpy-0.9.9.2726, I do this:

 >>> x =3D arange(4)
 >>> y =3D x[newaxis, :]

I would expect both arrays to be contiguous:

 >>> x.flags.contiguous, y.flags.contiguous
(True, False)

Shouldn't y be contiguous?  Maybe it's because of the strange strides:

 >>> y.strides
(0, 4)
 >>> y.strides =3D (16, 4)
 >>> y.flags.contiguous
True

Jens J=C3=B8rgen

Re: [Numpy-discussion] Speed degression?

[Steffen L. <ste...@gm...>]

T24gVGh1cnNkYXkgMDYgSnVseSAyMDA2LCBUcmF2aXMgT2xpcGhhbnQgd3JvdGU6Cj4gVGhpcyBj
YW4gdGVzdCB0aGUgc3BlZWQgb2YgdGhlIGltcGxlbWVudGF0aW9ucy4KCldpdGggdGhlIGxhdGVz
dCBtb2RpZmljYXRpb25zIGkgZ2V0IHRoZSBmb2xsb3dpbmcKClJlc3VsdHMgKGluIHVzZWMgcGVy
IGxvb3ApOgqgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgc2luLWFycmF5IKAg
oCCgIKAgoCCgbW9kLWFycmF5IKAKCQkJICAgICAgICAgICAgICB1c2Vfc2NhbGFybWF0aC91c2Vf
cHl0aG9ubWF0aKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIAoKoE51bWVyaWMg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDEzNCCgIKAgoCCgIKAgoCCgIKAgoCAxOCCg
IKAgoCCgIAqgIAqgbnVtcHkgMC45LjggoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIDk3IKAg
oCCgIKAgoCCgIKAgoCCgIDU1CgqgbnVtcHkgMC45LjkuMjc2NCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAxMTQvNzggoCCgIKAgoCCgIKAgoCCgNTUvMjEKoCCgCqBudW1weSAwLjkuOCArIG1hdGggoCCg
IKAgoCCgIKAgoCCgIKAgoCCgMzgKCqBudW1weSAwLjkuOS4yNzY0ICsgbWF0aCCgIKAgoCCgIKAg
oCCgICAzOC8yMwqgIAqgTnVtZXJpYyArIG1hdGggoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDIz
CgoKVGhlIG5ld2VzdCB2ZXJzaW9uIHNlZW1zIHRvIGJlIGZhc3RlciB0aGVuIE51bWVyaWMgaW4g
YWxsIHNpbi1hcnJheSB0ZXN0cy4gCkFsc28gdGhlIHNwZWVkIG9mIG1vZC1hcnJheSBoYXMgaW1w
cm92ZWQgYSBsb3QuCgpNYW55IHRoYW5rcywKU3RlZmZlbgoK

Re: [Numpy-discussion] .T Transpose shortcut for arrays again

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

Bill Baxter wrote:
> On 7/7/06, *Robert Kern* <rob...@gm... 
> <mailto:rob...@gm...>> wrote:
>
>     Bill Baxter wrote:
>     > I am also curious, given the number of times I've heard this
>     nebulous
>     > argument of "there are lots kinds of numerical computing that don't
>     > invlolve linear algebra", that no one ever seems to name any of
>     these
>     > "lots of kinds".  Statistics, maybe?  But you can find lots of
>     linear
>     > algebra in statistics.
>
>     That's because I'm not waving my hands at general fields of
>     application.  I'm
>     talking about how people actually use array objects on a
>     line-by-line basis. If
>     I represent a dataset as an array and fit a nonlinear function to
>     that dataset,
>     am I using linear algebra at some level? Sure! Does having a .T
>     attribute on
>     that array help me at all? No. Arguing about how fundamental
>     linear algebra is
>     to numerical endeavors is entirely besides the point.
>
>
> Ok.  If line-by-line usage is what everyone really means, then I'll 
> get off the linear algebra soap box, but that's not what it sounded 
> like to me.
>
> So, if you want to talk line-by-line, I really can't talk about much 
> beside my own code.  But I just grepped through it and out of 2445 
> non-empty lines of code:
>
> 927 lines contain '='
> 390 lines contain a '['
> 75 lines contain matrix,asmatrix, or mat
> ==>  47 lines contain a '.T' or '.transpose' of some sort.  <==
> 33 lines contain array, or asarray, or asanyarray
> 24 lines contain 'rand('  --- I use it for generating bogus test data 
> a lot
> 17 lines contain 'newaxis' or 'NewAxis'
> 16 lines contain 'zeros('
> 13 lines contain 'dot('
> 12 lines contain 'empty('
> 8 lines contain 'ones('
> 7 lines contain 'inv('
In my main project theres about 26 KLOC (including blank lines), 700 or 
so of which use numeric (I prefix everything with np. so it's easy to 
count. Of those lines 29 use transpose, and of those 29 lines at most 9 
could use a T attribute. It's probably far less than that since I didn't 
check the dimensionality of the arrays involved. Somewhere between 0 and 
5 seems likely.

>
> I'm pretty new to numpy, so that's all the code I got right now.  I'm 
> sure I've written many more lines of emails about numpy than I have 
> lines of actual numpy code.  :-/
>
> But from that, I can say that -- at least in my code -- transpose is 
> pretty common.  If someone can point me to some larger codebases 
> written in numpy or numeric, I'd be happy to do a similar analysis of 
> those.
>
>
>     I'm not saying that people who do use arrays for linear algebra
>     are rare or
>     unimportant. It's that syntactical convenience for one set of
>     conventional ways
>     to use an array object, by itself, is not a good enough reason to
>     add stuff to
>     the core array object.
>
>
> I wish I had a way to magically find out the distribution of array 
> dimensions used by all numpy and numeric code out there.  My guess is 
> it would be something like 1-d: 50%,  2-d: 30%, 3-d: 10%, everything 
> else: 10%.  I can't think of a good way to even get an estimate on 
> that.  But in any event, I'm positive ndims==2 is a significant 
> percentage of all usages.  It seems like the opponents to this idea 
> are suggesting the distribution is more flat than that.  But whatever 
> the distribution is, it has to have a fairly light tail since memory 
> usage is exponential in ndim.  If ndim == 20, then it takes 8 
> megabytes just to store the smallest possible non-degenerate array of 
> float64s ( i.e. a 2x2x2x2x...)
I would guess that it falls off fast after n=3, but that's just a guess. 
Personally, the majority of my code deals in 3D arrays (2x2xN and 4x4xN 
for the most part). These are arrays of vectors holding scattering data 
at N different frequency or time points. The 2D arrays that I do use are 
for rendering imaging (the actual rendering is done in C since Python 
wasn't fast enough and numpy wasn't really suitable for it). So, you see 
that for me at least, a T attribute is complete cruft. Useless for the 
3D arrays, not needed for the 2D arrays, and again useless for the 1D 
arrays. I suspect that in general, the image processing types, who use a 
lot of 2D arrays, are probably not heavy users of transpose, but I'm not 
certain of that.
>
> It seems crazy to even be arguing this.  Transposing is not some 
> specialized esoteric operation.  It's important enough that R and S 
> give it a one letter function, and Matlab, Scilab, K all give it a 
> single-character operator.  [*]   Whoever designed the numpy.matrix 
> class also thought it was worthy of a shortcut, and I think came up 
> with a pretty good syntax for it.   And the people who invented math 
> itself
?!

> decided it was worth assigning a 1-character exponent to it. 
>
> So I think there's a clear argument for having a .T attribute.  But 
> ok, let's say you're right, and a lot of people won't use it.  Fine.   
> IT WILL DO THEM ABSOLUTELY NO HARM.  They don't have to use it if they 
> don't like it!   Just ignore it.  Unlike a t() function, .T doesn't 
> pollute any namespace users can define symbols in, so you really can 
> just ignore it if you're not interested in using it.  It won't get in 
> your way.
This is a completely bogus argument. All features cost -- good and ill 
alike. There's implementation cost and maintenance cost, both likely 
small in this case, but not zero. There's cognitive costs associated 
with trying to hold all of the various numpy methods, attributes and 
functions in ones head at once. There's pedagogical costs trying to 
explain how things fit together. There's community costs in that people 
who are allegedly coding with core numpy end up using mutually 
incomprehensible dialects. TANSTAFL.

The ndarray object has far too many methods and attributes already IMO, 
and you have not made a case that I find convincing that this is 
important enough to further cruftify it.
>
> For the argument that ndarray should be pure like the driven snow, 
> just a raw container for n-dimensional data,
Did anyone make that argument. No? I didn't think so.

> I think that's what the basearray thing that goes into Python itself 
> should be.  ndarray is part of numpy and numpy is for numerical 
> computing.
And?

Regards,

-tim

>
> Regards,
> --Bill
>
> [*] Full disclosure: I did find two counter-examples -- Maple and 
> Mathematica.  Maple has only a transpose() function and Mathematica 
> has only Transpose[] (but you can use [esc]tr[esc] as a shortcut)  
> However, both of those packages are primarily known for their 
> _symbolic_ math capabilities, not their number crunching, so they less 
> are similar to numpy than R,S,K,Matlab and Scilab in that regard.
>
> ------------------------------------------------------------------------
>
> 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
>   

Re: [Numpy-discussion] Enhancing dot()

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

Bill Baxter wrote:
> On 7/7/06, *Tim Hochberg* <tim...@co... 
> <mailto:tim...@co...>> wrote:
>
>     > The funny thing is that having a dot(a,b,c,...) would lead to the
>     > exact same kind of hidden performance problems you're arguing
>     against.
>     Not exactly arguing -- this isn't why I don't like H and friends
>     -- just
>     noting that this is one of the traps that people are likely to
>     fall into
>     when transferring equations to code.
>
>
> There's a strong argument to be made that the whole design of most 
> array math packages is flawed and leads to inefficient code.  The 
> classic example is something like:
>   A = B + C - 2*D
> where all the matrices are 2million x 2million.  I think for numpy 
> that would basically do:
> tmp = B+C
> tmp2 = 2*D
> tmp3 = tmp - tmp2
> A = tmp3
>
> Allocating three huge tmp variables and probably doing an extra copy 
> or two in there, when the best thing to do would be more like:
> A = D
> A *= -2
> A += C
> A += B
>
> Or something like that.
Yeah -- that's not quite right since you've clobbered B.  But that is 
essentially the dark road that people go down in performance critical 
sections on occasion.

> The point is that you give up any notion of having optimal code the 
> minute you start using something like numpy.  And you do so happily 
> for the ability to get stuff done faster and have nicer looking, more 
> readable code in the end.  When everything works, that's when you hit 
> the "go fast button" if you even really need to.
That's what numexpr is for.

A = numexpr.evaluate("B + C - 2*D")

Evaluates this considerably faster than numpy and doesn't chew up all 
that extra memory. Actually that's why it's faster -- it's much more 
memory friendly. It's also a lot less flexible, although that's been 
improving. Still you want numpy as a base, but numexpr is a viable 
alternative for those critical sections where once you would resort to 
x= or worse, three argument ufuncs.

-tim


>
> --bb

Re: [Numpy-discussion] Enhancing dot()

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

On 7/7/06, Tim Hochberg <tim...@co...> wrote:
>
> > The funny thing is that having a dot(a,b,c,...) would lead to the
> > exact same kind of hidden performance problems you're arguing against.
> Not exactly arguing -- this isn't why I don't like H and friends -- just
> noting that this is one of the traps that people are likely to fall into
> when transferring equations to code.


There's a strong argument to be made that the whole design of most array
math packages is flawed and leads to inefficient code.  The classic example
is something like:
  A = B + C - 2*D
where all the matrices are 2million x 2million.  I think for numpy that
would basically do:
tmp = B+C
tmp2 = 2*D
tmp3 = tmp - tmp2
A = tmp3

Allocating three huge tmp variables and probably doing an extra copy or two
in there, when the best thing to do would be more like:
A = D
A *= -2
A += C
A += B

Or something like that.  The point is that you give up any notion of having
optimal code the minute you start using something like numpy.  And you do so
happily for the ability to get stuff done faster and have nicer looking,
more readable code in the end.  When everything works, that's when you hit
the "go fast button" if you even really need to.

--bb

Re: [Numpy-discussion] Call for a vote on .M .A .T .H attributes

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

On 7/7/06, Travis Oliphant <oli...@ie...> wrote:
>
>
> 1) .T  Have some kind of .T attribute


+1

   If >0 on this then:
>
>    a) .T == .swapaxes(-2,-1)


+1

   b) .T == .transpose()


+0

   c) .T raises error for ndim > 2


+0

   d) .T returns (N,1) array for length (N,) array


+1

   e) .T returns self for ndim < 2


+0

2) .H  returns .T.conj()


+1

3) .M  returns matrix version of array


-1

4) .A  returns basearray (useful for sub-classes).


+0

Re: [Numpy-discussion] Enhancing dot()

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

Bill Baxter wrote:
> On 7/7/06, *Tim Hochberg* <tim...@co... 
> <mailto:tim...@co...>> wrote:
>
>     I'd caution here though that the H is another thing that's going to
>     encourage people to write code that's less accurate and slower than it
>     needs to be. Consider the simple equation:
>
>     [Side note: Here's something I periodically think about -- it
>     would be
>     nice if dot could take multiple arguments and chain them into a series
>     of matrix multiplies so that dot(dot(a, b), a.H) could be written
>     dot(a,
>     b, a.H). I'll use that here for clarity].
>
>     x = dot(a, b, a.H)
>
>     versus:
>
>     x  = dot(a.real, b, a.real.transpose()) + dot(a.imag, b,
>     a.imag.transpose())
>
>     The latter should be about twice as fast and won't have any pesky
>     imaginary residuals showing up from the finite precision of the
>     various
>     operations.
>
>
> The funny thing is that having a dot(a,b,c,...) would lead to the 
> exact same kind of hidden performance problems you're arguing against.
Not exactly arguing -- this isn't why I don't like H and friends -- just 
noting that this is one of the traps that people are likely to fall into 
when transferring equations to code.

> The cost of a series of matrix multiplications can vary dramatically 
> with the order in which you perform them.  E.g. A*B*C*v where A,B,C 
> are 2-dim and v is a column vector.  Then you should do (A*(B*(C*v))), 
> and definitely not ((A*B)*C)*v)
That's a good point.
> But that said, dot could maybe be made smart enough to figure out the 
> best order.   That would be a nice feature. 
> dot(A, dot(B, dot(C, v))) is pretty darn ugly.  I seem to remember 
> finding the best order being an example of a dynamic programming 
> problem, and probably O(N^2) in the number of terms.  But presumably N 
> is never going to be very big, and the N==2 (no choice) and N=3 (only 
> one choice) cases could be optimized.
You could probably just brute force it with out too much trouble. As you 
say O(n^2) is not that daunting when n is usually 2 or 3 and rarely over 
5. Perhaps cache the last few configurations tested since the same 
matrix size combinations will likely occur over and over.

Another interesting thought is one just wrapped an array with a wrapper 
that says "use the conjugate of what I'm wrapping", then dot(a, b H(a)) 
could do the write thing and only compute the real part of the 
equation,  assuming H(a) created the wrapper. That's starting to get 
complex though.


-tim