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

Re: [Numpy-discussion] Array Protocol change for Python 2.6

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

Sasha wrote:

>On 6/8/06, Travis Oliphant <oli...@ee...> wrote:
>  
>
>>...
>>__array_struct__   (perhaps we could call this __array_interface__ but
>>I'm happy keeping the name the same too.)
>>    
>>
>
>+0 on the name change and consider making it a method rather than an attribute.
>  
>
I'm not thrilled with either name, nor do I have a better one, so put me 
down as undecided on name.

I marginally prefer an attribute to a name here.

I'm +1 on narrowing the interface though.

>>If __array_struct__ is a CObject then it behaves as it does now.
>>
>>If __array_struct__ is a tuple then each entry in the tuple is one of
>>the items currently obtained by an additional attribute access (except
>>the first item is always an integer indicating the version of the
>>protocol --- unused entries are None).
>>
>>    
>>
>
>-1
>
>This will complicate the use of array interface.  
>
I concur.

>I would propose
>creating a subtype of CObject that has the necessary attributes so
>that one can do a.__array_interface__.shape, for example.  I did not
>check if CObject is subclassable in 2.5, but if not, we can propose to
>make it subclassable for 2.6.
>  
>
Alternatively, if this proves to be a hassle, a function, 
unpack_interface or some such, could be provided that takes an 
__array_interface__ object and spits out the appropriate tuple or, 
perhaps better, and object with the appropriate field.

>  
>
>>...
>>
>>I would like to eliminate all the other array protocol attributes before
>>NumPy 1.0 (and re-label those such as __array_data__ that are useful in
>>other contexts --- like ctypes).
>>    
>>
>+1
>  
>
+1.


-tim

[Numpy-discussion] Intel OSX test failure

[Gennan C. <gn...@co...>]

Hi!

I just got an MacBook Pro and tried to install numpy+scipy on that.   
I successfully installed ipython+matplotlib+python 2.4 through  
darwinports.
Then I svn co a copy of numpy +scipy. Compilation (gcc 4.0.1 +  
gfortran) seems working fine for numpy. After I installed it and run  
numpy.test() in ipython, it failed. And the error is:

In [4]: numpy.test()
   Found 3 tests for numpy.lib.getlimits
   Found 30 tests for numpy.core.numerictypes
   Found 13 tests for numpy.core.umath
   Found 3 tests for numpy.core.scalarmath
   Found 8 tests for numpy.lib.arraysetops
   Found 42 tests for numpy.lib.type_check
   Found 95 tests for numpy.core.multiarray
   Found 3 tests for numpy.dft.helper
   Found 36 tests for numpy.core.ma
   Found 2 tests for numpy.core.oldnumeric
   Found 9 tests for numpy.lib.twodim_base
   Found 9 tests for numpy.core.defmatrix
   Found 1 tests for numpy.lib.ufunclike
   Found 35 tests for numpy.lib.function_base
   Found 1 tests for numpy.lib.polynomial
   Found 6 tests for numpy.core.records
   Found 19 tests for numpy.core.numeric
   Found 5 tests for numpy.distutils.misc_util
   Found 4 tests for numpy.lib.index_tricks
   Found 46 tests for numpy.lib.shape_base
   Found 0 tests for __main__
..............................................F......................... 
........................................................................ 
........................................................................ 
........................................................................ 
........................................................................ 
..........
======================================================================
FAIL: check_large_types (numpy.core.tests.test_scalarmath.test_power)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "/opt/local/lib/python2.4/site-packages/numpy/core/tests/ 
test_scalarmath.py", line 42, in check_large_types
     assert b == 6765201, "error with %r: got %r" % (t,b)
AssertionError: error with <type 'float128scalar'>: got 0.0

----------------------------------------------------------------------
Ran 370 tests in 0.510s

FAILED (failures=1)
Out[4]: <unittest.TextTestRunner object at 0x1581fd0>


Anyone has any idea?? or Anyone ever successfully did that?


Gen-Nan Chen, PhD
Chief Scientist
Research and Development Group
CorTechs Labs Inc (www.cortechs.net)
1020 Prospect St., #304, La Jolla, CA, 92037
Tel: 1-858-459-9700 ext 16
Fax: 1-858-459-9705
Email: gn...@co...

Re: [Numpy-discussion] Array Protocol change for Python 2.6

[David M. C. <co...@ph...>]

On Thu, 8 Jun 2006 17:07:55 -0400
Sasha <nd...@ma...> wrote:

> On 6/8/06, Travis Oliphant <oli...@ee...> wrote:
> > ...
> > __array_struct__   (perhaps we could call this __array_interface__ but
> > I'm happy keeping the name the same too.)
> 
> +0 on the name change and consider making it a method rather than an
> attribute.

+0 for name change; I'm happy with it as an attribute.

> > If __array_struct__ is a CObject then it behaves as it does now.
> >
> > If __array_struct__ is a tuple then each entry in the tuple is one of
> > the items currently obtained by an additional attribute access (except
> > the first item is always an integer indicating the version of the
> > protocol --- unused entries are None).
> >
> 
> -1
> 
> This will complicate the use of array interface.  I would propose
> creating a subtype of CObject that has the necessary attributes so
> that one can do a.__array_interface__.shape, for example.  I did not
> check if CObject is subclassable in 2.5, but if not, we can propose to
> make it subclassable for 2.6.

The idea behind the array interface was to have 0 external dependencies: any
array-like object from any package could add the interface, without requiring
a 3rd-party module. That's why the C version uses a CObject. Subclasses of
CObject start getting into 3rd-party requirements.

How about a dict instead of a tuple? With keys matching the attributes it's
replacing: "shapes", "typestr", "descr", "data", "strides", "mask", and
"offset". The problem with a tuple from my point of view is I can never
remember which order things go (this is why in the standard library the
result of os.stat() and time.localtime() are now "tuple-like" classes with
attributes).

We still need __array_descr__, as the C struct doesn't provide all the info
that this does.

> > I would like to eliminate all the other array protocol attributes before
> > NumPy 1.0 (and re-label those such as __array_data__ that are useful in
> > other contexts --- like ctypes).
> +1

+1 also

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

Re: [Numpy-discussion] Array Protocol change for Python 2.6

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

On 6/8/06, Travis Oliphant <oli...@ee...> wrote:
> ...
> __array_struct__   (perhaps we could call this __array_interface__ but
> I'm happy keeping the name the same too.)

+0 on the name change and consider making it a method rather than an attribute.

>
> If __array_struct__ is a CObject then it behaves as it does now.
>
> If __array_struct__ is a tuple then each entry in the tuple is one of
> the items currently obtained by an additional attribute access (except
> the first item is always an integer indicating the version of the
> protocol --- unused entries are None).
>

-1

This will complicate the use of array interface.  I would propose
creating a subtype of CObject that has the necessary attributes so
that one can do a.__array_interface__.shape, for example.  I did not
check if CObject is subclassable in 2.5, but if not, we can propose to
make it subclassable for 2.6.

> ...
>
> I would like to eliminate all the other array protocol attributes before
> NumPy 1.0 (and re-label those such as __array_data__ that are useful in
> other contexts --- like ctypes).
+1

Re: [Numpy-discussion] .debs of numpy-0.9.8 available for Ubuntu Dapper

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

On 08/06/2006, at 10:54 AM, Andrew Straw wrote:

> I've put together some .debs for numpy-0.9.8. There are binaries
> compiled for amd64 and i386 architectures of Ubuntu Dapper, and I
> suspect these will build from source for just about any Debian-based
> distro and architecture.
> ...

Great!

I posted an offer earlier this week to debian-science to help work on  
numpy packages (but got no response).  NumPy might be adopted much  
more rapidly once it has official packages in Debian and Ubuntu.  I'm  
glad you're in control of the situation; now I can now quietly  
withdraw my offer ;)

No, seriously ... I'd be happy to help out if I can :)

-- Ed

Re: [Numpy-discussion] .debs of numpy-0.9.8 available for Ubuntu Dapper

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

On Thu, 8 Jun 2006, Andrew Straw wrote:

> Arnd Baecker wrote:
> > What worries me is
> > a) the Build conflicts: atlas3-base
> >
> I hoped to investigate further and post afterwards, but my preliminary
> findings that led to this decision are:
>
> 1) building with atlas (atlas3-base and atlas3-base-dev) caused a
> significant slowdown (~10x) on my simple test on amd64 arch:
>
> import timeit
> shape = '(40,40)'
> timeit.Timer('a=ones(shape=%s);svd(a)'%shape,'from numpy import ones;
> from numpy.linalg import svd')
> print "NumPy: ", t2.repeat(5,500)
>
> 2) Even having atlas installed (atlas3-base on amd64) caused a
> significant slowdown (~2x) on that test. This was similar to the case
> for i386, where I installed atlas3-sse2.
> 3) This is done in the source packages by Matthias Klose for both
> numeric and numarray, too. I figured he knows what he's doing.

Alright, this ATLAS stuff always puzzled me and I thought that one
has to have atlas3-base and atlas3-base-dev atlas3-headers
installed to use atlas3 during compilation.
I assumed that installing additionally (even afterwards)
atlas3-sse2 should give
optimal performance on the corresponding machine.
(Thinking about this, it is not clear why then atlas3-sse2-dev,
so the previous statement must be wrong ...)

OTOH, `apt-cache rdepends atlas3-base` shows a pretty long list,
including python2.3-scipy, python2.3-numeric-ext, python2.3-numarray-ext

OK, obviously I haven't understood the ATLAS setup of debian
and better shut up now and leave this for the experts .... ;-)

Tomorrow I will remove the atlas3-base stuff before building and
see how things work
(I don't need that urgently as building from source seems
easier, but the benefit of having proper debian packages
pays off very quickly in the longer run ...)

> > b) and the python2.3-dev *and* python2.4-dev dependency
> >
> This is a _build_ dependency. The source package builds python
> python2.3-numpy and python2.4-numpy, so it needs Python.h for both.

Alright, so no problem here - thanks for the clarification.

[...]

> > What about scipy: presently debian sarge comes with
> > scipy 0.3.2. Installing old-scipy and new-scipy side-by side
> > seems impossible (unless one does something like wxversion select
> > stuff...) - should the new scipy debs just replace the old ones?
> >
> Unless you do some apt-pinning, I think any new scipy (0.4.x) in any
> repository in your sources list will automatically override the old
> (0.3.x) simply via the versioning mechanisms of apt-get. I like the idea
> of a wxversion-alike, but I've shifted all my code to use numpy and the
> new scipy, so I don't have any motivation to do any implementation.

Also, it might not be completely trivial to set up and
there is still a lot of other stuff which has to be done ...

Best, Arnd

[Numpy-discussion] Array Protocol change for Python 2.6

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

One of the hopes for the Summer of Code project involving getting the 
multidimensional array object into Python 2.6 is advertisement of the 
array protocol or array interface.

I think one way to simplify the array protocol is simply have only one 
attribute that is looked to to provide access to the protocol.   I would 
like to deprecate all the array protocol attributes except for

__array_struct__   (perhaps we could call this __array_interface__ but 
I'm happy keeping the name the same too.)

If __array_struct__ is a CObject then it behaves as it does now.

If __array_struct__ is a tuple then each entry in the tuple is one of 
the items currently obtained by an additional attribute access (except 
the first item is always an integer indicating the version of the 
protocol --- unused entries are None).

This should simplify the array interface and allow easier future 
changes.  It should also simplify NumPy so that it doesn't have to check 
for multiple attributes on arbitrary objects.

I would like to eliminate all the other array protocol attributes before 
NumPy 1.0 (and re-label those such as __array_data__ that are useful in 
other contexts --- like ctypes).

Comments?



-Travis

Re: [Numpy-discussion] eig hangs

[David M. C. <co...@ph...>]

On Thu, 8 Jun 2006 14:31:31 -0500
Robert Hetland <he...@ta...> wrote:

> 
> I set up a linux machine without BLAS, LAPACK, ATLAS, hoping that
> lapack_lite would take over.  For the moment, I am not concerned
> about speed -- I just want something that will work with small
> matricies.  I installed numpy, and it passes all of the tests OK, but
> it hangs when doing eig:
> 
> u, v = linalg.eig(rand(10,10))
> # ....lots of nothing....
> 
> Do you *need* the linear algebra libraries for eig? BTW,  inverse
> seems to work fine.

It should work. Can you give us a specific matrix where it fails? What
platform are you running on?

Lapack_lite probably doesn't get much testing from the developers, because we
probably all have optimized versions of blas and lapack.

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

[Numpy-discussion] eig hangs

[Robert H. <he...@ta...>]

I set up a linux machine without BLAS, LAPACK, ATLAS, hoping that
lapack_lite would take over.  For the moment, I am not concerned
about speed -- I just want something that will work with small
matricies.  I installed numpy, and it passes all of the tests OK, but
it hangs when doing eig:

u, v = linalg.eig(rand(10,10))
# ....lots of nothing....

Do you *need* the linear algebra libraries for eig? BTW,  inverse
seems to work fine.

-Rob


-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

Re: [Numpy-discussion] 5 bugs in numpy 0.9.8

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

Sven Schreiber wrote:
> Well as I got no replies it seems my earlier title wasn't drastic enough ;-)
> And mere mortals like me can't seem to file new tickets anymore, so I'm
> re-posting a summary here:

Of course you can file new tickets. You just have to register an account. Click
on the "Register" link in the upper right-hand corner of the Trac page.

We had to disallow unauthenticated ticket creation and wiki editing because we
were getting hit daily by spammers.

-- 
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] 5 bugs in numpy 0.9.8 (was: remaining matrix-non-preserving functions)

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

Well as I got no replies it seems my earlier title wasn't drastic enough ;-)
And mere mortals like me can't seem to file new tickets anymore, so I'm
re-posting a summary here:

affected functions:
diff
vstack
hstack
outer
msort

symptom:
given numpy-matrices as inputs, these functions still return
numpy-arrays (as opposed to the applicable rest of numpy's functions)

Cheers,
Sven

Sven Schreiber schrieb:
> Hi all,
> 
> I just discovered that the diff function returns a numpy-array even for
> matrix inputs. Since I'm a card-carrying matrix fanatic, I hope that
> behavior qualifies as a bug.
> 
> Then I went through some (most?) other functions/methods for which IMO
> it's best to return matrices if the input is also a matrix-type. I found
> that the following functions share the problem of diff (see below for
> illustrations):
> 
>  vstack and hstack (although I always use r_ and c_ and they work fine
> with matrices)
> 
>  outer
> 
>  msort
> 
> 
> Should I open new tickets? (Or has this already been fixed since 0.9.8,
> which I used because this time building the svn version failed for me?)
> 
> Cheers,
> Sven
> 
>>>> n.__version__
> '0.9.8'
>>>> a
> matrix([[1, 0, 0],
>        [0, 1, 0],
>        [0, 0, 1]])
>>>> b
> matrix([[0, 0, 0],
>        [0, 0, 0]])
>>>> n.diff(a)
> array([[-1,  0],
>        [ 1, -1],
>        [ 0,  1]])
>>>> n.outer(a,b)
> array([[0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0],
>        [0, 0, 0, 0, 0, 0]])
>>>> n.msort(a)
> array([[0, 0, 0],
>        [0, 0, 0],
>        [1, 1, 1]])
>>>> n.vstack([a,b])
> array([[1, 0, 0],
>        [0, 1, 0],
>        [0, 0, 1],
>        [0, 0, 0],
>        [0, 0, 0]])
>>>> n.hstack([a,b.T])
> array([[1, 0, 0, 0, 0],
>        [0, 1, 0, 0, 0],
>        [0, 0, 1, 0, 0]])
> 
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 

Re: [Numpy-discussion] .debs of numpy-0.9.8 available for Ubuntu Dapper

[Andrew S. <str...@as...>]

Pau Gargallo wrote:
> is your effort somehow related to
> http://packages.debian.org/experimental/python/python2.3-numpy
> ?
>
> it is a bit out of date, but already in experimental.
>   
I did have a look at their packaging infrastructure. It was breaking for 
me with numpy-0.9.8, so I started my debian/rules from scratch (and 
tried several methods along the way -- both debhelper and cdbs based). 
Now, upon re-looking at their debian/rules which is also cdbs based, I 
can see they have some nice code I should use (regarding installation of 
documentation and f2py). I'll try to integrate their changes into my 
next release. At that point I may simply be maintaining a more 
up-to-date version of theirs.

They also package new scipy. I'll see if I can leverage their efforts 
when I try to package that.

Re: [Numpy-discussion] .debs of numpy-0.9.8 available for Ubuntu Dapper

[Andrew S. <str...@as...>]

Arnd Baecker wrote:
> What worries me is
> a) the Build conflicts: atlas3-base
>   
I hoped to investigate further and post afterwards, but my preliminary 
findings that led to this decision are:

1) building with atlas (atlas3-base and atlas3-base-dev) caused a 
significant slowdown (~10x) on my simple test on amd64 arch:

import timeit
shape = '(40,40)'
timeit.Timer('a=ones(shape=%s);svd(a)'%shape,'from numpy import ones; 
from numpy.linalg import svd')
print "NumPy: ", t2.repeat(5,500)

2) Even having atlas installed (atlas3-base on amd64) caused a 
significant slowdown (~2x) on that test. This was similar to the case 
for i386, where I installed atlas3-sse2.
3) This is done in the source packages by Matthias Klose for both 
numeric and numarray, too. I figured he knows what he's doing.
> b) and the python2.3-dev *and* python2.4-dev dependency
>   
This is a _build_ dependency. The source package builds python 
python2.3-numpy and python2.4-numpy, so it needs Python.h for both.
> Clearly, python-setuptools and cdbs are not yet installed
> on my system (should be no problem).
>   
I hope the setuptools issue, in particular, does not present a problem. 
As I said, I have created this repository for work, and I find 
setuptools to be invaluable for maintaining order amongst all the Python 
packages I use internally. In any case, this is again only a build 
dependency -- all it does is creates a numpy-0.9.8-py2.x.egg-info 
directory in site-packages alongside numpy.

Let me be clear, since there's a lot of trepidation regarding 
setuptools: there is no use of setuptools (or even installation of 
setuptools) required to use these packages. Setuptools is required only 
to build from source.
>> If I get some positive feedback, I'm likely to add this to the scipy.org
>> download page. Also, I hope the official Debian and Ubuntu distros pick
>> up numpy soon, and perhaps this will speed them along.
>>     
>
> yes - that would be brilliant!
>   
OK, I'll wait a couple of days for some positive confirmation that this 
stuff works, (even from the various systems I'm setting up this 
repository for), and then I'll post it on the website.
> What about scipy: presently debian sarge comes with
> scipy 0.3.2. Installing old-scipy and new-scipy side-by side
> seems impossible (unless one does something like wxversion select
> stuff...) - should the new scipy debs just replace the old ones?
>   
Unless you do some apt-pinning, I think any new scipy (0.4.x) in any 
repository in your sources list will automatically override the old 
(0.3.x) simply via the versioning mechanisms of apt-get. I like the idea 
of a wxversion-alike, but I've shifted all my code to use numpy and the 
new scipy, so I don't have any motivation to do any implementation.

Re: [Numpy-discussion] argsort question

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

Robert,

Argsort doesn't preserve order by default because quicksort is not a stable
sort. Try using the kind="merge" option and see what happens. Or try
lexsort, which is targeted at just this sort of sort and uses  merge sort.
See the documentation here.

http://scipy.org/Numpy_Example_List#head-9f8656795227e3c43e849c6c0435eeeb32afd722

Chuck

PS:  The function argsort doesn't seem to support this  extension in the
version I am using (time for another svn update), so you may have to do
something like

>>> a = empty(50)
>>> a.argsort(kind="merge")
array([48, 47, 46,  0,  1, 49, 37, 12, 22, 38, 11,  2, 10, 36, 40, 25, 18,
        6, 17,  4,  3, 20, 24, 43, 33,  9,  7, 35, 32,  8, 23, 21,  5, 28,
       31, 30, 29, 26, 27, 19, 44, 13, 14, 15, 34, 39, 41, 42, 16, 45])

On 6/8/06, Robert Cimrman <cim...@nt...> wrote:
>
> Hi all,
>
> I have just lost some time to find a bug related to the fact, that
> argsort does not preserve the order of an array that is already sorted,
> see the example below. For me, it would be sufficient to mention this
> fact in the docstring, although having order preserving argsort is also
> an option :). What do the developers think?
>
> In [33]:a = nm.zeros( 10000 )
> In [34]:b = nm.arange( 10000 )
> In [35]:nm.alltrue( nm.argsort( a ) == b )
> Out[35]:False
>
> r.
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] argsort question

[Robert C. <cim...@nt...>]

Charles R Harris wrote:
> Robert,
> 
> Modifying your example gives
> 
> In [3]: import numpy as nm
> 
> In [4]: a = nm.zeros( 10000 )
> In [5]: b = nm.arange( 10000 )
> In [6]: nm.alltrue( a.argsort(kind="merge" ) == b )
> Out[6]: True

Thanks for all the answers!
r.

Re: [Numpy-discussion] argsort question

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

Robert,

Modifying your example gives

In [3]: import numpy as nm

In [4]: a = nm.zeros( 10000 )

In [5]: b = nm.arange( 10000 )

In [6]: nm.alltrue( a.argsort(kind="merge" ) == b )
Out[6]: True


On 6/8/06, Robert Cimrman <cim...@nt...> wrote:
>
> Hi all,
>
> I have just lost some time to find a bug related to the fact, that
> argsort does not preserve the order of an array that is already sorted,
> see the example below. For me, it would be sufficient to mention this
> fact in the docstring, although having order preserving argsort is also
> an option :). What do the developers think?
>
> In [33]:a = nm.zeros( 10000 )
> In [34]:b = nm.arange( 10000 )
> In [35]:nm.alltrue( nm.argsort( a ) == b )
> Out[35]:False
>
> r.
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] argsort question

[Robert C. <cim...@nt...>]

Travis Oliphant wrote:
> Robert Cimrman wrote:
> 
>>I have just lost some time to find a bug related to the fact, that 
>>argsort does not preserve the order of an array that is already sorted, 
>>see the example below. For me, it would be sufficient to mention this 
>>fact in the docstring, although having order preserving argsort is also 
>>an option :). What do the developers think?
>>
>>In [33]:a = nm.zeros( 10000 )
>>In [34]:b = nm.arange( 10000 )
>>In [35]:nm.alltrue( nm.argsort( a ) == b )
>>Out[35]:False
>>
> You want a "stable" sorting algorithm like the "mergesort".  Use the 
> argsort method with the mergesoret kind option:
> 
> a.argsort(kind='merge')

Thank you, Travis. Now I see that the function argsort in oldnumeric.py 
has different docstring that the array method argsort, which mentions 
the 'kind' keyword argument. Is the argsort function going to be 
deprecated? If no, is it possible to synchronize the docstrings? Also a 
note (in docs) which algorithm is stable would be handy.

regards,
r.

Re: [Numpy-discussion] argsort question

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

Robert Cimrman wrote:
> Hi all,
>
> I have just lost some time to find a bug related to the fact, that 
> argsort does not preserve the order of an array that is already sorted, 
> see the example below. For me, it would be sufficient to mention this 
> fact in the docstring, although having order preserving argsort is also 
> an option :). What do the developers think?
>
> In [33]:a = nm.zeros( 10000 )
> In [34]:b = nm.arange( 10000 )
> In [35]:nm.alltrue( nm.argsort( a ) == b )
> Out[35]:False
>
>   

You want a "stable" sorting algorithm like the "mergesort".  Use the 
argsort method with the mergesoret kind option:

a.argsort(kind='merge')

-Travis

[Numpy-discussion] argsort question

[Robert C. <cim...@nt...>]

Hi all,

I have just lost some time to find a bug related to the fact, that 
argsort does not preserve the order of an array that is already sorted, 
see the example below. For me, it would be sufficient to mention this 
fact in the docstring, although having order preserving argsort is also 
an option :). What do the developers think?

In [33]:a = nm.zeros( 10000 )
In [34]:b = nm.arange( 10000 )
In [35]:nm.alltrue( nm.argsort( a ) == b )
Out[35]:False

r.

Re: [Numpy-discussion] ndarray of matrices

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

On 6/8/06, Alexandre Guimond <ale...@mi...> wrote:
>
>
>
>
> Hi all.
>
>
>
> i work mainly with "volume" (3d) images, and numpy.ndarray answers most of
> my needs (addition of images, etc.). The problem I'm faced now with is that
> I have images of matrices and vectors and would like that when I do
> image_of_matrices * image_of_vector is does the dot product of each of my
> matrices with all of my vectors, and when I do image_of_matrices.mean() it
> gives me the mean matrix. Basically, I want the same functionalities that
> are currently provided with scalars, but applied to matrices.
>
>
>
> It seems that a nice way of doing this is to have and ndarray of
> numpy.matrix, but this isn't supported it seems. Can anyone recommend a good
> way of implementing this? I'm new with the numpy thing and I'm not sure if
> subclassing ndarray is a good idea since I'll have to overload all the
> operators and i don't believe this will result in a very fast
> implementation, but I might be mistaken. Another possibility may be to
> create a new dtype for numpy.matrix, but I don't know if this is possible.
> Anyone have recommandations?
>
>
>
> Thx for any help.
>

We are several of us wondering which is the best way to do this kind
of things. We were discussing this before
(http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/3130104),
and some solutions were proposed, but we still don't have the definitive answer.

Building arrays of matrices objects will be too inefficient.
For me the best thing would be to have n-dimensional universal
functions, but this don't exist yet.

Meanwhile, I am using the following code (which is not *the* solution):

from numpy import *

nz,ny,nx = 1,1,1

im_of_mat = rand( nz, ny, nx, 3,3 )
im_of_vec = rand( nz, ny, nx, 3 )

im_of_products = ( im_of_mat * im_of_vec[...,newaxis,:] ).sum(axis=-1)


# test that everything it's ok
for m,v,p in zip(im_of_mat.reshape(-1,3,3),
		 im_of_vec.reshape(-1,3),
		 im_of_products.reshape(-1,3)):
	assert allclose( dot(m,v), p )



pau

[Numpy-discussion] ndarray of matrices

[Alexandre G. <ale...@mi...>]

Hi all.

=20

i work mainly with "volume" (3d) images, and numpy.ndarray answers most
of my needs (addition of images, etc.). The problem I'm faced now with
is that I have images of matrices and vectors and would like that when I
do image_of_matrices * image_of_vector is does the dot product of each
of my matrices with all of my vectors, and when I do
image_of_matrices.mean() it gives me the mean matrix. Basically, I want
the same functionalities that are currently provided with scalars, but
applied to matrices.

=20

It seems that a nice way of doing this is to have and ndarray of
numpy.matrix, but this isn't supported it seems. Can anyone recommend a
good way of implementing this? I'm new with the numpy thing and I'm not
sure if subclassing ndarray is a good idea since I'll have to overload
all the operators and i don't believe this will result in a very fast
implementation, but I might be mistaken. Another possibility may be to
create a new dtype for numpy.matrix, but I don't know if this is
possible. Anyone have recommandations?

=20

Thx for any help.

=20

Alex.



NOTICE: This e-mail message and all attachments=0Atransmitted with it may=
 contain legally privileged and=0Aconfidential information intended solel=
y for the use of=0Athe addressee. If the reader of this message is not th=
e=0Aintended recipient, you are hereby notified that any=0Areading, disse=
mination, distribution, copying, or other=0Ause of this message or its at=
tachments, hyperlinks, or=0Aany other files of any kind is strictly prohi=
bited. If you=0Ahave received this message in error, please notify the=0A=
sender immediately by telephone (+44-1865-265500) or by=0Aa reply to this=
 electronic mail message and delete this=0Amessage and all copies and bac=
kups thereof.=0A

Re: [Numpy-discussion] .debs of numpy-0.9.8 available for Ubuntu Dapper

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

On 6/8/06, Andrew Straw <str...@as...> wrote:
> I've put together some .debs for numpy-0.9.8. There are binaries
> compiled for amd64 and i386 architectures of Ubuntu Dapper, and I
> suspect these will build from source for just about any Debian-based
> distro and architecture.
>
> The URL is http://sefton.astraw.com/ubuntu/dapper and you would add the
> following lines to your /etc/apt/sources.list:
> deb http://sefton.astraw.com/ubuntu/ dapper/
> deb-src http://sefton.astraw.com/ubuntu/ dapper/
>
> Although this is the culmination of my first serious attempt Debianizing
> something, I've attempted to build these "properly" (using inspiration
> from Matthias Klose's Numeric and numarray packages for Debian and
> Ubuntu, although I've updated the build system to use CDBS).
>
> The numpy source has a build dependency on setuptools (0.6b2), which is
> also available at the repository. Numpy doesn't get installed as an
> .egg, but it carries along .egg-info, which means that numpy can be part
> of a setuptools dependency specification. This was done using the
> --single-version-externally-managed command for setuptools.
>
> I'm building this repository to serve some of my needs at work, and I
> hope to add recent versions of several other projects including
> matplotlib and scipy in the coming days. I hope to be able to keep the
> repository up-to-date over time and to respond to bug reports and
> questions, although the amount of time I have to devote to this sort of
> stuff is unfortunately often near zero.
>
> If I get some positive feedback, I'm likely to add this to the scipy.org
> download page. Also, I hope the official Debian and Ubuntu distros pick
> up numpy soon, and perhaps this will speed them along.
>

cool, debian packages will be great, thanks!!

is your effort somehow related to
http://packages.debian.org/experimental/python/python2.3-numpy
?

it is a bit out of date, but already in experimental.

cheers,
pau

Re: [Numpy-discussion] .debs of numpy-0.9.8 available for Ubuntu Dapper

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

Hi Andrew,

first thanks a lot for your effort - I am certain it
will be very much appreciated!

On Thu, 8 Jun 2006, Andrew Straw wrote:

> I've put together some .debs for numpy-0.9.8. There are binaries
> compiled for amd64 and i386 architectures of Ubuntu Dapper, and I
> suspect these will build from source for just about any Debian-based
> distro and architecture.
>
> The URL is http://sefton.astraw.com/ubuntu/dapper and you would add the
> following lines to your /etc/apt/sources.list:
> deb http://sefton.astraw.com/ubuntu/ dapper/
> deb-src http://sefton.astraw.com/ubuntu/ dapper/
>
> Although this is the culmination of my first serious attempt Debianizing
> something, I've attempted to build these "properly" (using inspiration
> from Matthias Klose's Numeric and numarray packages for Debian and
> Ubuntu, although I've updated the build system to use CDBS).
>
> The numpy source has a build dependency on setuptools (0.6b2), which is
> also available at the repository. Numpy doesn't get installed as an
> .egg, but it carries along .egg-info, which means that numpy can be part
> of a setuptools dependency specification. This was done using the
> --single-version-externally-managed command for setuptools.
>
> I'm building this repository to serve some of my needs at work, and I
> hope to add recent versions of several other projects including
> matplotlib and scipy in the coming days. I hope to be able to keep the
> repository up-to-date over time and to respond to bug reports and
> questions, although the amount of time I have to devote to this sort of
> stuff is unfortunately often near zero.

Alright, let's start with the first question:
We are still running debian sarge and therefore would have to
build the above from source.
I used the following steps:
- put
    deb-src http://sefton.astraw.com/ubuntu/ dapper/
  into /etc/apt/sources.list
- apt-get update  # update the source package search list
- apt-get source python-numpy
- cd python-numpy-0.9.8/
  dpkg-buildpackage -rfakeroot

and get:

dpkg-buildpackage: source package is python-numpy
dpkg-buildpackage: source version is 0.9.8-0ads1
dpkg-buildpackage: source maintainer is Andrew Straw <str...@as...>
dpkg-buildpackage: host architecture is i386
dpkg-checkbuilddeps: Unmet build dependencies: cdbs (>= 0.4.23-1.1)
build-essential python2.4-dev python-setuptools (>= 0.6b2)
python2.3-setuptools (>= 0.6b2) python2.4-setuptools (>= 0.6b2)
dpkg-checkbuilddeps: Build conflicts: atlas3-base
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: (Use -d flag to override.)

What worries me is
a) the Build conflicts: atlas3-base
b) and the python2.3-dev *and* python2.4-dev dependency
Clearly, python-setuptools and cdbs are not yet installed
on my system (should be no problem).

> If I get some positive feedback, I'm likely to add this to the scipy.org
> download page. Also, I hope the official Debian and Ubuntu distros pick
> up numpy soon, and perhaps this will speed them along.

yes - that would be brilliant!

What about scipy: presently debian sarge comes with
scipy 0.3.2. Installing old-scipy and new-scipy side-by side
seems impossible (unless one does something like wxversion select
stuff...) - should the new scipy debs just replace the old ones?

Best, Arnd

[Numpy-discussion] .debs of numpy-0.9.8 available for Ubuntu Dapper

[Andrew S. <str...@as...>]

I've put together some .debs for numpy-0.9.8. There are binaries 
compiled for amd64 and i386 architectures of Ubuntu Dapper, and I 
suspect these will build from source for just about any Debian-based 
distro and architecture.

The URL is http://sefton.astraw.com/ubuntu/dapper and you would add the 
following lines to your /etc/apt/sources.list:
deb http://sefton.astraw.com/ubuntu/ dapper/
deb-src http://sefton.astraw.com/ubuntu/ dapper/

Although this is the culmination of my first serious attempt Debianizing 
something, I've attempted to build these "properly" (using inspiration 
from Matthias Klose's Numeric and numarray packages for Debian and 
Ubuntu, although I've updated the build system to use CDBS).

The numpy source has a build dependency on setuptools (0.6b2), which is 
also available at the repository. Numpy doesn't get installed as an 
.egg, but it carries along .egg-info, which means that numpy can be part 
of a setuptools dependency specification. This was done using the 
--single-version-externally-managed command for setuptools.

I'm building this repository to serve some of my needs at work, and I 
hope to add recent versions of several other projects including 
matplotlib and scipy in the coming days. I hope to be able to keep the 
repository up-to-date over time and to respond to bug reports and 
questions, although the amount of time I have to devote to this sort of 
stuff is unfortunately often near zero.

If I get some positive feedback, I'm likely to add this to the scipy.org 
download page. Also, I hope the official Debian and Ubuntu distros pick 
up numpy soon, and perhaps this will speed them along.

[Numpy-discussion] Typo in SWIG example

[Yves F. <yve...@cs...>]

Hi,

When having a look at the SWIG example under trunk/numpy/doc/swig, I
noticed a typing error in numpy.i. You can find the patch in attachment.

Cheers,
YVES


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