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

Re: [Numpy-discussion] Things to address for Py3K

[Eric F. <ef...@ha...>]

Charles R Harris wrote:
[...]
>        b) extending 'and' and 'or' to allow element-by-element logical
>     operations or adding && and ||
> 
>     2) Lowering the precedence of & so that a > 8 & a < 10  works as you
>     would expect.
> 
> 
> Yes on the extra operators. No on changing the precedence of &, that 
> would just confuse the heck out of all us c/c++ programmers; && and || 
> would be good. 

Travis's suggestion 2 is consistent with c/c++, where precedence 
increases from logical to bitwise to relational. (e.g., 
http://www.cs.niu.edu/~duffin/csci241/precedence.html).

Python precedence now increases from logical to relational to bitwise, 
so it is inconsistent with c/c++. 
(http://docs.python.org/ref/summary.html#l2h-456)

Eric

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

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

Travis Oliphant wrote:
> Sven Schreiber wrote:
>
>   
>>> This is user adjustable.  You change the error mode to raise on 
>>> 'invalid' instead of pass silently which is now the default.
>>>
>>> -Travis
>>>
>>>    
>>>
>>>       
>> Could you please explain how this adjustment is done, or point to the
>> relevant documentation.
>>  
>>
>>     
>
> numpy.sqrt(-1)
>
> old = seterr(invalid='raise')
> numpy.sqrt(-1)  # should raise an error
>
> seterr(**old)  # restores error-modes for current thread
> numpy.sqrt(-1)
>
>   
With python 2.5 out now, perhaps it's time to come up with a with 
statement context manager. Something like:

    from __future__ import with_statement
    import numpy

    class errstate(object):
        def __init__(self, **kwargs):
            self.kwargs = kwargs
        def __enter__(self):
            self.oldstate = numpy.seterr(**self.kwargs)
        def __exit__(self, *exc_info):
            numpy.seterr(**self.oldstate)
           
    a = numpy.arange(10)
    a/a # ignores divide by zero
    with errstate(divide='raise'):
        a/a # raise exception on divide by zer
    # Would ignore divide by zero again if we got here.

-tim

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

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

Fernando Perez wrote:

>On 10/11/06, Travis Oliphant <oli...@ee...> wrote:
>
>  
>
>>pe...@ce... wrote:
>>    
>>
>>>Could sqrt(-1) made to return 1j again?
>>>
>>>      
>>>
>>Not in NumPy.  But, in scipy it could.
>>    
>>
>
>Without taking sides on which way to go, I'd like to -1 the idea of a
>difference in behavior between numpy and scipy.
>
>IMHO, scipy should be within reason a strict superset of numpy.
>  
>
This was not the relationship of scipy to Numeric.

For me, it's the fact that scipy *used* to have the behavior that

scipy.sqrt(-1) return 1j

and now doesn't  that is the kicker. 

On the other hand requiring all calls to numpy.sqrt to go through an 
"argument-checking" wrapper is a bad idea as it will slow down other uses.

So, I committed a change to scipy to bring it back into compatibility 
with 0.3.2



>Gratuitious differences in behavior like this one are going to drive
>us all mad.
>
>There are people who import scipy for everything, others distinguish
>between numpy and scipy, others use numpy alone and at some point in
>their life's code they do
>
>import numpy as N -> import scipy as N
>
>because they start needing stuff not in plain numpy.  Having different
>APIs and behaviors appear there is, I think, a Seriously Bad Idea
>(TM).
>  
>
I think the SBI is mixing numpy and scipy gratuitously  (which I admit I 
have done in the past).  I'm trying to repent....

-Travis

Re: [Numpy-discussion] Things to address for Py3K

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

A. M. Archibald wrote:
> IEEE floats in python proper

+1

-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] Things to address for Py3K

[A. M. A. <per...@gm...>]

On 11/10/06, Charles R Harris <cha...@gm...> wrote:

> Speaking long term, what about data types? The basic 80 bit extended
> precision float now occurs in 80, 96, and 128 bit versions depending on
> alignment. So what happens when quad precision, which will probably be in
> the next IEEE standard, comes down the pike and is 128 bits long? The length
> of a float will no longer be sufficient to distinguish the various types.

This doesn't require python 3K; it can happn in numpy with no language
support. But perhaps python 3K can be viewed as a chance to ditch
backwards-compatibility baggage? (cough, Numeric compatibility, cough)

Would it be of interest to have numeric datatypes integrated with
python datatypes? How about IEEE floats in python proper, at least? It
can be rather confusing when doing a calculation yields different
results for arrays than for ordinary scalars...

A. M. Archibald

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

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

On 10/11/06, Travis Oliphant <oli...@ee...> wrote:

> pe...@ce... wrote:
> >Could sqrt(-1) made to return 1j again?
> >
> Not in NumPy.  But, in scipy it could.

Without taking sides on which way to go, I'd like to -1 the idea of a
difference in behavior between numpy and scipy.

IMHO, scipy should be within reason a strict superset of numpy.
Gratuitious differences in behavior like this one are going to drive
us all mad.

There are people who import scipy for everything, others distinguish
between numpy and scipy, others use numpy alone and at some point in
their life's code they do

import numpy as N -> import scipy as N

because they start needing stuff not in plain numpy.  Having different
APIs and behaviors appear there is, I think, a Seriously Bad Idea
(TM).

Just my 1e-2j,

Cheers,

f

Re: [Numpy-discussion] Things to address for Py3K

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

Travis Oliphant wrote:
>> 3) Inclusion of an nd-array type in the standard lib!
>> (or at the very least, an nd-array protocol)
>>
> Work on an nd-array protocol to extend the buffer protocol is occurring 
> right now.  It think this will be better in the end then a standard 
> nd-array type. 

Well, yes, if you have to choose just one. I'd like to see both.

> I think a multi-dimensional object array would at least be a nice step.

Me too. n-d slicing is so handy.

> There are enough differences between lists and 1-d arrays though, that 
> I'm not sure the accepted multi-dimensional object array would just be 
> the NumPy version.  

I guess the question is whether the goal is an n-d list or an n-d array. 
The key difference that I see is that numpy arrays are not re-sizable. 
But I have to wonder how practical it is to make an nd-array re-sizable, 
and, indeed, how that would work. I'm not sure what the n-d version of 
append() would be.

Numpy provides three things that I think are key:

1) An n-d array data structure. These are very useful for lots of things 
where an multi-dimensional data structure just makes sense. For these 
cases, you need the object array type (class?), and  n-d slicing.

2) array arithmetic: I'm a big fan of list comprehensions, but:

A = [x * 2 for x in B]

really is a LOT klunkier, and far less clear, than:

A = 2 * B

or even worse:

A = []
for x in B:
     A.append(2*x)

While array arithmetic is often seen primarily as a performance 
advantage (which, of course, it is) I also think it is a real boon to 
clear, error-free coding, and Python could use that.

3) A bunch of other really "mathy" or "scientific" functions:
(looking in the numpy book here)

polynomial functions
set operations (hmm -- there is a Python set type)
bessel functions
smoothing windows
fft
llinalg
etc.
etc.

These really do belong in numpy (scipy?), rather than the standard lib.

However this turn out, thanks for keeping numpy in the py3k loop.

-Chris










-- 
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] Should numpy.sqrt(-1) return 1j rather than nan?

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

Sven Schreiber wrote:

>>This is user adjustable.  You change the error mode to raise on 
>>'invalid' instead of pass silently which is now the default.
>>
>>-Travis
>>
>>    
>>
>
>Could you please explain how this adjustment is done, or point to the
>relevant documentation.
>  
>

numpy.sqrt(-1)

old = seterr(invalid='raise')
numpy.sqrt(-1)  # should raise an error

seterr(**old)  # restores error-modes for current thread
numpy.sqrt(-1)

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

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

Travis Oliphant schrieb:

> 
>> If not, shouldn't
>>  
>>
>> numpy.sqrt(-1) raise a ValueError instead of returning silently nan?
>>  
>>
> This is user adjustable.  You change the error mode to raise on 
> 'invalid' instead of pass silently which is now the default.
> 
> -Travis
> 

Could you please explain how this adjustment is done, or point to the
relevant documentation.
Thank you,
Sven

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

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

pe...@ce... wrote:

>Hi,
>
>I have recieved the following note from a user:
>
>"""
>In SciPy 0.3.x the ufuncs were overloaded by more "intelligent" versions.
>A very attractive feature was that sqrt(-1) would yield 1j as in Matlab.
>Then you can program formulas directly (e.g., roots of a 2nd order
>polynomial) and the right answer is always achieved. In the Matlab-Python
>battle in mathematics education, this feature is important.
>
>Now in SciPy 0.5.x sqrt(-1) yields nan. A lot of code we have, especially
>for introductory numerics and physics courses, is now broken.
>This has already made my colleagues at the University skeptical to
>Python as "this lack of backward compatibility would never happen in Matlab".
>  
>
This was a consequence of moving scipy_base into NumPy but not exposing 
the scimath library in NumPy.   It would be a very easy thing to put 
from numpy.lib.scimath import *
into the scipy name-space.

I'm supportive of that as a backward-compatibility measure.

>Another problem related to Numeric and numpy is that in these courses we
>use ScientificPython several places, which applies Numeric and will
>continue to do so. You then easily get a mix of numpy and Numeric
>in scripts, which may cause problems and at least extra overhead.
>Just converting to numpy in your own scripts isn't enough if you call
>up libraries using and returning Numeric.
>  
>
>"""
>
>I wonder, what are the reasons that numpy.sqrt(-1) returns nan?
>  
>
Because that is backwards compatible.  You have to construct a 
function-wrapper in order to handle the negative case correctly.  The 
function wrapper is going to be slower.  Thus, it is placed in a 
separate library.

>Could sqrt(-1) made to return 1j again? 
>
Not in NumPy.  But, in scipy it could.

>If not, shouldn't
>  
>
>numpy.sqrt(-1) raise a ValueError instead of returning silently nan?
>  
>
This is user adjustable.  You change the error mode to raise on 
'invalid' instead of pass silently which is now the default.

-Travis

Re: [Numpy-discussion] round

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

Hmm. I learned "round to even" in school...

But another formula that should get you what you want is:
   floor(x + 0.5).astype(int)

--bb

On 10/12/06, Greg Willden <gre...@gm...> wrote:
> Hi All,
>
> I've read discussions in the archives about how round() "rounds to even" and
> how that is supposedly better.
>
> But what I haven't been able to find is "What do I use if I want the regular
> old round that you learn in school?"
>
> Sorry for the likely FAQ.
> Greg
> --
> Linux.  Because rebooting is for adding hardware.
> -------------------------------------------------------------------------
> 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] round

[Greg W. <gre...@gm...>]

On 10/11/06, Charles R Harris <cha...@gm...> wrote:
>
> Perhaps you could explain *why* you want the schoolbook round? Given that
> floating point is inherently inaccurate you would have to expect to produce
> a lot of numbers exactly of the form x.5 *without errors*, which means you
> probably don't need round to deal with it. Anyway, absent a flag somewhere,
> you can do something like (x + sign(x)*.5).astype(int).
>


Yeah.  Forget it.  That was stupid of me to step into that one.
This has obviously been discussed before and you have good reasons for doing
it the way you do it.
Carry on.
Greg
-- 
Linux.  Because rebooting is for adding hardware.

[Numpy-discussion] Library problem on installation

[Michael S. <msu...@gm...>]

Hi,

I know that it's a perennial topic on the list, but I haven't been able to
find my answer in the archives. After running the installation on a RedHat
Linux machine, I'm getting the import error: "/usr/lib/libblas.so.3:
undefined symbol: e_wsfe". Judging from earlier exchanges here, it seems
that I need to add libg2c (which this machine does have in /usr/lib, unlike
g2c) somewhere between 'f77blas' and 'cblas', but I'm not sure where I
should make this change. Not being well versed in Python distributions, I
tried my luck with a few candidates and the import error remains. The
machine should be running gcc.

Thanks for any help.

Michael

Re: [Numpy-discussion] round

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

On 10/11/06, Greg Willden <gre...@gm...> wrote:
>
> Hi All,
>
> I've read discussions in the archives about how round() "rounds to even"
> and how that is supposedly better.
>
> But what I haven't been able to find is "What do I use if I want the
> regular old round that you learn in school?"


Perhaps you could explain *why* you want the schoolbook round? Given that
floating point is inherently inaccurate you would have to expect to produce
a lot of numbers exactly of the form x.5 *without errors*, which means you
probably don't need round to deal with it. Anyway, absent a flag somewhere,
you can do something like (x + sign(x)*.5).astype(int).

Chuck

[Numpy-discussion] round

[Greg W. <gre...@gm...>]

Hi All,

I've read discussions in the archives about how round() "rounds to even" and
how that is supposedly better.

But what I haven't been able to find is "What do I use if I want the regular
old round that you learn in school?"

Sorry for the likely FAQ.
Greg
-- 
Linux.  Because rebooting is for adding hardware.

[Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[<pe...@ce...>]

Hi,

I have recieved the following note from a user:

"""
In SciPy 0.3.x the ufuncs were overloaded by more "intelligent" versions.
A very attractive feature was that sqrt(-1) would yield 1j as in Matlab.
Then you can program formulas directly (e.g., roots of a 2nd order
polynomial) and the right answer is always achieved. In the Matlab-Python
battle in mathematics education, this feature is important.

Now in SciPy 0.5.x sqrt(-1) yields nan. A lot of code we have, especially
for introductory numerics and physics courses, is now broken.
This has already made my colleagues at the University skeptical to
Python as "this lack of backward compatibility would never happen in Matlab".

Another problem related to Numeric and numpy is that in these courses we
use ScientificPython several places, which applies Numeric and will
continue to do so. You then easily get a mix of numpy and Numeric
in scripts, which may cause problems and at least extra overhead.
Just converting to numpy in your own scripts isn't enough if you call
up libraries using and returning Numeric.
"""

I wonder, what are the reasons that numpy.sqrt(-1) returns nan?
Could sqrt(-1) made to return 1j again? If not, shouldn't
numpy.sqrt(-1) raise a ValueError instead of returning silently nan?

Thanks,
Pearu

Re: [Numpy-discussion] Things to address for Py3K

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

On 10/11/06, Travis Oliphant <oli...@ee...> wrote:
>
>
> Hi all,
>
> Py3K is undergoing active development.  This gives us an opportunity to
> discuss more significant changes to the language that might improve the
> experience of NumPy users.
>
> We should form a list and start commenting on the py3k mailing lists
> about what changes would be most  helpful for our community.
>
> Please provide examples of changes to Python that you think might help us.
>
> A couple on my short list
>
> 1) Adding a *few* new infix operators.
>
>    a) an extra multiplication operator to distinguish between
> element-by-element and dot
>    b) extending 'and' and 'or' to allow element-by-element logical
> operations or adding && and ||
>
> 2) Lowering the precedence of & so that a > 8 & a < 10  works as you
> would expect.


Yes on the extra operators. No on changing the precedence of &, that would
just confuse the heck out of all us c/c++ programmers; && and || would be
good. Yes to something that improves on the buffer interface, although it is
certainly usable right now.

Speaking long term, what about data types? The basic 80 bit extended
precision float now occurs in 80, 96, and 128 bit versions depending on
alignment. So what happens when quad precision, which will probably be in
the next IEEE standard, comes down the pike and is 128 bits long? The length
of a float will no longer be sufficient to distinguish the various types.

Chuck

Re: [Numpy-discussion] Things to address for Py3K

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

Christopher Barker wrote:

>Travis Oliphant wrote:
>  
>
>>A couple on my short list
>>
>>1) Adding a *few* new infix operators.
>>
>>   a) an extra multiplication operator to distinguish between 
>>element-by-element and dot
>>   b) extending 'and' and 'or' to allow element-by-element logical 
>>operations or adding && and ||
>>
>>2) Lowering the precedence of & so that a > 8 & a < 10  works as you 
>>would expect.
>>    
>>
>
>Maybe this goes without saying, but:
>
>3) Inclusion of an nd-array type in the standard lib!
>
>(or at the very least, an nd-array protocol)
>  
>
Work on an nd-array protocol to extend the buffer protocol is occurring 
right now.  It think this will be better in the end then a standard 
nd-array type. 

I think a multi-dimensional object array would at least be a nice step.

There are enough differences between lists and 1-d arrays though, that 
I'm not sure the accepted multi-dimensional object array would just be 
the NumPy version.  

-Travis

Re: [Numpy-discussion] Things to address for Py3K

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

Travis Oliphant wrote:
> A couple on my short list
> 
> 1) Adding a *few* new infix operators.
> 
>    a) an extra multiplication operator to distinguish between 
> element-by-element and dot
>    b) extending 'and' and 'or' to allow element-by-element logical 
> operations or adding && and ||
> 
> 2) Lowering the precedence of & so that a > 8 & a < 10  works as you 
> would expect.

Maybe this goes without saying, but:

3) Inclusion of an nd-array type in the standard lib!

(or at the very least, an nd-array protocol)

-Chris




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

[Numpy-discussion] Things to address for Py3K

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

Hi all,

Py3K is undergoing active development.  This gives us an opportunity to 
discuss more significant changes to the language that might improve the 
experience of NumPy users. 

We should form a list and start commenting on the py3k mailing lists 
about what changes would be most  helpful for our community.

Please provide examples of changes to Python that you think might help us.

A couple on my short list

1) Adding a *few* new infix operators.

   a) an extra multiplication operator to distinguish between 
element-by-element and dot
   b) extending 'and' and 'or' to allow element-by-element logical 
operations or adding && and ||

2) Lowering the precedence of & so that a > 8 & a < 10  works as you 
would expect.

Re: [Numpy-discussion] select part of array using two conditions

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

On 10/11/06, Nils Wagner <nw...@ia...> wrote:
> Mark Bakker wrote:
> > Hello -
> >
> > I want to select part of an array using two conditions.
> > I know how to do it with one condition (and it works great), but when
> > I use two conditions I get an error message?
> > This is probably easy, but I cannot figure it out.
> > Thanks for any help, Mark
> >
> > >>> a = arange(10)
> > >>> a
> > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
> > >>> a[ a>2 ]
> > array([3, 4, 5, 6, 7, 8, 9])
> > >>> a[ a>2 and a<8 ]
> > Traceback (most recent call last):
> >   File "<pyshell#52>", line 1, in ?
> >     a[ a>2 and a<8 ]
> > ValueError: The truth value of an array with more than one element is
> > ambiguous. Use a.any() or a.all()
> >
> > ------------------------------------------------------------------------
> >
> a[ (a>2) & (a<8) ]
>

& is bitwiase and which works fine for the booleans you get back from
comparisons like (a>2).  So in this case & is ok.

For arrays with non-boolean values (any non-zero is True) use logical_and:

    a[ logical_and(c, d) ]

Logical_and works always to give you the boolean result.
'&' gives you the bitwise result, which is sometimes equivalent to the
boolean result.

--bb

Re: [Numpy-discussion] cannot import Numeric

[Carl W. <car...@ya...>]

thanks.

Travis Oliphant <oli...@ee...> wrote: Carl Wenrich wrote:

> thanks, but actually it's the other applications i want to use that 
> have the 'import Numeric' line in them. i'm sure others have noted 
> this before. what's the normal procedure?


You must install Numeric if a package needs Numeric.  As far as Python 
is concerned NumPy is a separate package. Packages must be "ported" to 
use numpy.  Please encourage the package author to port.  Help is 
available for open source packages.  Just ask on the list.

-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] cannot import Numeric

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

Carl Wenrich wrote:

> thanks, but actually it's the other applications i want to use that 
> have the 'import Numeric' line in them. i'm sure others have noted 
> this before. what's the normal procedure?


You must install Numeric if a package needs Numeric.  As far as Python 
is concerned NumPy is a separate package. Packages must be "ported" to 
use numpy.  Please encourage the package author to port.  Help is 
available for open source packages.  Just ask on the list.

-Travis

Re: [Numpy-discussion] asmatrix and asarray exception

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

Charles R Harris wrote:

>
>
> On 10/11/06, *Keith Goodman* <kwg...@gm... 
> <mailto:kwg...@gm...>> wrote:
>
>     On 10/11/06, Keith Goodman <kwg...@gm...
>     <mailto:kwg...@gm...>> wrote:
>     > This works:
>     >
>     > >> M.asmatrix(['a', 'b', None])
>     > matrix([[a, b, None]], dtype=object)
>     >
>     > But this doesn't:
>     >
>     > >> M.asmatrix(['a', 'b', None, 'c'])
>     > TypeError: expected a readable buffer object
>     >
>
>
> As a side observation, I note that the 'None' is also non-printing:
>
> >>> a = asarray(['a', 'b', None, 'c'], dtype=object)
> >>> a[2]
> >>> str(a[2])
> 'None'
>
> I wonder if this should be changed?

That's Python's decision.  You are getting back the None object when you 
access element a[2].  Thus, there is no way to change it.

-Travis

Re: [Numpy-discussion] cannot import Numeric

[Carl W. <car...@ya...>]

thanks, but actually it's the other applications i want to use that have the 'import Numeric' line in them. i'm sure others have noted this before. what's the normal procedure?

Darren Dale <dd...@co...> wrote: On Wednesday 11 October 2006 12:48, Carl Wenrich wrote:
> The installation of Numpy went well, and numeric.py is in the python
> site-packages/numpy/core directory. But when I run python, and enter import
> Numeric, it says no module named Numeric. Please advise.

import numpy

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