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

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

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

Bill Baxter wrote:
> On 5/18/06, *Ed Schofield* <sch...@ft...
> <mailto:sch...@ft...>> wrote:
>
>     Bill Baxter wrote:
>     > Sure would be nice if all you had to type was a.nonzero().T,
>     though... ;-P
>
>     No, this wouldn't be possible -- the output of the nonzero method is a
>     tuple, not an array.  Perhaps this is why it's not _that_ obvious ;) 
>
>
> Oh, I see.  I did miss that bit.  I think I may have even done
> something recently myself like
>    vstack(where(a > val)).transpose()
> not realizing that plain old transpose() would work in place of
> vstack(xxx).transpose().
>
> If you feel like copy-pasting your doc addition for nonzero() over to
> where() also, that would be nice. 

Okay, done.

> What other functions work like that?   ... <me rummages around a
> little> ... actually it looks like most other functions similar to
> nonzero() return a boolean array, then you use where() if you need an
> index list.  isnan(), iscomplex(), isinf(), isreal(), isneginf(), etc
> and of course all the boolean operators like a>0.   So nonzero() is
> kind of an oddball.  Is it actually any different from where(a!=0)?

I think it's equivalent, only slightly more efficient...


-- Ed

Re: [Numpy-discussion] Indexing arrays with arrays

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

Pau Gargallo wrote:
> On 5/18/06, Bill Baxter <wb...@gm...> wrote:
>> One thing I haven't quite managed to figure out yet, is what the heck
>> indexing an array with an array is supposed to give you.
>> This is sort of an offshoot of the "nonzero()" discussion.
>> I was wondering why nonzero() and where() return tuples at all 
>> instead of
>> just an array, till I tried it.
>>
>> >>> b
>> array([[0, 1, 2],
>>        [3, 4, 5],
>>        [6, 7, 8]])
>> >>> b[ num.asarray(num.where(b>4)) ]
>> array([[[3, 4, 5],
>>         [6, 7, 8],
>>         [6, 7, 8],
>>         [6, 7, 8]],
>>
>>        [[6, 7, 8],
>>         [0, 1, 2],
>>         [3, 4, 5],
>>         [6, 7, 8]]])
>>
>> Whoa, not sure what that is.  Can someone explain the current rule 
>> and in
>> what situations is it useful?

I can't take too much credit for the indexing behavior.  I took what 
numarray had done and extended it just a little bit to allow mixing of 
slices and index arrays.   It was easily one of the most complicated 
things to write for NumPy.  

What you are observing is called "partial indexing" by Numarray.  

The indexing rules where also spelled out in emails to this list last 
year and placed in the design document for what was then called Numeric3 
(I'm not sure if that design document is still visible or not (probably 
under old.scipy.org it could be found).  The section in my book that 
covers this is based on that information. 

I can't pretend to have use cases for all the indexing fanciness because 
I was building off the work that numarray had already pioneered.


-Travis

Re: [Numpy-discussion] Numpy Example List

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

A Dijous 18 Maig 2006 14:52, jo...@st... va escriure:
> Newsflash
>
> The Numpy Example List has now passed its 100th example,
> and has now its own wikipage: http://scipy.org/Numpy_Example_List
>
> Thanks to Pau Gargallo for his contributions.

Wow, very good resource and indeed I'll check it frequently!

Thanks!

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

Re: [Numpy-discussion] Indexing arrays with arrays

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

On 5/18/06, Bill Baxter <wb...@gm...> wrote:
> One thing I haven't quite managed to figure out yet, is what the heck
> indexing an array with an array is supposed to give you.
> This is sort of an offshoot of the "nonzero()" discussion.
> I was wondering why nonzero() and where() return tuples at all instead of
> just an array, till I tried it.
>
> >>> b
> array([[0, 1, 2],
>        [3, 4, 5],
>        [6, 7, 8]])
> >>> b[ num.asarray(num.where(b>4)) ]
> array([[[3, 4, 5],
>         [6, 7, 8],
>         [6, 7, 8],
>         [6, 7, 8]],
>
>        [[6, 7, 8],
>         [0, 1, 2],
>         [3, 4, 5],
>         [6, 7, 8]]])
>
> Whoa, not sure what that is.  Can someone explain the current rule and in
> what situations is it useful?
>
> Thanks
>  --bb


i think that is b and x are arrays then,
   b[x]_ijk =3D b[ x_ijk ]
where ijk is whatever x needs to be indexed with.
Note that the indexing on b is _only_ on its first dimension.

>>> from numpy import *
>>> b =3D arange(9).reshape(3,3)
>>> b
array([[0, 1, 2],
       [3, 4, 5],
       [6, 7, 8]])
>>> x,y =3D where(b>4)
>>> xy =3D asarray( (x,y) )
>>> xy
array([[1, 2, 2, 2],
       [2, 0, 1, 2]])
>>> b[x,y]
array([5, 6, 7, 8])
>>> b[xy]
array([[[3, 4, 5],
        [6, 7, 8],
        [6, 7, 8],
        [6, 7, 8]],

       [[6, 7, 8],
        [0, 1, 2],
        [3, 4, 5],
        [6, 7, 8]]])
>>> asarray( (b[x],b[y]) )
array([[[3, 4, 5],
        [6, 7, 8],
        [6, 7, 8],
        [6, 7, 8]],

       [[6, 7, 8],
        [0, 1, 2],
        [3, 4, 5],
        [6, 7, 8]]])

Re: [Numpy-discussion] Indexing arrays with arrays

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

On Thu, 18 May 2006, Bill Baxter apparently wrote: 
> One thing I haven't quite managed to figure out yet, is 
> what the heck indexing an array with an array is supposed 
> to give you. 

I think you want section 3.3.6.1 of Travis's book,
which is easily one of the hardest sections of the book.

I find it nonobvious that when x and y are nd-arrays
that x[y] should differ from x[tuple(y)] or x[list(y)],
but as explained in this section it does in a big way.

Cheers,
Alan Isaac

[Numpy-discussion] [ANN] EuroPython 2006 - call for papers

[Nicolas C. <nic...@lo...>]

Hi Lists,

This year again EuroPython will see pythonistas from all over flock
together at the same place and the same time :

   EuroPython 2006 - July, 3rd to 5th - CERN, Geneva, Switzerland

Please do not hesitate to submit your presentation proposals to share
your insights and experience with all who have an interest in Python
put to good use in Science.

    http://www.europython.org

Deadline is May 31st.

See you there,

--=20
Nicolas Chauvat

logilab.fr - services en informatique avanc=E9e et gestion de connaissanc=
es =20

[Numpy-discussion] Indexing arrays with arrays

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

One thing I haven't quite managed to figure out yet, is what the heck
indexing an array with an array is supposed to give you.
This is sort of an offshoot of the "nonzero()" discussion.
I was wondering why nonzero() and where() return tuples at all instead of
just an array, till I tried it.

>>> b
array([[0, 1, 2],
       [3, 4, 5],
       [6, 7, 8]])
>>> b[ num.asarray(num.where(b>4)) ]
array([[[3, 4, 5],
        [6, 7, 8],
        [6, 7, 8],
        [6, 7, 8]],

       [[6, 7, 8],
        [0, 1, 2],
        [3, 4, 5],
        [6, 7, 8]]])

Whoa, not sure what that is.  Can someone explain the current rule and in
what situations is it useful?

Thanks
--bb

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

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

> Alan G Isaac wrote: 
>> 1. I hope for an array 'a' that nonzero(a) and a.nonzero() 
>>    will produce the same result, whatever convention is 
>>    chosen. 


On Wed, 17 May 2006, Travis Oliphant apparently wrote: 
> Unfortunately this won't work because the nonzero(a) behavior was 
> inherited from Numeric but the .nonzero() from numarray. 
> This is the price of trying to merge two user groups.   The little bit 
> of pain is worth it, I think. 


One last comment:
This is definitely trading off surprises for future users
against ease for incoming Numeric users.  So ...
might the best to be to make numpy consistent but,
assuming the more consistent numarray behavior is chosen,
provide the Numeric behavior as part of the compatability module?

fwiw,
Alan

[Numpy-discussion] Numpy Example List proposals

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

I want to thank Joris for this fantastic resource. Well done.
Further to Bill's suggestion, perhaps the first example(s) in each box 
could be the docstring example. For functions/methods already with 
docstrings, we could paste that into the wiki page. Those without could 
be pasted back the other way.
Maybe we could convince the developers to add an example() function to 
numpy and scipy which takes the function name as an argument and 
accesses a file containing these examples and spits it out. This way we 
could have many examples in the documentation without polluting the 
docstrings with pages of text.
The Maxima CAS package provides help, example() and apropos() functions. 
In this case example() actually executes the example input to generate 
the output which we could do with numpy/scipy as well. apropos() returns 
similar sounding functions. I contacted Fernando Perez the other day 
because I discovered a neat recipe for this functionality in the python 
cookbook here:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/409000
so we could do this in numpy/scipy too.

Gary R.

jo...@st... wrote:
> Newsflash
> 
> The Numpy Example List has now passed its 100th example,
> and has now its own wikipage: http://scipy.org/Numpy_Example_List
> 
> Thanks to Pau Gargallo for his contributions.
> 
> Joris

[Numpy-discussion] Numpy Example List

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

Newsflash

The Numpy Example List has now passed its 100th example,
and has now its own wikipage: http://scipy.org/Numpy_Example_List

Thanks to Pau Gargallo for his contributions.

Joris



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

Re: [Numpy-discussion] Re: Dot product threading?

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

In Einstein summation notation, what numpy.dot() does now is:
c_riqk =3D a_rij * b_qjk

And you want:
c_[r]ik =3D a_[r]ij * b_[r]jk

where the brackets indicate a 'no summation' index.
Writing the ESN makes it clearer to me anyway.  :-)

--bb



On 5/18/06, Pau Gargallo <pau...@gm...> wrote:
>
> > I'm afraid I really don't understand the operation that you want.
>
> I think that the operation Angus wants is the following (at least I
> would like that one ;-)
>
> if you have two 2darrays of shapes:
>     a.shape =3D (n,k)
>     b.shape =3D (k,m)
> you get:
>     dot( a,b ).shape =3D=3D (n,m)
>
> Now, if you have higher dimensional arrays  (kind of "arrays of matrices"=
)
>     a.shape =3D I+(n,k)
>     b.shape =3D J+(k,m)
> where I and J are tuples, you get
>     dot( a,b ).shape =3D=3D I+J+(n,m)
>     dot( a,b )[ i,j ] =3D=3D dot( a[i],b[j] )          #i,j represent tup=
les
> That is the current behaviour, it computes the matrix product between
> every possible pair.
> For me that is similar to 'outer' but with matrix product.
>
> But sometimes it would be useful (at least for me) to have:
>      a.shape =3D I+(n,k)
>      b.shape =3D I+(k,m)
> and to get only:
>      dot2( a,b ).shape =3D=3D I+(n,m)
>      dot2( a,b )[i] =3D=3D dot2( a[i], b[i] )
>
> This would be a natural extension of the scalar product (a*b)[i] =3D=3D
> a[i]*b[i]
> If dot2 was a kind of ufunc, this will be the expected behaviour,
> while the current dot's behaviour will be obtained by dot2.outer(a,b).
>
> Does this make any sense?
>
> Cheers,
> pau
>
>

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

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

This is a very useful thread. Made me think about what the present
arrangement is supposed to do.

My usage of this is to get out indices corresponding to a given condition.

So
E.g.
In [38]: a = arange(12).reshape(3,2,2)
Out[39]:
array([[[ 0,  1],
        [ 2,  3]],

       [[ 4,  5],
        [ 6,  7]],

       [[ 8,  9],
        [10, 11]]])
In [40]: xx = where(a%2==0)

In [41]: xx
Out[41]:
(array([0, 0, 1, 1, 2, 2]),
 array([0, 1, 0, 1, 0, 1]),
 array([0, 0, 0, 0, 0, 0]))

The transpose idea should have been obvious to me...

In [48]: for i,j,k in transpose(xx):
   ....:     print i,j,k
   ....:
   ....:
0 0 0
0 1 0
1 0 0
1 1 0
2 0 0
2 1 0

A 1D array
In [57]: aa = a.ravel()
In [49]: xx = where(aa%2==0)
In [53]: xx
Out[53]: (array([ 0,  2,  4,  6,  8, 10]),)

needs tuple unpacking:
n [52]: for i, in transpose(xx):
   ....:     print i
   ....:
   ....:
0
2
4
6
8
10

Or more simply, the ugly
In [58]: for i in xx[0]:
   ....:     print i
   ....:
   ....:
0
2
4
6
8
10

Alternatively, instead of transpose, we can simply use zip.

E.g. (3D)
In [42]: for i,j,k in zip(*xx):
   ....:     print i,j,k

or (1D, again still needs unpacking)
In [56]: for i, in zip(*xx):
   ....:     print i

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

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

On 5/18/06, Ed Schofield <sch...@ft...> wrote:
>
> Bill Baxter wrote:
> > Sure would be nice if all you had to type was a.nonzero().T, though...
> ;-P
>
> No, this wouldn't be possible -- the output of the nonzero method is a
> tuple, not an array.  Perhaps this is why it's not _that_ obvious ;)


Oh, I see.  I did miss that bit.  I think I may have even done something
recently myself like
   vstack(where(a > val)).transpose()
not realizing that plain old transpose() would work in place of
vstack(xxx).transpose().

If you feel like copy-pasting your doc addition for nonzero() over to
where() also, that would be nice.

What other functions work like that?   ... <me rummages around a little> ..=
.
actually it looks like most other functions similar to nonzero() return a
boolean array, then you use where() if you need an index list.  isnan(),
iscomplex(), isinf(), isreal(), isneginf(), etc and of course all the
boolean operators like a>0.   So nonzero() is kind of an oddball.  Is it
actually any different from where(a!=3D0)?

--bill

Re: [Numpy-discussion] Dot product threading?

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

> Pau, can you confirm that this is the same
> as the routine you're interested in?
>
> def dot2(a,b):
>     '''Returns dot product of last two dimensions of two 3-D arrays,
>     threaded over first dimension.'''
>     try:
>         assert a.shape[1] =3D=3D b.shape[2]
>         assert a.shape[0] =3D=3D b.shape[0]
>     except AssertionError:
>         print "incorrect input shapes"
>     res =3D zeros( (a.shape[0], a.shape[1], a.shape[1]), dtype=3Dfloat )
>     for i in range(a.shape[0]):
>         res[i,...] =3D dot( a[i,...], b[i,...] )
>     return res
>

yes, that is what I would like. I would like it even with more
dimensions and with all the broadcasting rules ;-)
These can probably be achieved by building actual 'arrays of matrices'
(an array of matrix objects) and then using the ufunc machinery.
But I think that a simple dot2 function (with an other name of course)
will still very useful.

pau

Re: [Numpy-discussion] NumPy 0.9.8 to be released today

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

Does scipy 0.4.8 work on top of that?

Martin


On Thursday 18 May 2006 00:20, Travis Oliphant wrote:
> If there are now further difficulties, I'm going to release 0.9.8
> today.   Then work on 1.0 can begin.  The 1.0 release will consist of a
> series of release candidates.
>
> Thank you to David Cooke for his recent flurry of fixes..  Thanks to all
> the other developers who have contributed 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] Dot product threading?

[Angus M. <am...@gm...>]

Pau Gargallo wrote:
> I think that the operation Angus wants is the following (at least I
> would like that one ;-)
> 
[snip]
> 
> But sometimes it would be useful (at least for me) to have:
>     a.shape = I+(n,k)
>     b.shape = I+(k,m)
> and to get only:
>     dot2( a,b ).shape == I+(n,m)
>     dot2( a,b )[i] == dot2( a[i], b[i] )
> 
> This would be a natural extension of the scalar product (a*b)[i] ==
> a[i]*b[i]
> If dot2 was a kind of ufunc, this will be the expected behaviour,
> while the current dot's behaviour will be obtained by dot2.outer(a,b).
> 
> Does this make any sense?

Thank-you Pau, this looks exactly like what I want. For further
explanation, here, I believe, is an implementation of the desired
routine using a loop. It would, however, be great to do this using
quicker (ufunc?) machinery. Pau, can you confirm that this is the same
as the routine you're interested in?

def dot2(a,b):
    '''Returns dot product of last two dimensions of two 3-D arrays,
    threaded over first dimension.'''
    try:
        assert a.shape[1] == b.shape[2]
        assert a.shape[0] == b.shape[0]
    except AssertionError:
        print "incorrect input shapes"
    res = zeros( (a.shape[0], a.shape[1], a.shape[1]), dtype=float )
    for i in range(a.shape[0]):
        res[i,...] = dot( a[i,...], b[i,...] )
    return res

I think the 'arrays of 2-D matrices' comment (which I've snipped out, oh
well) captures the idea well.

Angus.
-- 
Angus McMorland
email a.m...@au...
mobile +64-21-155-4906

PhD Student, Neurophysiology / Multiphoton & Confocal Imaging
Physiology, University of Auckland
phone +64-9-3737-599 x89707

Armourer, Auckland University Fencing
Secretary, Fencing North Inc.

-- 
Angus McMorland
email a.m...@au...
mobile +64-21-155-4906

PhD Student, Neurophysiology / Multiphoton & Confocal Imaging
Physiology, University of Auckland
phone +64-9-3737-599 x89707

Armourer, Auckland University Fencing
Secretary, Fencing North Inc.

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

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

Bill Baxter wrote:
> Aren't there quite a few functions that return indices like nonzero()
> does?
> Should they all have arg*** versions that just transpose the output of
> the non arg*** version?
>
> Maybe the answer is yes, but to me if all it takes to get what you
> needs is transpose() then I'm not sure how that fails to be obvious. 
> You have [[x y z] [p d q]] and you want ([x p][y d][z q]).  Looks like
> a job for transpose! 
> Maybe a note in the docstring pointing out "the obvious" is what is
> really warranted.  As in "hey, look, you can transpose the output of
> this function if you'd like the indices the other way, but the way it
> is it's more useful for indexing, as in a[ a.nonzero()]."

Well, it wasn't immediately obvious to me how it could be done so
elegantly.  But I agree that a new function isn't necessary.  I've
re-written the docstring for the nonzero method in SVN to point out how
to do it.

> Sure would be nice if all you had to type was a.nonzero().T, though... ;-P

No, this wouldn't be possible -- the output of the nonzero method is a
tuple, not an array.  Perhaps this is why it's not _that_ obvious ;)

-- Ed

Re: [Numpy-discussion] Re: Dot product threading?

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

> I'm afraid I really don't understand the operation that you want.

I think that the operation Angus wants is the following (at least I
would like that one ;-)

if you have two 2darrays of shapes:
    a.shape =3D (n,k)
    b.shape =3D (k,m)
you get:
    dot( a,b ).shape =3D=3D (n,m)

Now, if you have higher dimensional arrays  (kind of "arrays of matrices")
    a.shape =3D I+(n,k)
    b.shape =3D J+(k,m)
where I and J are tuples, you get
    dot( a,b ).shape =3D=3D I+J+(n,m)
    dot( a,b )[ i,j ] =3D=3D dot( a[i],b[j] )          #i,j represent tuple=
s
That is the current behaviour, it computes the matrix product between
every possible pair.
For me that is similar to 'outer' but with matrix product.

But sometimes it would be useful (at least for me) to have:
     a.shape =3D I+(n,k)
     b.shape =3D I+(k,m)
and to get only:
     dot2( a,b ).shape =3D=3D I+(n,m)
     dot2( a,b )[i] =3D=3D dot2( a[i], b[i] )

This would be a natural extension of the scalar product (a*b)[i] =3D=3D a[i=
]*b[i]
If dot2 was a kind of ufunc, this will be the expected behaviour,
while the current dot's behaviour will be obtained by dot2.outer(a,b).

Does this make any sense?

Cheers,
pau

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

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

Aren't there quite a few functions that return indices like nonzero() does?
Should they all have arg*** versions that just transpose the output of the
non arg*** version?

Maybe the answer is yes, but to me if all it takes to get what you needs is
transpose() then I'm not sure how that fails to be obvious.  You have [[x y
z] [p d q]] and you want ([x p][y d][z q]).  Looks like a job for
transpose!

Maybe a note in the docstring pointing out "the obvious" is what is really
warranted.  As in "hey, look, you can transpose the output of this function
if you'd like the indices the other way, but the way it is it's more useful
for indexing, as in a[a.nonzero()]."

Sure would be nice if all you had to type was a.nonzero().T, though... ;-P

--bill

On 5/18/06, Ed Schofield <sch...@ft...> wrote:
>
> Alan G Isaac wrote:
> > On Tue, 16 May 2006, Alan G Isaac apparently wrote:
> >
> >> 2. How are people using this?  I trust that the numarray
> >> behavior was well considered, but I would have expected
> >> coordinates to be grouped rather than spread across the
> >> arrays in the tuple.
> >>
> >
> > OK, just to satisfy my curiosity:
> > does the silence mean that nobody is using
> > 'nonzero' in a fashion that leads them to
> > prefer the current behavior to the "obvious"
> > alternative of grouping the coordinates?
> > Is the current behavior just an inherited
> > convention, or is it useful in specific applications?
> >
>
> I also think a function that groups coordinates would be useful.  Here's
> a prototype:
>
> def argnonzero(a):
>     return transpose(a.nonzero())
>
> This has the same effect as:
>
> def argnonzero(a):
>     nz =3D a.nonzero()
>     return array([[nz[i][j] for i in xrange(a.ndim)] for j in
> xrange(len(nz[0]))])
>
> The output is always a 2d array, so
>
> >>> a
> array([[ 0,  1,  2,  3],
>        [ 4,  0,  6,  7],
>        [ 8,  9,  0, 11]])
>
> >>> argnonzero(a)
> array([[0, 1],
>        [0, 2],
>        [0, 3],
>        [1, 0],
>        [1, 2],
>        [1, 3],
>        [2, 0],
>        [2, 1],
>        [2, 3]])
>
> >>> b =3D a[0]
> >>> argnonzero(b)
> array([[1],
>        [2],
>        [3]])
>
> >>> c =3D array([a, a-1, a-2])
> >>> argnonzero(c)
> array([[0, 0, 1],
>        [0, 0, 2],
>        ...
>
> It looks a little clumsy for 1d arrays, but I'd argue that, if NumPy
> were to offer a function like this, it should always return a 2d array
> whose rows are the coordinates for consistency, rather than returning
> some squeezed version for indices into 1d arrays.
>
> I'd support the addition of such a function to NumPy.  Although it's
> tiny, it's not obvious, and it might be useful.
>
> -- Ed
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>



--=20
William V. Baxter III
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan  154-0023
+81 (3) 3422-3380

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

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

Alan G Isaac wrote:
> On Tue, 16 May 2006, Alan G Isaac apparently wrote: 
>   
>> 2. How are people using this?  I trust that the numarray 
>> behavior was well considered, but I would have expected 
>> coordinates to be grouped rather than spread across the 
>> arrays in the tuple. 
>>     
>
> OK, just to satisfy my curiosity:
> does the silence mean that nobody is using
> 'nonzero' in a fashion that leads them to
> prefer the current behavior to the "obvious"
> alternative of grouping the coordinates?
> Is the current behavior just an inherited
> convention, or is it useful in specific applications?
>   

I also think a function that groups coordinates would be useful.  Here's
a prototype:

def argnonzero(a):
    return transpose(a.nonzero())

This has the same effect as:

def argnonzero(a):
    nz = a.nonzero()
    return array([[nz[i][j] for i in xrange(a.ndim)] for j in
xrange(len(nz[0]))])

The output is always a 2d array, so

>>> a
array([[ 0,  1,  2,  3],
       [ 4,  0,  6,  7],
       [ 8,  9,  0, 11]])

>>> argnonzero(a)
array([[0, 1],
       [0, 2],
       [0, 3],
       [1, 0],
       [1, 2],
       [1, 3],
       [2, 0],
       [2, 1],
       [2, 3]])

>>> b = a[0]
>>> argnonzero(b)
array([[1],
       [2],
       [3]])

>>> c = array([a, a-1, a-2])
>>> argnonzero(c)
array([[0, 0, 1],
       [0, 0, 2],
       ...

It looks a little clumsy for 1d arrays, but I'd argue that, if NumPy
were to offer a function like this, it should always return a 2d array
whose rows are the coordinates for consistency, rather than returning
some squeezed version for indices into 1d arrays.

I'd support the addition of such a function to NumPy.  Although it's
tiny, it's not obvious, and it might be useful.

-- Ed

[Numpy-discussion] Re: Dot product threading?

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

Angus McMorland wrote:
> Robert Kern wrote:
> 
>>Angus McMorland wrote:
>>
>>>Is there a way to specify which dimensions I want dot to work over?
>>
>>Use swapaxes() on the arrays to put the desired axes in the right places.
> 
> Thanks for your reply, Robert. I've explored a bit further, and have
> made sense of what's going on, to some extent, but have further questions.
> 
> My interpretation of the dot docstring, is that the shapes I need are:
>     a.shape == (2,3,1) and b.shape == (2,1,3)
> so that the sum is over the 1s, giving result.shape == (2,3,3)

I'm not sure why you think you should get that resulting shape. Yes, it will
"sum" over the 1s (in this case there is only one element in those axes so there
is nothing really to sum). What exactly are the semantics of the operation that
you want? I can't tell from just the input and output shapes.

> but:
>     In [85]:ma = array([[[4],[5],[6]],[[7],[8],[9]]]) #shape = (2, 3, 1)
>     In [86]:mb = array([[[4,5,6]],[[7,8,9]]])         #shape = (2, 1, 3)
> so
>     In [87]:res = dot(ma,mb).shape
>     In [88]:res.shape
>     Out[88]:(2, 3, 2, 3)
> such that
>     res[i,:,j,:] == dot(ma[i,:,:], mb[j,:,:])
> which means that I can take the results I want out of res by slicing
> (somehow) res[0,:,0,:] and res[1,:,1,:] out.
> 
> Is there an easier way, which would make dot only calculate the dot
> products for the cases where i==j (which is what I call threading over
> the first dimension)?

I'm afraid I really don't understand the operation that you want.

> Since the docstring makes no mention of what happens over other
> dimensions, should that be added, or is this the conventional numpy
> behaviour that I need to get used to?

It's fairly conventional for operations that reduce values along an axis to a
single value. The remaining axes are left untouched. E.g.

In [1]: from numpy import *

In [2]: a = random.randint(0, 10, size=(3,4,5))

In [3]: s1 = sum(a, axis=1)

In [4]: a.shape
Out[4]: (3, 4, 5)

In [5]: s1.shape
Out[5]: (3, 5)

In [6]: for i in range(3):
   ...:     for j in range(5):
   ...:         print i, j, (sum(a[i,:,j]) == s1[i,j]).all()
   ...:
   ...:
0 0 True
0 1 True
0 2 True
0 3 True
0 4 True
1 0 True
1 1 True
1 2 True
1 3 True
1 4 True
2 0 True
2 1 True
2 2 True
2 3 True
2 4 True

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

[Numpy-discussion] Re: your good crdit

[Chibuzo T. <tw...@ic...>]

D p ea l r H r om p e O u wn m er,

Your c d re d di e t doesn' f t m r atter to us!

If you O w WN s r j ea q l e h st v at f e and wa i nt
I s MME x DI g ATE c a as z h to s q pe f nd ANY wa f y you lik v e,
or simp d ly wis t h to L e OW s ER your mo q nthly p d aym i ent h s
by a thir e d or m m ore,
h v ere a e re the d n ea q ls o we hav r e T q ODA x Y:

$4 w 90 , 00 x 0 a b s l o ow a j s 3 , 6 b 4 %
$ b 370 , 0 z 00 a d s l g ow a g s 3 , 8 u 9 %
$ l 490 , 0 g 00 a p s lo p w a p s 3 , 1 k 9 %
$2 t 50 , 00 k 0 a u s lo i w a l s 3 , 3 o 4 %
$2 s 00 , 00 c 0 a p s lo z w a k s 3 , 5 v 4 %

Your c e re f di h t does v n't mat k ter to u u s!

g x et ma t tc y hed with l v en g der m s
<http://geocities.com/ZaynaxaronLadd/>=20

Chibuzo Twist , Ap h pr d ov k al M d ana r ge x r
=20

	----- Original Message -----=20
	believe, after a long start. And so do burglars, he added as a
parting
	shot, as he darted back and fled up the tunnel.
	It was an unfortunate remark, for the dragon spouted terrific
flames
	after him, and fast though he sped up the slope, he had not gone
nearly
=09

Re: [Numpy-discussion] Dot product threading?

[Angus M. <a.m...@au...>]

Robert Kern wrote:
> Angus McMorland wrote:
>
>>Is there a way to specify which dimensions I want dot to work over?
>
> Use swapaxes() on the arrays to put the desired axes in the right places.

Thanks for your reply, Robert. I've explored a bit further, and have
made sense of what's going on, to some extent, but have further questions.

My interpretation of the dot docstring, is that the shapes I need are:
    a.shape == (2,3,1) and b.shape == (2,1,3)
so that the sum is over the 1s, giving result.shape == (2,3,3)
but:
    In [85]:ma = array([[[4],[5],[6]],[[7],[8],[9]]]) #shape = (2, 3, 1)
    In [86]:mb = array([[[4,5,6]],[[7,8,9]]])         #shape = (2, 1, 3)
so
    In [87]:res = dot(ma,mb).shape
    In [88]:res.shape
    Out[88]:(2, 3, 2, 3)
such that
    res[i,:,j,:] == dot(ma[i,:,:], mb[j,:,:])
which means that I can take the results I want out of res by slicing
(somehow) res[0,:,0,:] and res[1,:,1,:] out.

Is there an easier way, which would make dot only calculate the dot
products for the cases where i==j (which is what I call threading over
the first dimension)?

Since the docstring makes no mention of what happens over other
dimensions, should that be added, or is this the conventional numpy
behaviour that I need to get used to?

Cheers,

Angus
-- 
Angus McMorland
email a.m...@au...
mobile +64-21-155-4906

PhD Student, Neurophysiology / Multiphoton & Confocal Imaging
Physiology, University of Auckland
phone +64-9-3737-599 x89707

Armourer, Auckland University Fencing
Secretary, Fencing North Inc.

[Numpy-discussion] NumPy 0.9.8 to be released today

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

If there are now further difficulties, I'm going to release 0.9.8 
today.   Then work on 1.0 can begin.  The 1.0 release will consist of a 
series of release candidates. 

Thank you to David Cooke for his recent flurry of fixes..  Thanks to all 
the other developers who have contributed as well.

-Travis

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

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

Simon Burton wrote:
> On Tue, 16 May 2006 15:15:23 -0400
> Alan G Isaac <ai...@am...> wrote:
>
>   
>> 2. How are people using this?  I trust that the numarray
>>    behavior was well considered, but I would have expected
>>    coordinates to be grouped rather than spread across
>>    the arrays in the tuple.
>>     
>
>   
The split-tuple is for fancy-indexing.  That's how you index a 
multidimensional array using an array of integers.  The output of 
a.nonzero() is setup to do that so that

a[a.nonzero()]

works.

> Yes, this strikes me as bizarre.
> How about we make a new function, eg. argwhere, that
> returns an array of indices ?
>   
> argwhere( array( [[0,1],[0,1]] ) ) -> [[0,1],[1,1]]
>
>   
I could see the value of this kind of function too.

-Travis