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

Re: [Numpy-discussion] avoiding the matrix copy performance hit

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

Tim Hochberg wrote:

> Bill Baxter wrote:
>
>> Is there anyway to get around this timing difference?
>> *
>>   >>> import timeit
>> **  >>> t1 = timeit.Timer("a = zeros((1000,1000),'d'); a += 1.;",  
>> 'from numpy import zeros,mat')
>> **  >>> t2 = timeit.Timer("a = mat(zeros((1000,1000),'d')); a += 
>> 1.;",  'from numpy import zeros,mat')
>>   >>> **t1.timeit(100)
>>   1.8391627591141742
>>   >>> t2.timeit(100)
>>   3.2988266117713465
>>
>> *Copying all the data of the input array seems wasteful when the 
>> array is just going to go out of scope.  Or is this not something to 
>> be concerned about? 
>

I think I originally tried to make mat *not* return a copy, but this 
actually broke code in SciPy.  So, I left the default as it was as a 
copy on input.  There is an *asmatrix* command that does not return a 
copy...

-Travis

Re: [Numpy-discussion] number ranges (was Re: Matlab page on scipy wiki)

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

I agree with Bill's comments. The other languages I've used have used 
closed/inclusive ranges, which made a lot of sense because they 
supported enumerated types. The Python Zen guideline breaks down for me 
because it never felt 'obvious' to me and the principle of least 
surprise told me to expect closed ranges. I can see the arguments for 
both though. I discovered that Ruby has both 0..10 and 0...10 syntax 
depending on whether you want open or closed ranges. I don't know if 
numpy should break with Python convention here and try to supply a 
closed range specifier because there should probably be a backup Zen 
guideline saying 'There should be one -- and preferably only one -- way 
to do it, even if it's not obvious.' If there was one, I'd use it in 
preference though.

Gary R.

Re: [Numpy-discussion] number ranges (was Re: Matlab page on scipy wiki)

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

Thanks for the suggestion.  Didn't realize there were all those other commo=
n
i* functions.  Maybe arangei is better.  It gives more indication that it's
mostly like arange, but different.

--bb

On 2/14/06, Tim Hochberg <tim...@co...> wrote:
>
>
> FWIW, I'd recomend a different name. irange sounds like it belongs in
> the itertools module with ifilter, islice, izip, etc. Perhaps, rangei
> would work, although admittedly it's harder to see. Maybe crange for
> closed range (versus half-open range)? I dunno, but irange seems like
> it's gonna confuse someone, if not you, then other people who end up
> looking at your code.
>
>

Re: [Numpy-discussion] String array equality test does not broadcast

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

Travis Oliphant wrote:

> Russel Howe wrote:
>
>> I am converting some numarray code to numpy and I noticed this behavior:
>>
>> >>> from numpy import *
>> >>> sta=array(['abc', 'def', 'ghi'])
>> >>> stb=array(['abc', 'jkl', 'ghi'])
>> >>> sta==stb
>> False
>>
>> I expected the same as this:
>> >>> a1=array([1,2,3])
>> >>> a2=array([1,4,3])
>> >>> a1==a2
>> array([True, False, True], dtype=bool)
>>
>> I am trying to figure out how to fix this now...
>
>
>
> Equality testing on string arrays does not work (equality testing uses 
> ufuncs internally which are not supported generally for flexible 
> arrays).   You must use chararray's.

Should string arrays then perhaps raise an exception here to keep people 
out of trouble?

-tim


>
> Thus,
>
> sta.view(chararray) == stb.view(chararray)
>
> Or create chararray's from the beginning:
>
> sta = char.array(['abc','def','ghi'])
> stb = char.array(['abc','jkl','ghi'])
>
> Char arrays are a special subclass of the ndarray that give arrays all 
> the methods of strings (and unicode) elements and allow (rich) 
> comparison operations.
>
> -Travis
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>

Re: [Numpy-discussion] Re: indexing problem

[<co...@ph...>]

Gary Ruben <gr...@bi...> writes:

> Tim Hochberg wrote:
> <snip>
>> However, I'm not convinced this is a good idea for numpy. This would
>> introduce a discontinuity in a**b that could cause problems in some
>> cases. If, for instance, one were running an iterative solver of
>> some sort (something I've been known to do), and b was a free
>> variable, it could get stuck at b = 2 since things would go
>> nonmonotonic there.
>
> I don't quite understand the problem here. Tim says Python special
> cases integer powers but then talks about the problem when b is a
> floating type. I think special casing x**2 and maybe even x**3 when
> the power is an integer is still a good idea.

Well, what I had done with Numeric did special case x**0, x**1,
x**(-1), x**0.5, x**2, x**3, x**4, and x**5, and only when the
exponent was a scalar (so x**y where y was an array wouldn't be). I
think this is very useful, as I don't want to microoptimize my code to
x*x instead of x**2. The reason for just scalar exponents was so
choosing how to do the power was lifted out of the inner loop. With
that, x**2 was as fast as x*x.

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

Re: [Numpy-discussion] number ranges (was Re: Matlab page on scipy wiki)

[Colin J. W. <cj...@sy...>]

Tim Hochberg wrote:

> Bill Baxter wrote:
>
>> On 2/11/06, *Gary Ruben* <gr...@bi... 
>> <mailto:gr...@bi...>> wrote:
>>
>>     Sasha wrote:
>>     > On 2/10/06, Gary Ruben <gr...@bi...
>>     <mailto:gr...@bi...>> wrote:
>>     >> ...  I must say that Travis's
>>     >> example numpy.r_[1,0,1:5,0,1] highlights my pet hate with
>>     python - that
>>     >> the upper limit on an integer range is non-inclusive.
>>     >
>>     > In this case you must hate that an integer range starts at 0 (I
>>     don't
>>     > think you would want len(range(10)) to be 11).
>>
>>
>> First, I think the range() function in python is ugly to begin with.  
>> Why can't python just support range notation directly like 'for a in 
>> 0:10'.  Or with 0..10 or 0...10 syntax.  That seems to make a lot 
>> more sense to me than having to call a named function.   Anyway, 
>> that's a python pet peeve, and python's probably not going to change 
>> something so fundamental...
>>
>> Second, sometimes zero-based, non-inclusive ranges are handy, and 
>> sometimes one-based inclusive ranges are handy.  For array indexing, 
>> I personally like zero based.  But sometimes I just want a list of N 
>> numbers like a human would write it, from 1 to N, and in those cases 
>> it seems really odd for N+1 to show up.
>>
>> This is a place where numpy could do something.  I think it would be 
>> nice if numpy had something like an 'irange' (inclusive range) 
>> function to complement the 'arange' function.  They would act pretty 
>> much the same, except irange(5) would return [1,2,3,4,5], and 
>> irange(1,5) would return [1,2,3,4,5].
>>
>> Anyway, I think I'm going to put a little irange function in my setup. 
>
>
>
> FWIW, I'd recomend a different name. irange sounds like it belongs in 
> the itertools module with ifilter, islice, izip, etc. Perhaps, rangei 
> would work, although admittedly it's harder to see. Maybe crange for 
> closed range (versus half-open range)? I dunno, but irange seems like 
> it's gonna confuse someone, if not you, then other people who end up 
> looking at your code.
>
> -tim

Wouldn't it be nice if we could express range(a, b, c) as a:b:c?

Colin W.

Re: [Numpy-discussion] More numpy and Numeric differences

[Colin J. W. <cj...@sy...>]

Travis Oliphant wrote:

> Pearu Peterson wrote:
>
>>
>> I have created a wiki page
>>
>>   http://scipy.org/PearuPeterson/NumpyVersusNumeric
>>
>> that reports my findings on how numpy and Numeric behave on various 
>> corner cases. Travis O., could you take a look at it?
>> Here is the most recent addition:
>>
> I fixed the put issue.  The problem with clip is actually in choose 
> (clip is just a specific application of  choose).
> The problem is in PyArray_ConvertToCommonType.  You have an integer 
> array, an integer scalar, and a floating-point scalar.
> I think the rules implemented in PyArray_ConvertToCommonType are not 
> allowing the scalar to dictate anything.  But, this should clearly be 
> changed to allow scalars of different "kinds" to up-cast the array.  
> This would be consistent with the umath module.
>
> So, PyArray_ConvertToCommonType needs to be improved.  This will have 
> an impact on several other functions that use this C-API.
>
> -Travis
>
A numarray vs numpy would be helpful for some of us.

Colin W.

Re: [Numpy-discussion] dtype names and titles

[Colin J. W. <cj...@sy...>]

Travis Oliphant wrote:

> N. Volbers wrote:
>
>> I continue to learn all about the heterogeneous arrays...
>>
>> When I was reading through the records.py code I discovered that 
>> besides the 'names' and 'formats' for the fields of a numpy array you 
>> can also specify 'titles'. Playing around with this feature I 
>> discovered a bug:
>>
>> >>> import numpy
>> >>> mydata = [(1,1), (2,4), (3,9)]
>> >>> mytype = {'names': ['col1','col2'], 'formats':['i2','f4'], 
>> 'titles': ['col2', 'col1']}
>> >>> b = numpy.array( mydata, dtype=mytype)
>> >>> print b
>> [(1.0, 1.0) (4.0, 4.0) (9.0, 9.0)]
>>
>> This seems to be caused by the fact that you can access a field by 
>> both the name and the field title. Why would you want to have two 
>> names anyway?
>
>
> This lets you use attribute look up on the names but have the titles 
> be the "true name" of the field.

Isn't it better to use the name as the identifier and the title as an 
external label? e.g. As a column heading when pretty-printing.

It seems to me that permitting either the name or the title as an object 
accessor is potentially confusing.

Colin W.

>
> I've fixed this in SVN, so that it raises an error when the titles 
> have the same names as the columns.
>
> Thanks for the test.
>
>
> -Travis
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Matlab page on scipy wiki

[Colin J. W. <cj...@sy...>]

Sasha wrote:

>Actually, what would be wrong with a single letter "c" or "r" for the
>concatenator?  NumPy already has one single-letter global identifier -
>"e", so it will not be against any naming standard.  I don't think
>either "c" or "r" will conflict with anything in the standard library.
> I would still prefer "c" because "r" is taken by RPy.
>  
>
It seems to me that a single letter would only be appropriate for a a 
function which has a very high frequency of use. I used M for the matrix 
constructor for my numarray based package.

Why not rowCat for row catenate or colCat for column catentate - I've 
never understood why concatentate is used more commonly.

Colin W.

>
>On 2/10/06, Sasha <nd...@ma...> wrote:
>  
>
>>To tell you the truth I dislike trailing underscore much more than the
>>choice of letter.  In my code I will probably be renaming all these
>>foo_ to delete the underscore foo_(...) or foo_[...] is way too ugly
>>for my taste.  However I fully admit that it is just a matter of taste
>>and it is trivial to rename things on import in Python.
>>
>>PS: Trailing underscore reminds me of C++ - the language that I
>>happily live without :-)
>>
>>On 2/10/06, Ryan Krauss <rya...@gm...> wrote:
>>    
>>
>>>The problem is that c_ at least used to mean "column concatenate" and
>>>concatenate is too long to type.
>>>
>>>On 2/10/06, Sasha <nd...@ma...> wrote:
>>>      
>>>
>>>>On 2/10/06, Travis Oliphant <oli...@ee...> wrote:
>>>>        
>>>>
>>>>>The whole point of r_ is to allow you to use slice notation to build
>>>>>ranges easily.  I wrote it precisely to make it easier to construct
>>>>>arrays in a simliar style that Matlab allows.
>>>>>          
>>>>>
>>>>Maybe it is just me, but r_ is rather unintuitive.  I would expect
>>>>something like this to be called "c" for "combine" or "concatenate."
>>>>This is the name used by S+ and R.
>>>>
>>>>From R manual:
>>>>"""
>>>>c                    package:base                    R Documentation
>>>>Combine Values into a Vector or List
>>>>...
>>>>Examples:
>>>>     c(1,7:9)
>>>>...
>>>>"""
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>>>for problems?  Stop!  Download the new AJAX search engine that makes
>>>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>>>http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
>>>>_______________________________________________
>>>>Numpy-discussion mailing list
>>>>Num...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>>>
>>>>        
>>>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
>_______________________________________________
>Numpy-discussion mailing list
>Num...@li...
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>  
>

Re: [Numpy-discussion] number ranges

[John H. <jdh...@ac...>]

>>>>> "Bill" == Bill Baxter <wb...@gm...> writes:
    Bill> This is a place where numpy could do something.  I think it
    Bill> would be nice if numpy had something like an 'irange'
    Bill> (inclusive range) function to complement the 'arange'

In my view, this goes a bit against the spirit of the Zen of python
('import this')

  There should be one -- and preferably only one -- obvious way to do
  it.

since there is an obvious way to get the range 1..6.

JDH

Re: [Numpy-discussion] number ranges (was Re: Matlab page on scipy wiki)

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

Bill Baxter wrote:

> On 2/11/06, *Gary Ruben* <gr...@bi... 
> <mailto:gr...@bi...>> wrote:
>
>     Sasha wrote:
>     > On 2/10/06, Gary Ruben <gr...@bi...
>     <mailto:gr...@bi...>> wrote:
>     >> ...  I must say that Travis's
>     >> example numpy.r_[1,0,1:5,0,1] highlights my pet hate with
>     python - that
>     >> the upper limit on an integer range is non-inclusive.
>     >
>     > In this case you must hate that an integer range starts at 0 (I
>     don't
>     > think you would want len(range(10)) to be 11).
>
>
> First, I think the range() function in python is ugly to begin with.  
> Why can't python just support range notation directly like 'for a in 
> 0:10'.  Or with 0..10 or 0...10 syntax.  That seems to make a lot more 
> sense to me than having to call a named function.   Anyway, that's a 
> python pet peeve, and python's probably not going to change something 
> so fundamental...
>
> Second, sometimes zero-based, non-inclusive ranges are handy, and 
> sometimes one-based inclusive ranges are handy.  For array indexing, I 
> personally like zero based.  But sometimes I just want a list of N 
> numbers like a human would write it, from 1 to N, and in those cases 
> it seems really odd for N+1 to show up.
>
> This is a place where numpy could do something.  I think it would be 
> nice if numpy had something like an 'irange' (inclusive range) 
> function to complement the 'arange' function.  They would act pretty 
> much the same, except irange(5) would return [1,2,3,4,5], and 
> irange(1,5) would return [1,2,3,4,5].
>
> Anyway, I think I'm going to put a little irange function in my setup. 


FWIW, I'd recomend a different name. irange sounds like it belongs in 
the itertools module with ifilter, islice, izip, etc. Perhaps, rangei 
would work, although admittedly it's harder to see. Maybe crange for 
closed range (versus half-open range)? I dunno, but irange seems like 
it's gonna confuse someone, if not you, then other people who end up 
looking at your code.

-tim

[Numpy-discussion] number ranges (was Re: Matlab page on scipy wiki)

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

On 2/11/06, Gary Ruben <gr...@bi...> wrote:
>
> Sasha wrote:
> > On 2/10/06, Gary Ruben <gr...@bi...> wrote:
> >> ...  I must say that Travis's
> >> example numpy.r_[1,0,1:5,0,1] highlights my pet hate with python - tha=
t
> >> the upper limit on an integer range is non-inclusive.
> >
> > In this case you must hate that an integer range starts at 0 (I don't
> > think you would want len(range(10)) to be 11).


First, I think the range() function in python is ugly to begin with.  Why
can't python just support range notation directly like 'for a in 0:10'.  Or
with 0..10 or 0...10 syntax.  That seems to make a lot more sense to me tha=
n
having to call a named function.   Anyway, that's a python pet peeve, and
python's probably not going to change something so fundamental...

Second, sometimes zero-based, non-inclusive ranges are handy, and sometimes
one-based inclusive ranges are handy.  For array indexing, I personally lik=
e
zero based.  But sometimes I just want a list of N numbers like a human
would write it, from 1 to N, and in those cases it seems really odd for N+1
to show up.

This is a place where numpy could do something.  I think it would be nice i=
f
numpy had something like an 'irange' (inclusive range) function to
complement the 'arange' function.  They would act pretty much the same,
except irange(5) would return [1,2,3,4,5], and irange(1,5) would return
[1,2,3,4,5].

Anyway, I think I'm going to put a little irange function in my setup.

--Bill

Re: [Numpy-discussion] avoiding the matrix copy performance hit

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

On 2/14/06, Tim Hochberg <tim...@co...> wrote:
>
> Bill Baxter wrote:
>
> > *Copying all the data of the input array seems wasteful when the array
> > is just going to go out of scope.  Or is this not something to be
> > concerned about?
>
> You could try using copy=3DFalse:


Lovely.  That does the trick.  And the syntax isn't so bad after defining a
little helper like:

   def matr(a): return mat(a,copy=3DFalse)


>>> t1.timeit(100)
> 3.6538127052460578
> >>> t2.timeit(100)
> 3.6567186611706237
>
> I'd also like to point out that your computer appears to be much faster
> than mine.



Duly noted.  :-)


-tim



--Bill

Re: [Numpy-discussion] Re: indexing problem

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

Tim Hochberg wrote:
<snip>
> However, I'm not convinced this is a good idea for numpy. This would 
> introduce a discontinuity in a**b that could cause problems in some 
> cases. If, for instance, one were running an iterative solver of some 
> sort (something I've been known to do), and b was a free variable, it 
> could get stuck at b = 2 since things would go nonmonotonic there.

I don't quite understand the problem here. Tim says Python special cases 
integer powers but then talks about the problem when b is a floating 
type. I think special casing x**2 and maybe even x**3 when the power is 
an integer is still a good idea.

Gary R.

Re: [Numpy-discussion] avoiding the matrix copy performance hit

[Ryan K. <rya...@gm...>]

You both seem to have cooler computers than I do:

In [19]: t1.timeit(100)
Out[19]: 4.9827449321746826

In [20]: t2.timeit(100)
Out[20]: 4.9990239143371582


On 2/13/06, Tim Hochberg <tim...@co...> wrote:
> Bill Baxter wrote:
>
> > Is there anyway to get around this timing difference?
> > *
> >   >>> import timeit
> > **  >>> t1 =3D timeit.Timer("a =3D zeros((1000,1000),'d'); a +=3D 1.;",
> > 'from numpy import zeros,mat')
> > **  >>> t2 =3D timeit.Timer("a =3D mat(zeros((1000,1000),'d')); a +=3D
> > 1.;",  'from numpy import zeros,mat')
> >   >>> **t1.timeit(100)
> >   1.8391627591141742
> >   >>> t2.timeit(100)
> >   3.2988266117713465
> >
> > *Copying all the data of the input array seems wasteful when the array
> > is just going to go out of scope.  Or is this not something to be
> > concerned about?
>
> You could try using copy=3DFalse:
>
>  >>> import timeit
>  >>> t1 =3D timeit.Timer("a =3D zeros((1000,1000),'d'); a +=3D 1.;",  'fr=
om
> numpy import zeros,mat')
>  >>> t2 =3D timeit.Timer("a =3D mat(zeros((1000,1000),'d'), copy=3DFalse)=
; a
> +=3D 1.;",  'from numpy import z
> eros,mat')
>  >>> t1.timeit(100)
> 3.6538127052460578
>  >>> t2.timeit(100)
> 3.6567186611706237
>
> I'd also like to point out that your computer appears to be much faster
> than mine.
>
> -tim
>
>
> >
> > It seems like a copy-by-reference version of mat() would be useful.
> > Really I can't imagine any case when I'd want both a matrix and the
> > original version of the array both hanging around as separate copies.
> > I can imagine either 1) the array is just a temp and I won't ever need
> > it again or 2) temporarily wanting a "matrix view" on the array's data
> > to do some linalg, after which I'll go back to using the original (now
> > modified) array as an array again.
> >
> > --bill
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Re: indexing problem

[Ryan K. <rya...@gm...>]

I agree.  I already made that change in my code.

Ryan

On 2/13/06, Tim Hochberg <tim...@co...> wrote:
> David M. Cooke wrote:
>
> >Tim Hochberg <tim...@co...> writes:
> >
> >
> >
> >>Ryan Krauss wrote:
> >>
> >>
> >>
> >>>At the risk of sounding silly, can you explain to me in simple terms
> >>>why s**2 is less accurate than s*s.  I can sort of intuitively
> >>>appreciate that that would be true, but but might like just a little
> >>>more detail.
> >>>
> >>>
> >>>
> >>>
> >>I don't know that it has to be *less* accurate, although it's unlikely
> >>to be more accurate since s*s should be nearly as accurate as you get
> >>with floating point. Multiplying two complex numbers in numpy is done
> >>in the most straightforward way imaginable:
> >>
> >>   result.real    =3D z1.real*z2.real - z1.imag*z2.imag
> >>   result.image =3D z1.real*z2.imag + z1.imag*z2.real
> >>
> >>The individual results lose very little precision and the overall
> >>result will be nearly exact to within the limits of floating point.
> >>
> >>On the other hand, s**2 is being calculated by a completely different
> >>route. Something that will look like:
> >>
> >>   result =3D pow(s, 2.0)
> >>
> >>Pow is some general function that computes the value of s to any
> >>power. As such it's a lot more complicated than the above simple
> >>expression. I don't think that there's any reason in principle that
> >>pow(s,2) couldn't be as accurate as s*s, but there is a tradeoff
> >>between accuracy, speed and simplicity of implementation.
> >>
> >>
> >
> >On a close tangent, I had a patch at one point for Numeric (never
> >committed) that did pow(s, 2.0) (=3D s**2) actually as s*s at the C leve=
l (no
> >pow), which helped a lot in speed (currently, s**2 is slower than s*s).
> >
> >I should have another look at that. The difference is speed is pretty
> >bad: for an array of 100 complex elements, s**2 is 68.4 usec/loop as
> >opposed to s*s with 4.13 usec/loop on my machine.
> >
> >
> Python's complex object also special cases integer powers. Which is why
> you won't see the inaccuracy that started this thread using basic
> complex objects.
>
> However, I'm not convinced this is a good idea for numpy. This would
> introduce a discontinuity in a**b that could cause problems in some
> cases. If, for instance, one were running an iterative solver of some
> sort (something I've been known to do), and b was a free variable, it
> could get stuck at b =3D 2 since things would go nonmonotonic there. I
> would recomend that we just prominently document that x*x is faster and
> more accurate than x**2 and that people should use x*x where that's a
> concern.
>
> -tim
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Re: indexing problem

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

David M. Cooke wrote:

>Tim Hochberg <tim...@co...> writes:
>
>  
>
>>Ryan Krauss wrote:
>>
>>    
>>
>>>At the risk of sounding silly, can you explain to me in simple terms
>>>why s**2 is less accurate than s*s.  I can sort of intuitively
>>>appreciate that that would be true, but but might like just a little
>>>more detail.
>>>
>>>
>>>      
>>>
>>I don't know that it has to be *less* accurate, although it's unlikely
>>to be more accurate since s*s should be nearly as accurate as you get
>>with floating point. Multiplying two complex numbers in numpy is done
>>in the most straightforward way imaginable:
>>
>>   result.real    = z1.real*z2.real - z1.imag*z2.imag
>>   result.image = z1.real*z2.imag + z1.imag*z2.real
>>
>>The individual results lose very little precision and the overall
>>result will be nearly exact to within the limits of floating point.
>>
>>On the other hand, s**2 is being calculated by a completely different
>>route. Something that will look like:
>>
>>   result = pow(s, 2.0)
>>
>>Pow is some general function that computes the value of s to any
>>power. As such it's a lot more complicated than the above simple
>>expression. I don't think that there's any reason in principle that
>>pow(s,2) couldn't be as accurate as s*s, but there is a tradeoff
>>between accuracy, speed and simplicity of implementation.
>>    
>>
>
>On a close tangent, I had a patch at one point for Numeric (never
>committed) that did pow(s, 2.0) (= s**2) actually as s*s at the C level (no
>pow), which helped a lot in speed (currently, s**2 is slower than s*s).
>
>I should have another look at that. The difference is speed is pretty
>bad: for an array of 100 complex elements, s**2 is 68.4 usec/loop as
>opposed to s*s with 4.13 usec/loop on my machine.
>  
>
Python's complex object also special cases integer powers. Which is why 
you won't see the inaccuracy that started this thread using basic 
complex objects.

However, I'm not convinced this is a good idea for numpy. This would 
introduce a discontinuity in a**b that could cause problems in some 
cases. If, for instance, one were running an iterative solver of some 
sort (something I've been known to do), and b was a free variable, it 
could get stuck at b = 2 since things would go nonmonotonic there. I 
would recomend that we just prominently document that x*x is faster and 
more accurate than x**2 and that people should use x*x where that's a 
concern.

-tim

Re: [Numpy-discussion] avoiding the matrix copy performance hit

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

Bill Baxter wrote:

> Is there anyway to get around this timing difference?
> *
>   >>> import timeit
> **  >>> t1 = timeit.Timer("a = zeros((1000,1000),'d'); a += 1.;",  
> 'from numpy import zeros,mat')
> **  >>> t2 = timeit.Timer("a = mat(zeros((1000,1000),'d')); a += 
> 1.;",  'from numpy import zeros,mat')
>   >>> **t1.timeit(100)
>   1.8391627591141742
>   >>> t2.timeit(100)
>   3.2988266117713465
>
> *Copying all the data of the input array seems wasteful when the array 
> is just going to go out of scope.  Or is this not something to be 
> concerned about? 

You could try using copy=False:

 >>> import timeit
 >>> t1 = timeit.Timer("a = zeros((1000,1000),'d'); a += 1.;",  'from 
numpy import zeros,mat')
 >>> t2 = timeit.Timer("a = mat(zeros((1000,1000),'d'), copy=False); a 
+= 1.;",  'from numpy import z
eros,mat')
 >>> t1.timeit(100)
3.6538127052460578
 >>> t2.timeit(100)
3.6567186611706237

I'd also like to point out that your computer appears to be much faster 
than mine.

-tim


>
> It seems like a copy-by-reference version of mat() would be useful.  
> Really I can't imagine any case when I'd want both a matrix and the 
> original version of the array both hanging around as separate copies.  
> I can imagine either 1) the array is just a temp and I won't ever need 
> it again or 2) temporarily wanting a "matrix view" on the array's data 
> to do some linalg, after which I'll go back to using the original (now 
> modified) array as an array again.
>
> --bill

[Numpy-discussion] avoiding the matrix copy performance hit

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

Is there anyway to get around this timing difference?
*
  >>> import timeit
**  >>> t1 =3D timeit.Timer("a =3D zeros((1000,1000),'d'); a +=3D 1.;",  'f=
rom
numpy import zeros,mat')
**  >>> t2 =3D timeit.Timer("a =3D mat(zeros((1000,1000),'d')); a +=3D 1.;"=
,
'from numpy import zeros,mat')
  >>> **t1.timeit(100)
  1.8391627591141742
  >>> t2.timeit(100)
  3.2988266117713465

*Copying all the data of the input array seems wasteful when the array is
just going to go out of scope.  Or is this not something to be concerned
about?

It seems like a copy-by-reference version of mat() would be useful.  Really
I can't imagine any case when I'd want both a matrix and the original
version of the array both hanging around as separate copies.  I can imagine
either 1) the array is just a temp and I won't ever need it again or 2)
temporarily wanting a "matrix view" on the array's data to do some linalg,
after which I'll go back to using the original (now modified) array as an
array again.

--bill

Re: [Numpy-discussion] Re: indexing problem

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

Tim Hochberg wrote:

> Ryan Krauss wrote:
>
>> At the risk of sounding silly, can you explain to me in simple terms
>> why s**2 is less accurate than s*s.  I can sort of intuitively
>> appreciate that that would be true, but but might like just a little
>> more detail.
>>  
>>
> I don't know that it has to be *less* accurate, although it's unlikely 
> to be more accurate since s*s should be nearly as accurate as you get 
> with floating point. Multiplying two complex numbers in numpy is done 
> in the most straightforward way imaginable:
>
>    result.real    = z1.real*z2.real - z1.imag*z2.imag
>    result.image = z1.real*z2.imag + z1.imag*z2.real
>
> The individual results lose very little precision and the overall 
> result will be nearly exact to within the limits of floating point.
>
> On the other hand, s**2 is being calculated by a completely different 
> route. Something that will look like:
>
>    result = pow(s, 2.0)
>
> Pow is some general function that computes the value of s to any 
> power. As such it's a lot more complicated than the above simple 
> expression. I don't think that there's any reason in principle that 
> pow(s,2) couldn't be as accurate as s*s, but there is a tradeoff 
> between accuracy, speed and simplicity of implementation.
>
> That being said, it may be worthwhile having a look at complex pow and 
> see if there's anything suspicious that might make the error larger 
> than it needs to be.
>
> If all of that sounds a little bit like "I really know", there's some 
> of that in there too.


To add a little more detail to this, the formula that numpy uses to 
compute a**b is:

    exp(b*log(a))

where:

    log(x) = log(|x|) + arctan2(x.imag, x,real)
    exp(x) = exp(x.real) * (cos(x.imag) + 1j*sin(x.imag))

With these definitions in hand, it should be apparent what's happening 
when *a* = |a|j and *b* = 2. First, let's compute 2*log(a) for *a* = 
24674.011002723393j:

   2*log(a) = (20.227011565110185+3.1415926535897931j)
  
Now it's clear what's happening: ideally the sine of the imaginary part 
of the above number should be zero. However:

  sin(3.1415926535897931) = 1.2246063538223773e-016

And this in turn leads to the error we see here.

-tim


>
> Regards,
>
> -tim
>
>
>> Thanks,
>>
>> Ryan
>>
>> On 2/13/06, Tim Hochberg <tim...@co...> wrote:
>>  
>>
>>>>> Ryan Krauss wrote:
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>> This may only be a problem for ridiculously large numbers.  I 
>>>>>> actually
>>>>>> meant to be dealing with these values:
>>>>>>
>>>>>> In [75]: d
>>>>>> Out[75]:
>>>>>> array([   246.74011003,    986.96044011,   2220.66099025,   
>>>>>> 3947.84176044,
>>>>>>       6168.50275068,   8882.64396098,  12090.26539133,  
>>>>>> 15791.36704174,
>>>>>>      19985.94891221,  24674.01100272])
>>>>>>
>>>>>> In [76]: s=d[-1]*1.0j
>>>>>>
>>>>>> In [77]: s
>>>>>> Out[77]: 24674.011002723393j
>>>>>>
>>>>>> In [78]: type(s)
>>>>>> Out[78]: <type 'complex128scalar'>
>>>>>>
>>>>>> In [79]: s**2
>>>>>> Out[79]: (-608806818.96251547+7.4554869875188623e-08j)
>>>>>>
>>>>>> So perhaps the previous difference of 26 orders of magnitude really
>>>>>> did mean that the imaginary part was negligibly small, that just got
>>>>>> obscured by the fact that the real part was order 1e+135.
>>>>>>
>>>>>> On 2/13/06, Ryan Krauss <rya...@gm...> wrote:
>>>>>>
>>>>>>
>>>>>>         
>>>>>
>>> I got myself all tied up in a knot over this because I couldn't figure
>>> out how multiplying two purely complex numbers was going to result in
>>> something with a complex portion. Since I couldn't find the complex
>>> routines my imagination went wild: perhaps, I thought, numpy uses the
>>> complex multiplication routine that uses 3 multiplies instead of the
>>> more straightforward one that uses 4 multiples, etc, etc. None of these
>>> panned out, and of course they all evaporated when I got pointed to the
>>> code that implements this which is pure vanilla.  All the time I was
>>> overlooking the obvious:
>>>
>>> Ryan is using s**2, not s*s.
>>>
>>> So the obvious answer, is that he's just seeing normal error in the
>>> function that is implementing pow.
>>>
>>> If this is inacuracy is problem, I'd just replace s**2 with s*s. It 
>>> will
>>> probably be both faster and more accurate anyway
>>>
>>> Foolishly,
>>>
>>> -tim
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc. Do you grep through 
>>> log files
>>> for problems?  Stop!  Download the new AJAX search engine that makes
>>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 
>>>
>>> _______________________________________________
>>> Numpy-discussion mailing list
>>> Num...@li...
>>> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>>
>>>   
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through 
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
>> _______________________________________________
>> Numpy-discussion mailing list
>> Num...@li...
>> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>
>>
>>  
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>

Re: [Numpy-discussion] NumPy Glossary: a request for review

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

On 2/13/06, Christopher Barker <Chr...@no...> wrote:
> Then a wiki page on broadcasting may be in order, and the glossary could
> link to it.

I don't think a glossary should link to anything.  I envisioned the
glossary as a way to resolve ambiguities for people who already know
more than one meaning of the terms.

However, if others think a link to more detailed explanation belongs
to glossary entries, the natural destination of the link would be a
page in Travis' book.  Travis, can you suggest a future-proof way to
refer to a page in your book?

Re: [Numpy-discussion] matplotlib

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

Sorry, I wasn't very clear.  My thinking was like this:
- matplotlib web pages don't mention support for numpy anywhere, just
numeric and numarray
- matplotlib web page says that the default is to use numeric
- numpy is basically the successor to numeric plus numarray functionality

- conclusion: if matplotlib actually does support numpy, and the web pages
are just out of date, then probably numpy would now be the default instead
of numeric, since it is the successor to numeric.

But apparently there's a flaw in that thinking somewhere.

--bb

On 2/14/06, Ryan Krauss <rya...@gm...> wrote:
>
> The point of the numerix setting in the rc file is that matplotlib
> can't tell you what is the best numerical package to use for your
> problem.
>
> On 2/13/06, Bill Baxter <wb...@gm...> wrote:
> > Ah, ok.  You're right.  Doing from pylab import * was actually just
> > overwriting the definition of array and rand() to be those from Numeric=
,
> > which pylab was picking to use by default.   I guess my expectation was
> that
> > pylab would default to using the best numerical package installed.
> >
> > With "numerix : numpy" in my ~/.matplotlib/matplotlibrc file, it seems
> to be
> > working properly now.
> >
> > Thanks for the help!
> >
> > --bb
> >
> > On 2/14/06, John Hunter <jdh...@ac...> wrote:
> > > >>>>> "Bill" =3D=3D Bill Baxter <wb...@gm...> writes:
> > >
> > >     Bill> from numpy import * was the only line missing, called befor=
e
> > >     Bill> the rest.  It seems to work fine if I use from pylab import
> > >     Bill> * instead of import pylab as g
> > >
> > >     Bill> And actually if I do both in this order: import pylab as g
> > >     Bill> from pylab import *
> > >
> > >     Bill> Seems as if there's some
> > >     Bill> initialization code that only gets run with the 'from pylab
> > >     Bill> import *' version.
> > >
> > > As far as I know that is a python impossibility, unless perhaps you d=
o
> > > some deep dark magic that is beyond my grasp.  pylab doesn't know how
> > > it is imported.
> > >
> > > Are you sure you have your numerix set properly?  I suggest creating
> > > two free standing scripts, one with the problem and one without, and
> > > running both with --verbose-helpful to make sure that your settings
> > > are what you think they are.  If you verify that numerix is set
> > > properly and still see the problem, I would like to see both scripts
> > > in case it is exposing a problem with matplotlib.
> > >
> > > Of course, doing multiple import * commands is a recipe for long term
> > > pain, especially with packages that have so much overlapping namespac=
e
> > > and numpy/scipy/pylab.
> > >
> > > JDH
> > >
> >
> >
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>



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

[Numpy-discussion] Re: ***[Possible UCE]*** Test units on unicode types

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

Francesc Altet wrote:

>Hi Travis,
>
>I've finished a series of tests on your recent new implementation of
>unicode types in NumPy. They discovered a couple of issues in Numpy: one
>is clearly a bug that show up in UCS2 builds (see the patch attached).
>The other, well, it is not clear to me if it is a bug or not:
>  
>

Thanks very much for these tests...  They are very, very useful.

I recently realized that the getitem material must make copies for 
misaligned data because the convert to UCS2 functions expect aligned 
data (on Solaris anyway it would cause a segfault). 

You caught an obvious mistake in that code.


>>>>ia1=numpy.array([1])
>>>>type(ia1)
>>>>        
>>>>
><type 'numpy.ndarray'>
>  
>
>>>>type(ia1.view())
>>>>        
>>>>
><type 'numpy.ndarray'>
>
>However, for 0-dimensional arrays:
>
>  
>
>>>ia0=numpy.array(1)
>>>type(ia0)
>>>      
>>>
Francesc Altet wrote:

>>>type(ia0.view())
>>>      
>>>
<type 'int32scalar'>  !!!!!!

Do you think the next this is a bug or a feature? My opinion is that it
is a bug, but maybe I'm wrong. In fact, this has a very bad effect on
unicode objects in UCS2 interpreters:



Almost all of the methods right now, return scalars instead of 
0-dimensional arrays on purpose.   This was intentional because 
0-dimensional arrays were not supposed to be handed around in Python.  
But, we were unable to completely eliminate them at this point.  So, I 
suppose, though there are a select few methods that should not 
automatically convert 0-dimensional arrays to the equivalent scalar.

.copy()  is one of them  *already changed*
.view()  is probably another *should be changed*.

If you can think of other methods that should not return scalars instead 
of 0-dimensional arrays, post it.


-Travis

Re: [Numpy-discussion] Re: indexing problem

[<co...@ph...>]

Tim Hochberg <tim...@co...> writes:

> Ryan Krauss wrote:
>
>>At the risk of sounding silly, can you explain to me in simple terms
>>why s**2 is less accurate than s*s.  I can sort of intuitively
>>appreciate that that would be true, but but might like just a little
>>more detail.
>>
>>
> I don't know that it has to be *less* accurate, although it's unlikely
> to be more accurate since s*s should be nearly as accurate as you get
> with floating point. Multiplying two complex numbers in numpy is done
> in the most straightforward way imaginable:
>
>    result.real    = z1.real*z2.real - z1.imag*z2.imag
>    result.image = z1.real*z2.imag + z1.imag*z2.real
>
> The individual results lose very little precision and the overall
> result will be nearly exact to within the limits of floating point.
>
> On the other hand, s**2 is being calculated by a completely different
> route. Something that will look like:
>
>    result = pow(s, 2.0)
>
> Pow is some general function that computes the value of s to any
> power. As such it's a lot more complicated than the above simple
> expression. I don't think that there's any reason in principle that
> pow(s,2) couldn't be as accurate as s*s, but there is a tradeoff
> between accuracy, speed and simplicity of implementation.

On a close tangent, I had a patch at one point for Numeric (never
committed) that did pow(s, 2.0) (= s**2) actually as s*s at the C level (no
pow), which helped a lot in speed (currently, s**2 is slower than s*s).

I should have another look at that. The difference is speed is pretty
bad: for an array of 100 complex elements, s**2 is 68.4 usec/loop as
opposed to s*s with 4.13 usec/loop on my machine.

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

Re: [Numpy-discussion] Re: indexing problem

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

Ryan Krauss wrote:

>At the risk of sounding silly, can you explain to me in simple terms
>why s**2 is less accurate than s*s.  I can sort of intuitively
>appreciate that that would be true, but but might like just a little
>more detail.
>  
>
I don't know that it has to be *less* accurate, although it's unlikely 
to be more accurate since s*s should be nearly as accurate as you get 
with floating point. Multiplying two complex numbers in numpy is done in 
the most straightforward way imaginable:

    result.real    = z1.real*z2.real - z1.imag*z2.imag
    result.image = z1.real*z2.imag + z1.imag*z2.real

The individual results lose very little precision and the overall result 
will be nearly exact to within the limits of floating point.

On the other hand, s**2 is being calculated by a completely different 
route. Something that will look like:

    result = pow(s, 2.0)

Pow is some general function that computes the value of s to any power. 
As such it's a lot more complicated than the above simple expression. I 
don't think that there's any reason in principle that pow(s,2) couldn't 
be as accurate as s*s, but there is a tradeoff between accuracy, speed 
and simplicity of implementation.

That being said, it may be worthwhile having a look at complex pow and 
see if there's anything suspicious that might make the error larger than 
it needs to be.

If all of that sounds a little bit like "I really know", there's some of 
that in there too.

Regards,

-tim


>Thanks,
>
>Ryan
>
>On 2/13/06, Tim Hochberg <tim...@co...> wrote:
>  
>
>>>>Ryan Krauss wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>This may only be a problem for ridiculously large numbers.  I actually
>>>>>meant to be dealing with these values:
>>>>>
>>>>>In [75]: d
>>>>>Out[75]:
>>>>>array([   246.74011003,    986.96044011,   2220.66099025,   3947.84176044,
>>>>>       6168.50275068,   8882.64396098,  12090.26539133,  15791.36704174,
>>>>>      19985.94891221,  24674.01100272])
>>>>>
>>>>>In [76]: s=d[-1]*1.0j
>>>>>
>>>>>In [77]: s
>>>>>Out[77]: 24674.011002723393j
>>>>>
>>>>>In [78]: type(s)
>>>>>Out[78]: <type 'complex128scalar'>
>>>>>
>>>>>In [79]: s**2
>>>>>Out[79]: (-608806818.96251547+7.4554869875188623e-08j)
>>>>>
>>>>>So perhaps the previous difference of 26 orders of magnitude really
>>>>>did mean that the imaginary part was negligibly small, that just got
>>>>>obscured by the fact that the real part was order 1e+135.
>>>>>
>>>>>On 2/13/06, Ryan Krauss <rya...@gm...> wrote:
>>>>>
>>>>>
>>>>>          
>>>>>
>>I got myself all tied up in a knot over this because I couldn't figure
>>out how multiplying two purely complex numbers was going to result in
>>something with a complex portion. Since I couldn't find the complex
>>routines my imagination went wild: perhaps, I thought, numpy uses the
>>complex multiplication routine that uses 3 multiplies instead of the
>>more straightforward one that uses 4 multiples, etc, etc. None of these
>>panned out, and of course they all evaporated when I got pointed to the
>>code that implements this which is pure vanilla.  All the time I was
>>overlooking the obvious:
>>
>>Ryan is using s**2, not s*s.
>>
>>So the obvious answer, is that he's just seeing normal error in the
>>function that is implementing pow.
>>
>>If this is inacuracy is problem, I'd just replace s**2 with s*s. It will
>>probably be both faster and more accurate anyway
>>
>>Foolishly,
>>
>>-tim
>>
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>>for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>>_______________________________________________
>>Numpy-discussion mailing list
>>Num...@li...
>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
>_______________________________________________
>Numpy-discussion mailing list
>Num...@li...
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>  
>