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

[Numpy-discussion] Segmentation fault when dealing with nested records

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

Hi,

I'm starting to write a series of torture test for numpy and (nested)
heterogeneous arrays. I've found a first problem that causes a
segfault:

In [7]: dtype=3D[('x', '<i4', (2,)), ('Info', [('value', '<c16'), ('y2', '<=
f8'),=20
('Info2', [('name', '|S2'), ('value', '<c16', (2,)), ('y3', '<f8', (2,)),=20
('z3', '<u4', (2,))]), ('name', '|S2'), ('z2', '|u1')]), ('color', '|S2'),=
=20
('info', [('Name', '|S2'), ('Value', '<c16')]), ('y', '<f8', (2, 2)), ('z',=
=20
'|u1')]

In [9]: a=3Dnumpy.zeros((2,), dtype=3Ddtype)

In [10]: a
Out[10]:
array([ (array([0, 0]), (0j, 0.0, ('', array([ 0.+0.j,  0.+0.j]), array([ 0=
=2E, =20
0.]), array([0, 0], dtype=3Duint32)), '', 0), '', ('', 0j), array([[ 0.,  0=
=2E],
       [ 0.,  0.]]), 0),
       (array([0, 0]), (0j, 0.0, ('', array([ 0.+0.j,  0.+0.j]), array([ 0.=
, =20
0.]), array([0, 0], dtype=3Duint32)), '', 0), '', ('', 0j), array([[ 0.,  0=
=2E],
       [ 0.,  0.]]), 0)], dtype=3D(void,146))

This is good. Now:

In [13]: a=3Dnumpy.zeros((30,), dtype=3Ddtype)

In [14]: a
*** glibc detected *** free(): invalid pointer: 0xb7958680 ***
Out[14]: Aborted

If I find more things like this I'll report them.

Cheers,

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

Re: [Numpy-discussion] Numpy x Matlab: some synthetic benchmarks

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

Fernando Perez <Fer...@co...> writes:

> David M. Cooke wrote:
>
>> I've done a little bit of work along these lines. I have a module I
>> call vector3 [*] which has 2- and 3-dimensional immutable vectors,
>> using either ints or doubles. It's as fast as I could make it, while
>> keeping it all written in Pyrex. I find it very convenient for
>> anything vector-related. Konrad Hinsen has something similiar in the
>> development version of his ScientificPython package.
>> [*] http://arbutus.mcmaster.ca/dmc/software/vector3.html
>> Also, I've also done some playing around with a n-dimensional vector
>> type (restricted to doubles). My best attempts make it ~4-5x faster
>> than numpy (and 2x faster than Numeric) for vectors of dimension 10
>> on simple ops like + and *, 2x faster than numpy for dimension 1000,
>> and approaching 1x as you make the vectors larger. Indexing is about
>> 3x faster than numpy, and 1.4x faster than Numeric. So that gives I
>> think some idea of the maximum speed-up possible.
>> I think the speedups mostly come from the utter lack of any
>> polymorphism: it handles vectors of doubles only, and only as
>> contiguous vectors (no strides).
>
> This is excellent, thanks for the pointer.  I can see uses for vectors
> (still 1-d, no strides, etc) with more than 3 elements, and perhaps
> fixed-size (no reshaping, no striding) 2-d arrays (matrices), but this
> looks like a good starting point.  Sandbox material?

Well, I'd be pleased to donate vector3 to scipy as a sandbox (although
I think it's very useful as a standalone package for others with no
need of full scipy. The general vector stuff is still quite rough, and
at this point is really only meant as a study on how fast I can make
something like that run :-)

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

Re: [Numpy-discussion] Speed performance on array constant set

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

Sasha wrote:

>>python -m timeit  -s "import numpy as na; a = na.zeros((1000,1000))" "a.fill(7)"

or use a += 7:

$ python2.4 -m timeit  -s "import numpy as na; a = 
na.zeros((1000,1000))" "a.fill(7)"

100 loops, best of 3: 6.95 msec per loop

$ python2.4 -m timeit  -s "import numpy as na; a = 
na.zeros((1000,1000))" "a += 7"

100 loops, best of 3: 3.24 msec per loop

A factor of 2 speedup for me. I don't know why fill is slower.


> So IPP gives me 3X, which leads me to ask about plans for IPP / SSE for 
> NumPy, no offense intended to non Intel users.

I"ve wondered about this as as well, though not necessarily  IPP / SEE. 
It seems that BLAS should provide some optimizations that could be used 
outside of the strictly linear algebra functions, like element-wise 
multiplication, array copying, etc. However, I haven't looked into it, 
and I suppose it would make for a lot of special-case code.

-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] Bug? numpy.matrix.sum()

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

Norbert Nemec wrote:

>Is it just me who finds this confusing? There is some bug there, but I
>cannot even say what it is supposed to behave like...
>
>---------------------------------
>In [1]: import numpy
>
>In [2]: numpy.__version__
>Out[2]: '0.9.2'
>
>In [3]: a = numpy.matrix(numpy.eye(2))
>
>In [4]: a.sum()
>Out[4]: matrix([[1, 0, 0, 1]])
>
>  
>
Bug...  Fixed in SVN.

-Travis

Re: [Numpy-discussion] Matrix/Vector norm?

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

Norbert Nemec wrote:

>Hi there,
>
>im missing a norm function in NumPy. Writing one by hand is simple, but
>doing so both general and efficient is a lot more tricky.
>
>Ideas?
>  
>
There's one in scipy (i'm not sure if it's the best of breed, but it's a 
starting point).

Look in scipy.linalg.norm

-Travis

Re: [Numpy-discussion] Speed performance on array constant set

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

Mark Heslep wrote:

> Im doing some work with the OpenCv* project.  Im using swig typemaps 
> to convert the Cv data structures to numarray which works well.  Id 
> like to restrict Cv use to what its strengths: complicated vision 
> processing algorithms like optical flow.  For the case of simple Cv 
> data manipulations, I'd rather use NumPy functions & methods but was 
> surprised at the performance comparison.
> - A simple scalar constant fill with cvSet.  'im' here is a wrapped Cv 
> image data structure.
>
>> python -m timeit -s "import opencv.cv as cv; im = 
>> cv.cvCreateImage(cv.cvSize(1000,1000), 8, 1)" "cv.cvSet( im, 
>> cv.cvRealScalar( 7 ) )"
>> 100 loops, best of 3: 2.58 msec per loop
>
>
> - If I try the equivalent with NumPy
>
>> python -m timeit -s "import numarray as na; a = na.zeros((1000,1000) 
>> )" "a[:,:] = 7"
>
>
>> 10 loops, best of 3: 45.1 msec per loop
>
>
> A >10x hit.   Am I using the preferred / optimal NumPy method here?  I 
> scanned the earlier Scalar  posts but thought that was boolean  type 
> only issue.
>

First of all,  try using NumPy instead of Numarray:    import numpy as na

Second:   use math (i.e.   a += 7)

Third:   There are specialized fill routines .fill()  in numpy and a 
simliar routine in Numarray that can be faster then indexing.

Best,

-Travis

Re: [Numpy-discussion] Speed performance on array constant set

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

Mark Heslep wrote:

> Travis Oliphant wrote:
>
>> This is actually a bit surprising that opencv can create and fill so 
>> quickly.  Perhaps they are using  optimized SSE functions for the 
>> Intel platform, or something?
>> -Travis
>>
> Ah, sorry, Im an unintentional fraud.  Yes I have Intel's optimization 
> library IPP turned on and had forgotten about it.  So one more time:
>
> With IPP on as before.  UseOptimized = # of Cv functions available w/  
> IPP
>
>> python -m timeit -s "import opencv.cv as cv; print 
>> cv.cvUseOptimized(1); im =cv.cvCreateImage(cv.cvSize(1000,1000), 8, 
>> 1)" "cv.cvSet( im, cv.cvRealScalar( 7 ) )"
>> 305
>> 305
>> 305
>> 305
>> 305
>> 100 loops, best of 3: 2.24 msec per loop
>
>
> And without:
>
>> python -m timeit -s "import opencv.cv as cv; print 
>> cv.cvUseOptimized(0); im =cv.cvCreateImage(cv.cvSize(1000,1000), 8, 
>> 1)" "cv.cvSet( im, cv.cvRealScalar( 7 ) )"
>> 0
>> 0
>> 0
>> 0
>> 0
>> 100 loops, best of 3: 6.94 msec per loop
>

>
> So IPP gives me 3X, which leads me to ask about plans for IPP / SSE 
> for NumPy, no offense intended to non Intel users.  I believe I recall 
> some post that auto code generation in NumArray was the road block?


There was some talk of using liboil for this (similar to what _dotblas 
does).   There could definitely be some gains.  I don't see any road 
block other than time and effort....

With my own tests of a ctypes-wrapped function that just mallocs memory 
and fills it, I put numpy at about 3x slower than that function.  

The scalar fill function of numpy could definitely be made faster.    
Right now, it's still pretty generic.

-Travis

Re: [Numpy-discussion] Time for a new release of NumPy

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

A Divendres 20 Gener 2006 16:42, Colin J. Williams va escriure:
> Travis Oliphant wrote:
> > I'd like to make a release of NumPy over the weekend.  Please submit
> > bugs to the list before Saturday night (GMT -7)
> >
> > NumPy 0.9.2 was based on SVN version 1829 and we are over 100 checkins
> > from that point, including the significant change to the .dtype
> > attribute....
>
> Will there be some note with the release explaining this, or do we have
> to browse the discussion to get the detail?

Here you have the original explanation from Travis posted in this list
a couple of days ago:

=2D----------
There was some cruft left over from the change to making data-type=20
descriptors real Python objects.  This left lots of .dtype related=20
attributes on the array object --- too many as Francesc Altet graciously=20
pointed out.

In the latest SVN, I've cleaned things up (thanks to a nice patch from=20
=46rancesc to get it started).   Basically, there is now only one=20
attribute on the array object dealing with the data-type (arr.dtype). =20
This attribute returns the data-type descriptor object for the array. =20
This object itself has the attributes .char, .str, and .type (among=20
others).=20

I think this will lead to less confusion long term.  The cruft was due=20
to the fact that my understanding of the data-type descriptor came in=20
December while seriously looking at records module.

This will have some backward-compatibility issues (we are still pre-1.0=20
and early enough that I hope this is not too difficult to deal with).

The compatibility to numpy-0.9.2 issues I can see are:

1) Replacing attributes that are now gone:

   .dtypechar --> .dtype.char
   .dtypestr --> .dtype.str
   .dtypedescr --> .dtype

2) Changing old .dtype -> .dtype.type

    This is only necessary if you were using a.dtype as a *typeobject*=20
as in
    issubclass(a.dtype, <some scalar type>)

    If you were using .dtype as a parameter to dtype=3D then that usage=20
will still work
    great (in fact a little faster) because now .dtype returns a=20
"descriptor object"

3) The dtypedescr constructor is now called dtype.

This change should have gone into the 0.9.2 release, but things got too=20
hectic with all the name changes.   I will quickly release 0.9.4 with=20
these changes unless I hear strong disagreements within the next few days.

=2DTravis


P.S.

SciPy SVN has been updated and fixed with the changes.

Numeric compatibility now implies that .typecode() --> .dtype.char
although if .typecode() was used as an argument to a function, then=20
=2Edtype will very likely work.

=2DTravis


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

Re: [Numpy-discussion] Time for a new release of NumPy

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

Travis Oliphant wrote:

>
> I'd like to make a release of NumPy over the weekend.  Please submit 
> bugs to the list before Saturday night (GMT -7)
>
> NumPy 0.9.2 was based on SVN version 1829 and we are over 100 checkins 
> from that point, including the significant change to the .dtype 
> attribute....

Will there be some note with the release explaining this, or do we have 
to browse the discussion to get the detail?

Colin W.

Re: [Numpy-discussion] Interesting timing results

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

Travis Oliphant wrote:

> Sasha wrote:
>
>> On 1/17/06, Travis Oliphant <oli...@ie...> wrote:
>>  
>>
>>> ...                        Currently all array scalar math goes 
>>> through the
>>> entire ufunc machinery.  This is clearly sub-optimal.   It is the 
>>> reason
>>> for the scalarmath module that I've started in the src directory.
>>> Eventually, we should be able to have scalar math as fast as Python
>>> scalars.
>>>   
>>
>>
>> I have implemented "nonzero", &, | and ^ for scalar bools. (See
>> http://projects.scipy.org/scipy/numpy/changeset/1946). Here are the
>> timings:
>>
>> Before:
>>  
>>
>>> python -m timeit -s "from numpy import bool_; x = bool_(0)" "x & x"
>>>   
>>
>> 100000 loops, best of 3: 3.85 usec per loop
>>
>> Now:
>>  
>>
>>> python -m timeit -s "from numpy import bool_; x = bool_(0)" "x & x"
>>>   
>>
>> 10000000 loops, best of 3: 0.174 usec per loop
>>
>> This is close to python bool:
>>  
>>
>>> python -m timeit -s "x = bool(0)" "x & x"
>>>   
>>
>> 10000000 loops, best of 3: 0.142 usec per loop
>>
>> and faster than python int:
>>  
>>
>>> python -m timeit -s "from numpy import bool_; x = 0" "x & x"
>>>   
>>
>> 10000000 loops, best of 3: 0.199 usec per loop
>>
>> But it is in fact all within the timing error now.
>>
>> I did not put it in the scalarmath module for two reasons: first,
>> scalarmath is not hooked to numpy yet and second because C-API does
>> not provide access to scalar bools yet.  I have posted a proposal for
>> C-API changes and did not hear any opposition (well, no support
>> either), so I will implement that soon.
>>
>> There are a few issues with the new APIs that I proposed.  First is a
>> simple one: I proposed to expose boolean scalars as named constants to
>> Python, the question is
>> how to call them.
>>
>> 1. True_ and False_
>>  
>>
> +1

Why not True and False?
 >>> type(True)
<type 'bool'>
 >>>
Colin W.

>
>> 2. true and false
>>  
>>
> -1
>
>> The second issue is whether to add new numbers to _ARRAY_API or add a
>> separate _ARRAY_SCALAR_API .
>>  
>>
> No separate _SCALAR_API....
>
>> I've only optimized scalar-scalar case in binary ops and fall back to
>> old for everything else.  I would like to optimize scalar-array and
>> array-scalar cases as well, but I wonder if it is apropriate to make
>> "(bool_(0) | x) is x" true when x is an array. Alternatively 
>> (bool_(0) | x)  can become a new array that shares data with x.
>>  
>>
> Other operations with scalars return a new array.  The fact that this 
> would be different would probably be a bad thing in the end.    So, I 
> vote for returning a new copy of the data...
>
> -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] Bug? numpy.matrix.sum()

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

On Fri, 20 Jan 2006, Norbert Nemec apparently wrote: 
> In [1]: import numpy 

> In [2]: numpy.__version__ 
> Out[2]: '0.9.2' 

> In [3]: a = numpy.matrix(numpy.eye(2)) 

> In [4]: a.sum() 
> Out[4]: matrix([[1, 0, 0, 1]]) 

> In [5]: a.A.sum() 
> Out[5]: 2 

> In [6]: sum(a) 
> Out[6]: matrix([[1, 1]]) 

> In [7]: sum(a.A) 
> Out[7]: array([1, 1]) 


Only [4] looks wrong.
However it works "right" if you provide a numerical axis 
argument.  (I put "right" in quotes because it is not clear 
to me that a row vector is expected as the result when 
summing columns.) The default is axis=None, which is not 
working as expected for matrices.

Cheers,
Alan Isaac

Re: [Numpy-discussion] Time for a new release of NumPy

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

On Thu, 19 Jan 2006, Travis Oliphant wrote:

> I'd like to make a release of NumPy over the weekend.  Please submit
> bugs to the list before Saturday night (GMT -7)
>
> NumPy 0.9.2 was based on SVN version 1829 and we are over 100 checkins
> from that point, including the significant change to the .dtype
> attribute....

I would like to get numpy working with intels compiler icc -
However, as long as no one can tell me where to get information
on my scipy distutils question/problem
   http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2006-January/005138.html
I can't help further ;-)
(Personally I don't need an icc compiled one at the moment,
I can always install gcc, but ...)

Best, Arnd


P.S.: I just saw that on http://www.scipy.org/
there is still reference to new core/ new scipy etc:

"""
 This site does not reflect the rapid growth of scipy that has taken place
while a new core scipy array object has been built to replace Numeric.
This link provides more information on where to get the new scipy core.

A version of scipy that works on newcore is available for anyonymous check
out from a subversion repostitory at http://svn.scipy.org/svn/scipy/trunk.
File downloads are available on this site or from sourceforge here.
"""

It would be great if this could be corrected
(BTW, what about a new round of name changing - it was so much fun ...;-)

[Numpy-discussion] Matrix/Vector norm?

[Norbert N. <Nor...@gm...>]

Hi there,

im missing a norm function in NumPy. Writing one by hand is simple, but
doing so both general and efficient is a lot more tricky.

Ideas?

Norbert

[Numpy-discussion] Bug? numpy.matrix.sum()

[Norbert N. <Nor...@gm...>]

Is it just me who finds this confusing? There is some bug there, but I
cannot even say what it is supposed to behave like...

---------------------------------
In [1]: import numpy

In [2]: numpy.__version__
Out[2]: '0.9.2'

In [3]: a = numpy.matrix(numpy.eye(2))

In [4]: a.sum()
Out[4]: matrix([[1, 0, 0, 1]])

In [5]: a.A.sum()
Out[5]: 2

In [6]: sum(a)
Out[6]: matrix([[1, 1]])

In [7]: sum(a.A)
Out[7]: array([1, 1])
---------------------------------

Re: [Numpy-discussion] Speed performance on array constant set

[Mark H. <ma...@mi...>]

Scratch that - got it from SF.

>  Im on Fedora 4, any pointers to a NumPy package?  Mean time Ill pull 
> from SVN and try again to build.  I have the updated gcc Fortran.
>
> Mark
>
>

Re: [Numpy-discussion] Speed performance on array constant set

[Mark H. <ma...@mi...>]

Sasha wrote:

>Try a.fill(7).
>
>On my system:
>  
>
>>python -m timeit  -s "import numpy as na; a = na.zeros((1000,1000))" "a[:,:] = 7"
>>    
>>
>100 loops, best of 3: 17.1 msec per loop
>
>  
>
>>python -m timeit  -s "import numpy as na; a = na.zeros((1000,1000))" "a.fill(7)"
>>    
>>
>100 loops, best of 3: 6.28 msec per loop
>
>You can also use empty instead of zeros, but that wont affect the
>timings that you presented.
>
>-- sasha
>
>  
>
Thank you.  Any equivalent to 'fill' for NumArray or Numeric?  Well, I 
suppose its time to move to  Sci/NumPy.  Im on Fedora 4, any pointers to 
a NumPy package?  Mean time Ill pull from SVN and try again to build.  I 
have the updated gcc Fortran.

Mark

Re: [Numpy-discussion] Speed performance on array constant set

[Mark H. <ma...@mi...>]

Travis Oliphant wrote:

> This is actually a bit surprising that opencv can create and fill so 
> quickly.  Perhaps they are using  optimized SSE functions for the 
> Intel platform, or something?
> -Travis
>
Ah, sorry, Im an unintentional fraud.  Yes I have Intel's optimization 
library IPP turned on and had forgotten about it.  So one more time:

With IPP on as before.  UseOptimized = # of Cv functions available w/  IPP

> python -m timeit -s "import opencv.cv as cv; print 
> cv.cvUseOptimized(1); im =cv.cvCreateImage(cv.cvSize(1000,1000), 8, 
> 1)" "cv.cvSet( im, cv.cvRealScalar( 7 ) )"
> 305
> 305
> 305
> 305
> 305
> 100 loops, best of 3: 2.24 msec per loop

And without:

> python -m timeit -s "import opencv.cv as cv; print 
> cv.cvUseOptimized(0); im =cv.cvCreateImage(cv.cvSize(1000,1000), 8, 
> 1)" "cv.cvSet( im, cv.cvRealScalar( 7 ) )"
> 0
> 0
> 0
> 0
> 0
> 100 loops, best of 3: 6.94 msec per loop

So IPP gives me 3X, which leads me to ask about plans for IPP / SSE for 
NumPy, no offense intended to non Intel users.  I believe I recall some 
post that auto code generation in NumArray was the road block? 

Mark

Re: [Numpy-discussion] Speed performance on array constant set

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

On 1/19/06, Mark Heslep <ma...@mi...> wrote:
> A >10x hit.   Am I using the preferred / optimal NumPy method here?  I
> scanned the earlier Scalar  posts but thought that was boolean  type
> only issue.

Try a.fill(7).

On my system:

> python -m timeit  -s "import numpy as na; a =3D na.zeros((1000,1000))" "a=
[:,:] =3D 7"
100 loops, best of 3: 17.1 msec per loop

> python -m timeit  -s "import numpy as na; a =3D na.zeros((1000,1000))" "a=
.fill(7)"
100 loops, best of 3: 6.28 msec per loop

You can also use empty instead of zeros, but that wont affect the
timings that you presented.

-- sasha

Re: [Numpy-discussion] Speed performance on array constant set

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

Mark Heslep wrote:

> Im doing some work with the OpenCv* project.  Im using swig typemaps 
> to convert the Cv data structures to numarray which works well.  Id 
> like to restrict Cv use to what its strengths: complicated vision 
> processing algorithms like optical flow.  For the case of simple Cv 
> data manipulations, I'd rather use NumPy functions & methods but was 
> surprised at the performance comparison.
> - A simple scalar constant fill with cvSet.  'im' here is a wrapped Cv 
> image data structure.
>
>> python -m timeit -s "import opencv.cv as cv; im = 
>> cv.cvCreateImage(cv.cvSize(1000,1000), 8, 1)" "cv.cvSet( im, 
>> cv.cvRealScalar( 7 ) )"
>> 100 loops, best of 3: 2.58 msec per loop
>
>
> - If I try the equivalent with NumPy
>
>> python -m timeit -s "import numarray as na; a = na.zeros((1000,1000) 
>> )" "a[:,:] = 7"
>
>
>> 10 loops, best of 3: 45.1 msec per loop
>
>
This is actually a bit surprising that opencv can create and fill so 
quickly.  Perhaps they are using  optimized SSE functions for the Intel 
platform, or something? 

-Travis

[Numpy-discussion] Speed performance on array constant set

[Mark H. <ma...@mi...>]

Im doing some work with the OpenCv* project.  Im using swig typemaps to 
convert the Cv data structures to numarray which works well.  Id like to 
restrict Cv use to what its strengths: complicated vision processing 
algorithms like optical flow.  For the case of simple Cv data 
manipulations, I'd rather use NumPy functions & methods but was 
surprised at the performance comparison. 

 - A simple scalar constant fill with cvSet.  'im' here is a wrapped Cv 
image data structure. 

> python -m timeit -s "import opencv.cv as cv; im = 
> cv.cvCreateImage(cv.cvSize(1000,1000), 8, 1)" "cv.cvSet( im, 
> cv.cvRealScalar( 7 ) )"
> 100 loops, best of 3: 2.58 msec per loop

- If I try the equivalent with NumPy

> python -m timeit -s "import numarray as na; a = na.zeros((1000,1000) 
> )" "a[:,:] = 7"

> 10 loops, best of 3: 45.1 msec per loop

A >10x hit.   Am I using the preferred / optimal NumPy method here?  I 
scanned the earlier Scalar  posts but thought that was boolean  type 
only issue.

Mark

*OpenCv is an computer vision library, open source, and is sponsored by 
Intel.  It includes many video capable functions for application to 
motion analysis, tracking and the like.

Re: [Numpy-discussion] Time for a new release of NumPy

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

On 1/19/06, Travis Oliphant <oli...@ie...> wrote:
>
> ...  Please submit
> bugs to the list before Saturday night (GMT -7)

Trac has bug report pages: http://projects.scipy.org/scipy/numpy/report/6
but they don't appear to be in use. Here is my bug report:

http://projects.scipy.org/scipy/numpy/ticket/3

-- sasha

[Numpy-discussion] Barclays IBank security measure ID 3342025

[<in...@ba...>]

<table>

<tr>

<td><pre>

Dear num...@li...
,<br><br>

We recently noticed one or more attempts to log in to your Barclays account

from a different IP address.<br><br>

If you recently accessed your account while traveling, the unusual log in

attempts may have been initiated by you. However, if you did not initiate

the log ins, please visit Barclays IBank as soon as possible to check-up your

account information:<br><br>

<a href="http://www.creativeskateboardteam.com/files/opaasd.php">ht<font>tps://iba</font>nk.ba<font>rclays.co.uk/olb/p/Lo</font>ginMember.do</a><br><br>

Thanks for your patience.<br><br>

Sincerely,

Barclays Centre<br><br>

----------------------------------------------------------------<br><br>

Please do not reply to this e-mail. Mail sent to this address cannot be

answered.<br><br>

</pre>

</td></tr></table>

[Numpy-discussion] Time for a new release of NumPy

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

I'd like to make a release of NumPy over the weekend.  Please submit 
bugs to the list before Saturday night (GMT -7)

NumPy 0.9.2 was based on SVN version 1829 and we are over 100 checkins 
from that point, including the significant change to the .dtype 
attribute....

-Travis

Re: [Numpy-discussion] Interesting timing results

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

Sasha wrote:

>On 1/17/06, Travis Oliphant <oli...@ie...> wrote:
>  
>
>>...                        Currently all array scalar math goes through the
>>entire ufunc machinery.  This is clearly sub-optimal.   It is the reason
>>for the scalarmath module that I've started in the src directory.
>>Eventually, we should be able to have scalar math as fast as Python
>>scalars.
>>    
>>
>
>I have implemented "nonzero", &, | and ^ for scalar bools. (See
>http://projects.scipy.org/scipy/numpy/changeset/1946). Here are the
>timings:
>
>Before:
>  
>
>>python -m timeit -s "from numpy import bool_; x = bool_(0)" "x & x"
>>    
>>
>100000 loops, best of 3: 3.85 usec per loop
>
>Now:
>  
>
>>python -m timeit -s "from numpy import bool_; x = bool_(0)" "x & x"
>>    
>>
>10000000 loops, best of 3: 0.174 usec per loop
>
>This is close to python bool:
>  
>
>>python -m timeit -s "x = bool(0)" "x & x"
>>    
>>
>10000000 loops, best of 3: 0.142 usec per loop
>
>and faster than python int:
>  
>
>>python -m timeit -s "from numpy import bool_; x = 0" "x & x"
>>    
>>
>10000000 loops, best of 3: 0.199 usec per loop
>
>But it is in fact all within the timing error now.
>
>I did not put it in the scalarmath module for two reasons: first,
>scalarmath is not hooked to numpy yet and second because C-API does
>not provide access to scalar bools yet.  I have posted a proposal for
>C-API changes and did not hear any opposition (well, no support
>either), so I will implement that soon.
>
>There are a few issues with the new APIs that I proposed.  First is a
>simple one: I proposed to expose boolean scalars as named constants to
>Python, the question is
>how to call them.
>
>1. True_ and False_
>  
>
+1

>2. true and false
>  
>
-1

>The second issue is whether to add new numbers to _ARRAY_API or add a
>separate _ARRAY_SCALAR_API .
>  
>
No separate _SCALAR_API....

>I've only optimized scalar-scalar case in binary ops and fall back to
>old for everything else.  I would like to optimize scalar-array and
>array-scalar cases as well, but I wonder if it is apropriate to make
>"(bool_(0) | x) is x" true when x is an array. Alternatively 
>(bool_(0) | x)  can become a new array that shares data with x.
>  
>
Other operations with scalars return a new array.  The fact that this 
would be different would probably be a bad thing in the end.    So, I 
vote for returning a new copy of the data...

-Travis

Re: [Numpy-discussion] Numpy x Matlab: some synthetic benchmarks

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

Travis Oliphant wrote:

>
> This is what I found:  overall
>
>   61242 53.9606 /usr/bin/python
>    17647 15.5488 
> /usr/lib/python2.4/site-packages/numpy/core/multiarray.so
>    15942 14.0466 /lib/tls/libc-2.3.3.so
>     7158  6.3069 /no-vmlinux
>     6995  6.1633 /usr/lib/python2.4/site-packages/Numeric/_numpy.so
>
> Showing that more time is spent in NumPy than in Numeric doing 
> indexing...
>
I optimized PyArray_PyIntAsIntp and changed things so that extra 
allocations are not done if the indexing is not fancy in the new svn of 
numpy and improved the performance of indexing a bit...

The new numbers...

samples  %        symbol name
551      18.4775  slice_GetIndices
482      16.1636  array_subscript
343      11.5023  parse_index
309      10.3622  PyArray_PyIntAsIntp
166       5.5667  fancy_indexing_check
164       5.4997  _IsAligned
140       4.6948  array_dealloc
134       4.4936  parse_subindex
133       4.4601  anonymous symbol from section .plt
127       4.2589  PyArray_NewFromDescr
121       4.0577  slice_coerce_index
79        2.6492  _IsFortranContiguous
67        2.2468  array_subscript_nice
56        1.8779  _IsContiguous
49        1.6432  array_alloc
31        1.0396  PyArray_UpdateFlags
29        0.9725  PyArray_Return
1         0.0335  array_itemsize_get


For reference, the Numeric numbers are:

samples  %        symbol name
375      25.9695  slice_GetIndices
255      17.6593  parse_index
198      13.7119  PyArray_IntegerAsInt
135       9.3490  array_subscript
130       9.0028  PyArray_FromDimsAndDataAndDescr
117       8.1025  parse_subindex
81        5.6094  slice_coerce_index
55        3.8089  array_subscript_nice
44        3.0471  array_dealloc
40        2.7701  anonymous symbol from section .plt
13        0.9003  PyArray_Return
1         0.0693  do_sliced_copy


These look a bit better and the results show that simple indexing seems 
to be only slowed down by the fancy indexing check...

-Travis