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

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

[Alexander B. <ale...@gm...>]

On 7/6/06, Tim Hochberg <tim...@co...> wrote:
> ...
> Overloading '+' sure seems perverse, but maybe that's just me.
>
The first time I saw it, it seemed perverse to me as well, but it
actually make a lot of sense:

1. It is visually appealing as in  '+' makes '|' from '-' and '-' from
'|' and looks close enough to 't'.
2. It puts an otherwise useless operator to work.
3. Prefix spelling suggests that it should be swapaxes(0,1) rather
than swapaxes(-2,-1), which is the choice made by K.
4. You can't get any shorter than that (at least using a fixed width font :-).
5. It already does the right thing for rank<2.

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

[Alexander B. <ale...@gm...>]

On 7/6/06, Tim Hochberg <tim...@co...> wrote:
> ...
> So this is essentially turning a row vector into a column vector? Is
> that right?
>
Being a definition, this is neither right nor wrong.  It all depends
on what you are using it for. If you want to distinguish row and
column vectors, you have to use rank-2, but it is convenient to to
think of rank-1 as an equivalent of either row or column and rank-0 as
a 1x1 array. If you define transpose as a rank-2 only operation, but
allow promotion of rank < 2 to rank 2, you end up with the rules of
S+.

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

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

Travis Oliphant wrote:
> Bill Baxter wrote:
>> So in short my proposal is to:
>> --  make a.T a property of array that returns a.swapaxes(-2,-1),
>> --  make a.H a property of array that returns 
>> a.conjugate().swapaxes(-2,-1)
>> and maybe
>> --  make a.M a property of array that returns numpy.asmatrix(a)
> 
> I've tentatively implemented all of these suggestions as well as adding 
> the .A attribute to the ndarray as well (so that all sub-classes and 
> array scalars can get back a view as an ndarray). 
> 
> I did this to make it easier to do matrix-like calculations with or 
> with-out matrices.   Matrix-calculation flexibility is still a sore-spot 
> for many and I think these syntatical-sugar attributes will help long term.
> 
> If there are no strong objections, then the recent  MATH attribute 
> checkin will stay.  If there are major objections, then we can back them 
> out without too much trouble as well.

Like Sasha, I'm mildly opposed to .T (as a synonym for .transpose()) and much 
more opposed to the rest (including .T being a synonym for .swapaxes(-2, -1)). 
It's not often that a proposal carries with it its own slippery-slope argument 
against itself.

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.

-- 
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] .T Transpose shortcut for arrays again

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

Sasha wrote:
> On 7/6/06, Bill Baxter <wb...@gm...> wrote:
>   
>> On 7/7/06, Sasha <nd...@ma...> wrote:
>> ... I think it's much
>> more common to want to swap just two axes, and the last two seem a logical
>> choice since a) in the default C-ordering they're the closest together in
>> memory and b) they're the axes that are printed contiguously when you say
>> "print A".
>>     
>
> It all depends on how you want to interpret a rank-K tensor.  You seem
> to advocate a view that it is a (K-2)-rank array of matrices and .T is
> an element-wise transpose operation. Alternatively I can expect that
> it is a matrix of (K-2)-rank arrays and then .T should be
> swapaxes(0,1).  Do you have real-life applications of swapaxes(-2,-1)
> for rank > 2?
>   
I do for what it's worth. At various times I use arrays of shape (n, n, 
d) (matrices of rank-1 arrays at you suggest above) and arrays of shape 
(d, n, n) (vectors of matrices as Bill proposes). Using swapaxes(-2, -1) 
would be right only half the time, but it would the current defaults for 
transpose are essentially never right for rank > 2. Then again they are 
easy to explain.

>   
>>> and swapaxes(-2,-1) is
>>> invalid for rank < 2.
>>>
>>>       
>>  At least in numpy 0.9.8, it's not invalid, it just doesn't do anything.
>>
>>     
>
> That's bad.  What sense does it make to swap non-existing axes? Many
> people would expect transpose of a vector to be a matrix.  This is the
> case in S+ and R.
>   
So this is essentially turning a row vector into a column vector? Is 
that right?

>>> My main objection is that a.T is fairly cryptic
>>> - is there any other language that uses attribute for transpose?
>>>       
>> Does it matter what other languages do?  It's not _that_ cryptic.
>>     
>
> If something is clear and natural, chances are it was done before.
> For me prior art is always a useful guide when making a design choice.
>  For example, in R, the transpose operation is t(a) and works on rank
> <= 2 only always returning rank-2.  K (an APL-like language) overloads
> unary '+' to do swapaxes(0,1) for rank>=2 and nothing for lower rank.
> Both R and K solutions are implementable in Python with R using 3
> characters and K using 1(!) compared to your two-character ".T"
> notation. 
Overloading '+' sure seems perverse, but maybe that's just me.

>  I would suggest that when inventing something new, you
> should consider prior art and explain how you invention is better.
> That's why what other languages do matter. (After all, isn't 'T'
> chosen because "transpose" starts with "t" in the English language?)
>
>   
>>  The standard way to write transpose is with a little T superscript in the upper
>> right.  We can't do that with ASCII so the T just appears after the dot.
>> Makes perfect sense to me.  I'd vote for an operator if it were possible in
>> python.  Something like A^T would be neat, maybe, or matlab's single-quote
>> operator.
>>
>>     
>
> Well, you could overload __rpow__ for a singleton T and spell it A**T
> ... (I hope no one will take that proposal seriosely).   Visually, A.T
> looks more like a subscript rather than superscript.
>   
No, no no. Overload __rxor__, then you can spell it A^t, A^h, etc. Much 
better ;-).  [Sadly, I almost like that....]

>   
>>> Adding .T to arrays will lead to less readable code because in
>>> expressions like "a * b.T" it will not be clear whether * is a matrix
>>> or elemenwise multiplication.
>>>       
>> That seems a pretty weak argument, since there are already lots of
>> expressions you can write that don't make it clear whether some operation is
>> a matrix operation or array operation.
>>     
>
> This may be a weak argument for someone used to matrix notation, but
> for me seeing a.T means: beware - tricky stuff here.
>
>   
>>  You could write a * b.transpose(1,0)
>> right now and still not know whether it was matrix or element-wise
>> multiplication.
>>     
>
> Why would anyone do that if b was a matrix?
>
>
>   
>>> 2. .H :  This is an  O(n^2) complexity operation returning a copy so
>>> it is not appropriate for an attribute.
>>>       
>> Not sure how you get O(n^2).   It just requires flipping the sign on the
>> imaginary part of each element in the array.  So in my book that's O(n).
>> But that does make it more expensive than O(1) transpose, yes.
>>
>>     
> In my book n is the size of the matrix as in "n x n matrix", but the
> argument stays with O(n) as well.
>
>
>
>   
>> But probably a better solution
>> would be to have matrix versions of these in the library as an optional
>> module to import so people could, say, import them as M and use M.ones(2,2).
>>
>>     
>
> This is the solution used by ma, which is another argument for it.
>
>
>   
>> In short, I'm most enthusiastic about the .T attribute.  Then, given a .T,
>> it makes sense to have a .H, both to be consistent with matrix, but also
>> since it seems to be a big deal in other math packages like matlab.  Then
>> given the current situation, I like the .M but I can imagine other ways to
>> make .M less necessary.
>>
>>     
>
> I only raised a mild objection against .T, but the slippery slope
> argument makes me dislike it much more.  At the very least I would
> like to see a discussion of why a.T is better than t(a) or +a.
>   
Here's a half baked thought: if the objection to t(A) is that it doesn't 
mirror the formulae where t appears as a subscript after A. Conceivably, 
__call__ could be defined so that A(x) returns x(A). That's kind of 
perverse, but it means that A(t), A(h), etc. could all work 
appropriately for suitably defined singletons. These singletons could 
either be assembeled in some abbreviations namespace or brought in by 
the programmer using "import transpose as t", etc. The latter works for 
doing t(a) as well of course.

-tim

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

[Sasha <nd...@ma...>]

On 7/6/06, Bill Baxter <wb...@gm...> wrote:
>
>
> On 7/7/06, Sasha <nd...@ma...> wrote:
> ... I think it's much
> more common to want to swap just two axes, and the last two seem a logical
> choice since a) in the default C-ordering they're the closest together in
> memory and b) they're the axes that are printed contiguously when you say
> "print A".

It all depends on how you want to interpret a rank-K tensor.  You seem
to advocate a view that it is a (K-2)-rank array of matrices and .T is
an element-wise transpose operation. Alternatively I can expect that
it is a matrix of (K-2)-rank arrays and then .T should be
swapaxes(0,1).  Do you have real-life applications of swapaxes(-2,-1)
for rank > 2?

>
> > and swapaxes(-2,-1) is
> > invalid for rank < 2.
> >
>  At least in numpy 0.9.8, it's not invalid, it just doesn't do anything.
>

That's bad.  What sense does it make to swap non-existing axes? Many
people would expect transpose of a vector to be a matrix.  This is the
case in S+ and R.

> > My main objection is that a.T is fairly cryptic
> > - is there any other language that uses attribute for transpose?
>
>
> Does it matter what other languages do?  It's not _that_ cryptic.

If something is clear and natural, chances are it was done before.
For me prior art is always a useful guide when making a design choice.
 For example, in R, the transpose operation is t(a) and works on rank
<= 2 only always returning rank-2.  K (an APL-like language) overloads
unary '+' to do swapaxes(0,1) for rank>=2 and nothing for lower rank.
Both R and K solutions are implementable in Python with R using 3
characters and K using 1(!) compared to your two-character ".T"
notation.  I would suggest that when inventing something new, you
should consider prior art and explain how you invention is better.
That's why what other languages do matter. (After all, isn't 'T'
chosen because "transpose" starts with "t" in the English language?)

>  The standard way to write transpose is with a little T superscript in the upper
> right.  We can't do that with ASCII so the T just appears after the dot.
> Makes perfect sense to me.  I'd vote for an operator if it were possible in
> python.  Something like A^T would be neat, maybe, or matlab's single-quote
> operator.
>

Well, you could overload __rpow__ for a singleton T and spell it A**T
... (I hope no one will take that proposal seriosely).   Visually, A.T
looks more like a subscript rather than superscript.

> > Adding .T to arrays will lead to less readable code because in
> > expressions like "a * b.T" it will not be clear whether * is a matrix
> > or elemenwise multiplication.
>
>
> That seems a pretty weak argument, since there are already lots of
> expressions you can write that don't make it clear whether some operation is
> a matrix operation or array operation.

This may be a weak argument for someone used to matrix notation, but
for me seeing a.T means: beware - tricky stuff here.

>  You could write a * b.transpose(1,0)
> right now and still not know whether it was matrix or element-wise
> multiplication.

Why would anyone do that if b was a matrix?


> > 2. .H :  This is an  O(n^2) complexity operation returning a copy so
> > it is not appropriate for an attribute.
>
> Not sure how you get O(n^2).   It just requires flipping the sign on the
> imaginary part of each element in the array.  So in my book that's O(n).
> But that does make it more expensive than O(1) transpose, yes.
>
In my book n is the size of the matrix as in "n x n matrix", but the
argument stays with O(n) as well.



> But probably a better solution
> would be to have matrix versions of these in the library as an optional
> module to import so people could, say, import them as M and use M.ones(2,2).
>

This is the solution used by ma, which is another argument for it.


> In short, I'm most enthusiastic about the .T attribute.  Then, given a .T,
> it makes sense to have a .H, both to be consistent with matrix, but also
> since it seems to be a big deal in other math packages like matlab.  Then
> given the current situation, I like the .M but I can imagine other ways to
> make .M less necessary.
>

I only raised a mild objection against .T, but the slippery slope
argument makes me dislike it much more.  At the very least I would
like to see a discussion of why a.T is better than t(a) or +a.

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

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

Sven Schreiber wrote:
> Tim Hochberg schrieb:
>
>   
>>>> -) .I for inverse; actually, why not add that to arrays as well as
>>>> "syntactic sugar"?
>>>>   
>>>>     
>>>>         
>>> Because it encourages people to do the wrong thing numerically speaking? 
>>> My understanding is that one almost never wants to compute the inverse 
>>> directly, at least not if you're subsequently going to multiply it with 
>>> something, instead you want to use linalg.solve or some other similar 
>>> approach.
>>>   
>>>       
>> Also, having an attribute access do an expensive operation behind the 
>> scenes seems antisocial.
>>     
>
> Ok, you (and Bill) may have a point there. (Although I'm not sure it's
> the best way to educate naive users like me about numerical efficiency
> by making inverse harder to access. Otherwise you should rename
> linalg.inv --way too easy!-- to
> linalg.okay_im_going_to_compute_the_inverse_for_you_but_its_probably_a_stupid_thing_to_do()
>  ;-)
>
> However, then why is it possible for matrices?? It's just seems
> incoherent to me.
>   
Because matrix users asked for it I imagine. Since I don't use the 
matrix, I certainly wouldn't have objected.  Also, the matrix class is 
supposed to look a lot like matlab and I assume matlab has some trivial 
way to produce an inverse -- even if it is a bad idea.

> Maybe you guys as the developers of numpy should really make up your
> mind about the future of matrices in numpy. Either it's supported, then
> eventually I would expect matrix versions of ones, zeros, eye, for
> example. (Although eye().M would come close enough I guess.) Or you
> decide that you don't really like all the problems that it implies and
> officially declare it unsupported.
> That would be valuable information for users like me who have had (and
> still sometimes have) a hard time figuring out whether I should be using
> arrays or matrices.
>   

Well, the matrix class could use a champion I think. Preferably someone 
who does a lot of matrix work and is capable of doing some development 
on it, at least on the python end. Without that I imagine it will stay 
kind of incoherent.

>
>   
>>>   
>>>       
>>>> -) * being the matrix product instead of element-wise; Now, I could live
>>>> with using dot and I don't want to push anything, but maybe this is the
>>>> right time to consider another operator symbol as a shortcut for the dot
>>>> function to be used with arrays? (Unfortunately right now I can't think
>>>> of any sensible character(s) for that...)
>>>>
>>>>         
>> 2. Backwards compatibility.
>>     
>
> I meant a *new* operator symbol.
>   
Oh. Well, we're kind of short on those at the moment. The only thing I 
know of that would work is to abuse the call operator, thus
    dot(A, B)  <=> (A)(B)
That's kind of weird though and it's never gotten much support.

>   
>> Curmudgeonly yours,
>>     
A curmudgeon is an old, cranky, stubborn fixed in his ways kind of person.

>>     
> Well I don't know what that means, so here's my hopefully equally
> incomprehensible reaction:
> Mit freundlichen Grüßen,
>   
With great (big? much?) friendship (friendliness?)?

-tim


> Sven
>
>
>   

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

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

On 7/7/06, Sasha <nd...@ma...> wrote:
>
> I would like to raise a few objections going from mild to strong:
>
> 1. .T : I am mildly against it.  As an inexpensive operation that
> returns a view (so that a.T[...] = makes sense) it is a reasonable
> candidate for an attribute.

Unfortunately reversing the order of axes at least as reasonable as
> swapaxes(-2,-1)


I suppose reversing the order changes you from C ordering to Fortran
ordering?  Other than that I can't think of any good examples of why you'd
want to completely reverse the order of all your axes.  I think it's much
more common to want to swap just two axes, and the last two seem a logical
choice since a) in the default C-ordering they're the closest together in
memory and b) they're the axes that are printed contiguously when you say
"print A".

and swapaxes(-2,-1) is
> invalid for rank < 2.
>

At least in numpy 0.9.8, it's not invalid, it just doesn't do anything.

My main objection is that a.T is fairly cryptic
> - is there any other language that uses attribute for transpose?


Does it matter what other languages do?  It's not _that_ cryptic.  The
standard way to write transpose is with a little T superscript in the upper
right.  We can't do that with ASCII so the T just appears after the dot.
Makes perfect sense to me.  I'd vote for an operator if it were possible in
python.  Something like A^T would be neat, maybe, or matlab's single-quote
operator.

Adding .T to arrays will lead to less readable code because in
> expressions like "a * b.T" it will not be clear whether * is a matrix
> or elemenwise multiplication.


That seems a pretty weak argument, since there are already lots of
expressions you can write that don't make it clear whether some operation is
a matrix operation or array operation.  You could write a * b.transpose(1,0)
right now and still not know whether it was matrix or element-wise
multiplication.  Or doing A[:,1] when you know A is 2-D -- does it give you
a 1D thing back or a 2D thing back?  That just comes down to it being
difficult to determine the class of objects in Python by looking at code.


> 2. .H :  This is an  O(n^2) complexity operation returning a copy so
> it is not appropriate for an attribute.


Not sure how you get O(n^2).   It just requires flipping the sign on the
imaginary part of each element in the array.  So in my book that's O(n).
But that does make it more expensive than O(1) transpose, yes.

It does not make much sense
> for any type other than complex, so it's use is limited.


I personally don't think I have ever used a hermitian transpose in my life.
So I can't really can't say how useful it is.  But the makers of Matlab
decided to make single quote ( e.g. A' ) be the hermitian transpose
operator, and  dot-single quote (e.g. A.') be the regular transpose.  So I'm
assuming it's common enough that the folks behind Matlab thought it wise to
make it the 'default' style of transpose and give it a one-character
operator.  That's about the only evidence I have that it's a useful
operation, though.    In general, though, I do know that when you take
good-ole algorithms for reals and extend them to complex numbers, things
that were transpose for the reals become hermitian transposes for the
complex version.

3. .M : I am strongly against this. It will create a circular
> dependency between ndarray and matrix.  I would expect that asmatrix
> is mostly used to convert function arguments and for this purpose
> @matrix_args decorator would be a better solution to reduce code
> clutter.


I'm kindof ambivalent about this one too.  Assuming matrix is going to stay
around and we actually want to encourage people to use it, I think having a
.M on arrays is an improvement over the current situation.  Arguments to
functions expecting matrices are as you say one place where conversions are
needed, but another place is on funtions like zeros and ones and empty.
With the .M you can just say ones(2,2).M.  But probably a better solution
would be to have matrix versions of these in the library as an optional
module to import so people could, say, import them as M and use M.ones(2,2).

It does seem to me that in some sense matrix is supposed to be 'just another
customized array subclass', like sparse or masked, so to have array aware of
it this one particular subclass makes me a little uneasy.  But if matrix
really should be considered to be on par with array, then it makes sense.
It's just like a mutually recursive data structure.  Or you can think of
matrix's inheritance from array being an implementation detail.


4. .A : I have no clue what this one does, so I won't comment.



It returns the array.  I think the idea was that you would always be able to
say .A with array or anything derived from it.  Currently you have to know
you have a matrix before you can use  the .A attribute.  If you were wrong
and it was actually an array, then you'll get an exception.  It would be
nicer to have X.A just return X if X is already an array.

In short, I'm most enthusiastic about the .T attribute.  Then, given a .T,
it makes sense to have a .H, both to be consistent with matrix, but also
since it seems to be a big deal in other math packages like matlab.  Then
given the current situation, I like the .M but I can imagine other ways to
make .M less necessary.

--bb

On 7/6/06, Travis Oliphant <oli...@ie...> wrote:
> > Bill Baxter wrote:
> > > So in short my proposal is to:
> > > --  make a.T a property of array that returns a.swapaxes(-2,-1),
> > > --  make a.H a property of array that returns
> > > a.conjugate().swapaxes(-2,-1)
> > > and maybe
> > > --  make a.M a property of array that returns numpy.asmatrix(a)
> >
> > I've tentatively implemented all of these suggestions as well as adding
> > the .A attribute to the ndarray as well (so that all sub-classes and
> > array scalars can get back a view as an ndarray).
> >
> > I did this to make it easier to do matrix-like calculations with or
> > with-out matrices.   Matrix-calculation flexibility is still a sore-spot
> > for many and I think these syntatical-sugar attributes will help long
> term.
> >
> > If there are no strong objections, then the recent  MATH attribute
> > checkin will stay.  If there are major objections, then we can back them
> > out without too much trouble as well.
> >
> > -Travis
>
>

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

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

On 7/6/06, Sven Schreiber <sve...@gm...> wrote:

> Maybe you guys as the developers of numpy should really make up your
> mind about the future of matrices in numpy. Either it's supported, then
> eventually I would expect matrix versions of ones, zeros, eye, for
> example. (Although eye().M would come close enough I guess.) Or you
> decide that you don't really like all the problems that it implies and
> officially declare it unsupported.
> That would be valuable information for users like me who have had (and
> still sometimes have) a hard time figuring out whether I should be using
> arrays or matrices.

If we use it (matrices) they will build it.

All of the big problems I've run into while using matrices have been
fixed within hours of posting the problem to the mailing list.

So for anyone who wants better matrix support, all you have to do is
start using matrices. The rest follows naturally: send any problems
you have to the list and answer any questions you can from new matrix
users.

Re: [Numpy-discussion] Numpy import problem

[Christopher B. <Chr...@no...>]

Satellite Data Research Group wrote:
> Hi, I have a problem when importing numpy into python 2.4.1.  I did a 
> successful (I think) build and install of Numpy 0.9.8 on a mac osx 
> (10.4) intel, 

Which Python 2.4.1 are you using? It would be great if you would give 
the Python2.4.3 version found here a try:

http://www.pythonmac.org/packages/py24-fat/index.html

We're trying to establish it as the "recommended" Python for OS-X 10.4, 
on both Intel and PPC machines.

In any case, we need to know what build of Python you're using.

-CHB



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

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

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

Tim Hochberg schrieb:

>>> -) .I for inverse; actually, why not add that to arrays as well as
>>> "syntactic sugar"?
>>>   
>>>     
>> Because it encourages people to do the wrong thing numerically speaking? 
>> My understanding is that one almost never wants to compute the inverse 
>> directly, at least not if you're subsequently going to multiply it with 
>> something, instead you want to use linalg.solve or some other similar 
>> approach.
>>   
> Also, having an attribute access do an expensive operation behind the 
> scenes seems antisocial.

Ok, you (and Bill) may have a point there. (Although I'm not sure it's
the best way to educate naive users like me about numerical efficiency
by making inverse harder to access. Otherwise you should rename
linalg.inv --way too easy!-- to
linalg.okay_im_going_to_compute_the_inverse_for_you_but_its_probably_a_stupid_thing_to_do()
 ;-)

However, then why is it possible for matrices?? It's just seems
incoherent to me.

Maybe you guys as the developers of numpy should really make up your
mind about the future of matrices in numpy. Either it's supported, then
eventually I would expect matrix versions of ones, zeros, eye, for
example. (Although eye().M would come close enough I guess.) Or you
decide that you don't really like all the problems that it implies and
officially declare it unsupported.
That would be valuable information for users like me who have had (and
still sometimes have) a hard time figuring out whether I should be using
arrays or matrices.


> 
>>   
>>> -) * being the matrix product instead of element-wise; Now, I could live
>>> with using dot and I don't want to push anything, but maybe this is the
>>> right time to consider another operator symbol as a shortcut for the dot
>>> function to be used with arrays? (Unfortunately right now I can't think
>>> of any sensible character(s) for that...)
>>> 
> 2. Backwards compatibility.

I meant a *new* operator symbol.

> Curmudgeonly yours,
> 
Well I don't know what that means, so here's my hopefully equally
incomprehensible reaction:
Mit freundlichen Grüßen,
Sven

Re: [Numpy-discussion] simple question

[Christopher B. <Chr...@no...>]

Mathew Yeates wrote:
> ohhhh. I was looking at using "where"

There's nothing wrong with where:

 >>> y = N.asmatrix(N.rand(3,3))
 >>> y
matrix([[ 0.29741635,  0.78756994,  0.641378  ],
        [ 0.0198837 ,  0.71677631,  0.76068183],
        [ 0.84904382,  0.80169706,  0.23877389]])
 >>> x = N.asmatrix(N.where(y > 0.5, 1, 0))
 >>> x
matrix([[0, 1, 1],
        [0, 1, 1],
        [1, 1, 0]])

And did you really mean matrix? or would 2-d arrays be fine?

-CHB

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

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

[Sasha <nd...@ma...>]

I would like to raise a few objections going from mild to strong:

1. .T : I am mildly against it.  As an inexpensive operation that
returns a view (so that a.T[...] = makes sense) it is a reasonable
candidate for an attribute.  Unfortunately reversing the order of axes
at least as reasonable as swapaxes(-2,-1) and swapaxes(-2,-1) is
invalid for rank < 2.  My main objection is that a.T is fairly cryptic
- is there any other language that uses attribute for transpose?
Adding .T to arrays will lead to less readable code because in
expressions like "a * b.T" it will not be clear whether * is a matrix
or elemenwise multiplication.

2. .H :  This is an  O(n^2) complexity operation returning a copy so
it is not appropriate for an attribute.  It does not make much sense
for any type other than complex, so it's use is limited.

3. .M : I am strongly against this. It will create a circular
dependency between ndarray and matrix.  I would expect that asmatrix
is mostly used to convert function arguments and for this purpose
@matrix_args decorator would be a better solution to reduce code
clutter.

4. .A : I have no clue what this one does, so I won't comment.

On 7/6/06, Travis Oliphant <oli...@ie...> wrote:
> Bill Baxter wrote:
> > So in short my proposal is to:
> > --  make a.T a property of array that returns a.swapaxes(-2,-1),
> > --  make a.H a property of array that returns
> > a.conjugate().swapaxes(-2,-1)
> > and maybe
> > --  make a.M a property of array that returns numpy.asmatrix(a)
>
> I've tentatively implemented all of these suggestions as well as adding
> the .A attribute to the ndarray as well (so that all sub-classes and
> array scalars can get back a view as an ndarray).
>
> I did this to make it easier to do matrix-like calculations with or
> with-out matrices.   Matrix-calculation flexibility is still a sore-spot
> for many and I think these syntatical-sugar attributes will help long term.
>
> If there are no strong objections, then the recent  MATH attribute
> checkin will stay.  If there are major objections, then we can back them
> out without too much trouble as well.
>
> -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

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

Bill Baxter wrote:
> On 7/6/06, *Tim Hochberg* <tim...@co... 
> <mailto:tim...@co...>> wrote:
>
>     > -) Being able to distinguish between row and column vectors; I guess
>     > this is just not possible with arrays...
>     >
>     Why can't you distinguish between them the same way that the matrix
>     class does? Shape [1, N] is a row array, shape [N,1] is column array. 
>
>
> Yep, that works.  But there are still various annoyances.  
> - You have to remeber to specify extra brackets all the time.  Like 
> array([[1,2,3]]) or array([[1],[2],[3]]). 
This one I can't get excited about. If you are actually creating that 
many constant arrays, just define rowarray and colarray functions that 
add the appropriate dimensions for you.

> - And a slice of a vector out of a matrix has to be pumped back up to 
> 2-D.   If x has ndim==2, then to get a column out of it you have to do 
> x[:,i,None] instead of just x[:,i].  To get a row you need x[j,None] 
> instead of just x[j]
Alternatively x[:,i:i+1], although that's not much better.

>
> Not horrible, but it feels a little klunky if you're used to something 
> like Matlab.
Well Matlab is geared to matrices. The ndarray object has always been 
more or less a tensor. I can't help feeling that loading it up with 
matrix like methds is just going to lead to confusion and trouble. I 
would rather work things out so that we can have a pure matrix class and 
a pure ndarray class coexist in some sensible way. Figuring out how to 
do that well would have fringe benefits for other stuff (masked arrays, 
sparse arrays, user defined arrays of various types).
> So matrix gets rid of a few annoyances like that ... and replaces them 
> with a few of its own.  :-)
In theory matrix should not be annoying to Matlab users since it's whole 
purpose is to keep matlab users happy. I think the big problem with 
matrix is that none of the developers use it as far as I know, so no one 
is motivated to clean up the rough edges.

-tim

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

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

On 7/6/06, Tim Hochberg <tim...@co...> wrote:
>
> > -) Being able to distinguish between row and column vectors; I guess
> > this is just not possible with arrays...
> >
> Why can't you distinguish between them the same way that the matrix
> class does? Shape [1, N] is a row array, shape [N,1] is column array.


Yep, that works.  But there are still various annoyances.
- You have to remeber to specify extra brackets all the time.  Like
array([[1,2,3]]) or array([[1],[2],[3]]).
- And a slice of a vector out of a matrix has to be pumped back up to 2-D.
If x has ndim==2, then to get a column out of it you have to do x[:,i,None]
instead of just x[:,i].  To get a row you need x[j,None] instead of just
x[j]

Not horrible, but it feels a little klunky if you're used to something like
Matlab.

So matrix gets rid of a few annoyances like that ... and replaces them with
a few of its own.  :-)

--bb

Re: [Numpy-discussion] Speed degression?

[Arnd B. <arn...@we...>]

On Thu, 6 Jul 2006, Travis Oliphant wrote:

> Arnd Baecker wrote:
> > Hi
> >>> i made some speed tests using the sin-function and the %-operation to compare
> >>> Numeric, numpy 0.9.8 and numpy 0.9.9.2732.
> >>> As result the latest numpy version seems to be very slow in comparison to the
> >>> two other candidates.
> >>>
>
> Arrgggh.
>
> It looks like a pre-mature return statement was causing scalarmath not
> to load and therefore none of it's speed ups are present  until this SVN.
>
> Thanks for the speed test...

Well, the thanks for this go to Steffen (who wrote the text above and the
test, not me ;-).

Concerning the speed the thanks go to you:

Results (in usec per loop):
                                     sin-array            mod-array
 Numeric                                34                  7
 numpy 0.9.9.2732                       56                 92
 numpy 0.9.9.2732 + math                42
 Numeric + math                          8

*and now*

Results (in usec per loop):
                                     sin-array            mod-array
 Numeric                                33                  7
 numpy 0.9.9.2749                       30                 17.6
 numpy 0.9.9.2749 + math                13
 Numeric + math                          8


Bingo! Only numpy 0.9.9.2749 + math  is slower than
Numeric+math by a factor 1.6 and mod-array is 2.5 times slower
than numpy.
It would be nice if you could have a look at the module operation,
if possible ...

Many thanks,

Arnd

Re: [Numpy-discussion] Speed degression?

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

Arnd Baecker wrote:
> Hi
>>> i made some speed tests using the sin-function and the %-operation to compare
>>> Numeric, numpy 0.9.8 and numpy 0.9.9.2732.
>>> As result the latest numpy version seems to be very slow in comparison to the
>>> two other candidates.
>>>       

Arrgggh.

It looks like a pre-mature return statement was causing scalarmath not 
to load and therefore none of it's speed ups are present  until this SVN.

Thanks for the speed test...

-Travis

Re: [Numpy-discussion] Speed degression?

[Arnd B. <arn...@we...>]

Hi Travis,

On Thu, 6 Jul 2006, Travis Oliphant wrote:

> Steffen Loeck wrote:
> > Hi all,
> >
> > i made some speed tests using the sin-function and the %-operation to compare
> > Numeric, numpy 0.9.8 and numpy 0.9.9.2732.
> > As result the latest numpy version seems to be very slow in comparison to the
> > two other candidates.
> >
> > Results (in usec per loop):
> >                                      sin-array            mod-array
> >
> >  Numeric                                134                   18
> >  numpy 0.9.8                             97                   55
> >  numpy 0.9.9.2732                       204                  316
> >  numpy 0.9.8 + math                      38
> >  numpy 0.9.9.2732 + math                161
> >  Numeric + math                          23
> >
> > Can anyone verify my results and explain the observed speed degression?
> >
>
> I can't verify the results, but it's possible that the indexing code for
> a single integer is a bit slower.

On the 64Bit machine I get

Results (in usec per loop):
                                     sin-array            mod-array
 Numeric                                34                  7
 numpy 0.9.9.2746                       56                 92
 numpy 0.9.9.2746 + math                42
 Numeric + math                          8

Though this does not do the comparison with 0.9.8,
it can roughly reproduce the ratios above.

In particular the mod seems not just a "bit slower", but more than
a factor 5. Also the " + math" variants for the sin
suffered by a factor of 4...

> However, you forgot to test the "use Python lists" approach which is the
> fastest of all on this code.
>
> python -m timeit -s "x = [0.1]*10;" "for i in xrange(9):
> x[i+1]=(x[i]+1.1)%(1.0)"
>
>
> Using Numeric/NumPy is always slower than lists if you are doing
> element-by-element processing.   NumPy is slower than Numeric for such
> processing.  But, Numeric was always slower than pure Python too for
> such processing.  So, the moral of the story is:
>
> "don't compute like that with NumPy (or Numeric)"
>

Well, the example is a benchmark and not the real code ...
To me it seems that it clearly points out some significant slow-down.

> With that said.   I can add back the 1-d integer check in the indexing
> code to see if that speeds things up...

That would be great - I will re-run the tests on the Opteron then.

Many thanks,

Arnd

Re: [Numpy-discussion] Dot as a method

[Bart V. <bar...@cs...>]

Tim Hochberg wrote:
> Bart Vandereycken wrote:
>> Hi all,
>>
>> reading the thread "Ransom proposals" I was wondering why there isn't a 
>> ndarray.dot() method?  There is already a scipy.sparse.dot() so this 
>> would fit nicely in the whole idea of polymorphism.
>>   
> Are you sure about that?
> 
> The problem with a dot method (aside from a over proliferation of 
> methods in general) is that to be done correctly you want to choose a 
> particular implementation of dot based *both* of its arguments. A method 
> does a good job dispatching on a single argument, but falls down when 
> dispatching on two types. Let's look at this specific case. Imagine that 
> in addition ndarray.dot and sparse.dot, we also stick a dot method on 
> ma.masked, etc. Now in order to fully exploit polymorphism and get 
> maximum efficiency, we want asparsearray.dot(amaskedarray) to correctly 
> treat the masked values (ma.dot treats them as zeros) and to not 
> instantiate a dense version of the sparsearray. But in order to do that 
> all three classes need to know about the other two. That's possible, if 
> messy since all three of these are known in advance, but this approach 
> becomes untenable if you classes outside core numpy or scipy to 
> participate as full citizens.

You're right that you need to put the class specific dot code somewhere. 
   However, it would be better if this can be done in a clean way. By 
the way I don't fixate on methods or functions, I just want something 
useful ;-)

Suppose  I have written my own matrix class (custmatrix) with it's own 
fast matrix-vector product. How can I extend numpy code so that is uses 
this fast multiplication when I want a_custmatrix*a_ndarray or 
a_ndarray*a_custmatrix?


> What does appear fit well here is generic functions / multimethods / 
> protocols as discussed in some detail on pydev-3000 a couple of months 
> ago. This would allow classes defined outside of core numpy and scipy to 
> work correctly and efficiently with dot as long as they register 
> appropriate versions of dot. If I wasn't swamped right at the moment I'd 
> prototype this up and see how it works in practice.

Right, I was thinking about multimethods too after reading 
http://www.artima.com/weblogs/viewpost.jsp?thread=101605

The other solution that simulates double dispatching is the Visitor 
pattern, but it has a lot of disadvantages (difficult to add custom 
matrices, slow?, all the matrices have to be children of an abstract class).


Bart

Re: [Numpy-discussion] Speed degression?

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

Steffen Loeck wrote:
> Hi all,
>
> i made some speed tests using the sin-function and the %-operation to compare 
> Numeric, numpy 0.9.8 and numpy 0.9.9.2732. 
> As result the latest numpy version seems to be very slow in comparison to the 
> two other candidates.
>
> Results (in usec per loop):
>                                      sin-array            mod-array  
>                                     
>  Numeric                                134                   18         
>   
>  numpy 0.9.8                             97                   55
>
>  numpy 0.9.9.2732                       204                  316
>    
>  numpy 0.9.8 + math                      38
>
>  numpy 0.9.9.2732 + math                161
>   
>  Numeric + math                          23
>
>
> The used scripts can be found at the end. 
>
> Can anyone verify my results and explain the observed speed degression?
>   

I can't verify the results, but it's possible that the indexing code for 
a single integer is a bit slower.  

However, you forgot to test the "use Python lists" approach which is the 
fastest of all on this code. 

python -m timeit -s "x = [0.1]*10;" "for i in xrange(9): 
x[i+1]=(x[i]+1.1)%(1.0)"


Using Numeric/NumPy is always slower than lists if you are doing 
element-by-element processing.   NumPy is slower than Numeric for such 
processing.  But, Numeric was always slower than pure Python too for 
such processing.  So, the moral of the story is:

"don't compute like that with NumPy (or Numeric)"

With that said.   I can add back the 1-d integer check in the indexing 
code to see if that speeds things up...

-Travis

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

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

Bill Baxter wrote:
> So in short my proposal is to:
> --  make a.T a property of array that returns a.swapaxes(-2,-1),
> --  make a.H a property of array that returns 
> a.conjugate().swapaxes(-2,-1)
> and maybe
> --  make a.M a property of array that returns numpy.asmatrix(a)

I've tentatively implemented all of these suggestions as well as adding 
the .A attribute to the ndarray as well (so that all sub-classes and 
array scalars can get back a view as an ndarray). 

I did this to make it easier to do matrix-like calculations with or 
with-out matrices.   Matrix-calculation flexibility is still a sore-spot 
for many and I think these syntatical-sugar attributes will help long term.

If there are no strong objections, then the recent  MATH attribute 
checkin will stay.  If there are major objections, then we can back them 
out without too much trouble as well.

-Travis

Re: [Numpy-discussion] Determining if two arrays share data

[Rob W.W. H. <ro...@ho...>]

Albert Strasheim wrote:
> I think we might be talking about two related but different concepts. One is
> sharing of data between arrays, the other is whether the data overlaps.

When is it useful to know whether data buffers overlap? As long as they 
are disjoint, it should be irrelevant at the higher level of the program.

> Let's assume we can get at the starting address of the array in memory via
> the array interface or whatever, and the length of the array in bytes.
> 
> To determine whether two arrays overlap, find the smallest data address of
> the two arrays. If the data address of the other array is smaller than the
> sum of the smallest data address and its corresponding length, you have
> overlap.

Don't forget the strides.

Rob

-- 
Rob W.W. Hooft  ||  ro...@ho...  ||  http://www.hooft.net/people/rob/

[Numpy-discussion] bug in svn/numpy/numpy/doc/swig/numpy.i

[Zhang L. <zha...@gm...>]

Hi,
  I found a bug in svn/numpy/numpy/doc/swig/numpy.i:
 a ')' is missed at line 72 which causes a compilation error:
if (is_array(input) && (typecode == PyArray_NOTYPE ||
    PyArray_EquivTypenums(array_type(input), typecode))) {

                              ^ missing
        ary = (PyArrayObject*) input;

Cheers,
Zhang Le

Re: [Numpy-discussion] Determining if two arrays share data

[Albert S. <fu...@gm...>]

Hello all

> <snip>
> Python 2.3b1+ (#2, Jun 10 2003, 20:53:51)
> [GCC 3.0.2 20010905 (Red Hat Linux 7.1 3.0.1-3)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import Numeric
>  >>> a=Numeric.arange(20)
>  >>> b=a[::2]
>  >>> c=a[1::2]
>  >>> a
> array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
> 16, 17, 18,
>              19])
>  >>> b
> array([ 0,  2,  4,  6,  8, 10, 12, 14, 16, 18])
>  >>> c
> array([ 1,  3,  5,  7,  9, 11, 13, 15, 17, 19])
>  >>> b[0]=99
>  >>> c[0]=99
>  >>> a
> array([99, 99,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
> 16, 17, 18,
>              19])
> 
> 
> Do "b" and "c" share a copy of the same data? None of the values in
> either array is visible in the other, but both share data with "a"!

I think we might be talking about two related but different concepts. One is
sharing of data between arrays, the other is whether the data overlaps.

Let's assume we can get at the starting address of the array in memory via
the array interface or whatever, and the length of the array in bytes.

To determine whether two arrays overlap, find the smallest data address of
the two arrays. If the data address of the other array is smaller than the
sum of the smallest data address and its corresponding length, you have
overlap.

I'm not quite sure how to check whether two arrays share the same underlying
data buffer. Flags don't tell the whole story here.

Regards,

Albert

Re: [Numpy-discussion] Determining if two arrays share data

[Rob W.W. H. <ro...@ho...>]

Stefan van der Walt wrote:
> On Thu, Jul 06, 2006 at 11:39:19AM +0900, Bill Baxter wrote:
> 
>>Often when I'm doing interactive prototyping I find myself wanting to check
>>whether two arrays are sharing a copy of the same data.
> 
> 
> Say you have
> 
> x = N.array([1,2,3,4])
> 
> and
> 
> y = x.reshape((2,2))
> 
> then x and y share the same data.  You can see this when you do
> 
> x.__array_interface__['data'][0] == y.__array_interface__['data'][0]
> 
> Still, this only holds for full data views.  If you had
> 
> z = y[1:,1:]
> 
> then the data memory position would differ.

I am still using Numeric, but even with that background I think that the 
problem is ill-defined. Consider the following interactive session:

Python 2.3b1+ (#2, Jun 10 2003, 20:53:51)
[GCC 3.0.2 20010905 (Red Hat Linux 7.1 3.0.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import Numeric
 >>> a=Numeric.arange(20)
 >>> b=a[::2]
 >>> c=a[1::2]
 >>> a
array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 
16, 17, 18,
             19])
 >>> b
array([ 0,  2,  4,  6,  8, 10, 12, 14, 16, 18])
 >>> c
array([ 1,  3,  5,  7,  9, 11, 13, 15, 17, 19])
 >>> b[0]=99
 >>> c[0]=99
 >>> a
array([99, 99,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13, 14, 15, 
16, 17, 18,
             19])


Do "b" and "c" share a copy of the same data? None of the values in 
either array is visible in the other, but both share data with "a"!

Regards,

Rob

-- 
Rob W.W. Hooft  ||  ro...@ho...  ||  http://www.hooft.net/people/rob/

Re: [Numpy-discussion] simple question

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

On 7/6/06, Bill Baxter <wb...@gm...> wrote:
> That's the kind of thing that should maybe be on the NumpyExample list:
> http://www.scipy.org/Numpy_Example_List
> But currently little syntactical tricks like that aren't listed there.   I'm
> not sure how you'd list that even.
>
There is a (tentative) introduction to 'fancy' indexing in the
tentative numpy tutorial.
http://www.scipy.org/Tentative_NumPy_Tutorial#head-0dffc419afa7d77d51062d40d2d84143db8216c2

i'm going to add the '[ ]' operator to the Numpy example list.

pau