You can subscribe to this list here.
2000 
_{Jan}
(8) 
_{Feb}
(49) 
_{Mar}
(48) 
_{Apr}
(28) 
_{May}
(37) 
_{Jun}
(28) 
_{Jul}
(16) 
_{Aug}
(16) 
_{Sep}
(44) 
_{Oct}
(61) 
_{Nov}
(31) 
_{Dec}
(24) 

2001 
_{Jan}
(56) 
_{Feb}
(54) 
_{Mar}
(41) 
_{Apr}
(71) 
_{May}
(48) 
_{Jun}
(32) 
_{Jul}
(53) 
_{Aug}
(91) 
_{Sep}
(56) 
_{Oct}
(33) 
_{Nov}
(81) 
_{Dec}
(54) 
2002 
_{Jan}
(72) 
_{Feb}
(37) 
_{Mar}
(126) 
_{Apr}
(62) 
_{May}
(34) 
_{Jun}
(124) 
_{Jul}
(36) 
_{Aug}
(34) 
_{Sep}
(60) 
_{Oct}
(37) 
_{Nov}
(23) 
_{Dec}
(104) 
2003 
_{Jan}
(110) 
_{Feb}
(73) 
_{Mar}
(42) 
_{Apr}
(8) 
_{May}
(76) 
_{Jun}
(14) 
_{Jul}
(52) 
_{Aug}
(26) 
_{Sep}
(108) 
_{Oct}
(82) 
_{Nov}
(89) 
_{Dec}
(94) 
2004 
_{Jan}
(117) 
_{Feb}
(86) 
_{Mar}
(75) 
_{Apr}
(55) 
_{May}
(75) 
_{Jun}
(160) 
_{Jul}
(152) 
_{Aug}
(86) 
_{Sep}
(75) 
_{Oct}
(134) 
_{Nov}
(62) 
_{Dec}
(60) 
2005 
_{Jan}
(187) 
_{Feb}
(318) 
_{Mar}
(296) 
_{Apr}
(205) 
_{May}
(84) 
_{Jun}
(63) 
_{Jul}
(122) 
_{Aug}
(59) 
_{Sep}
(66) 
_{Oct}
(148) 
_{Nov}
(120) 
_{Dec}
(70) 
2006 
_{Jan}
(460) 
_{Feb}
(683) 
_{Mar}
(589) 
_{Apr}
(559) 
_{May}
(445) 
_{Jun}
(712) 
_{Jul}
(815) 
_{Aug}
(663) 
_{Sep}
(559) 
_{Oct}
(930) 
_{Nov}
(373) 
_{Dec}

S  M  T  W  T  F  S 




1
(18) 
2
(29) 
3
(29) 
4
(7) 
5
(5) 
6
(6) 
7
(9) 
8
(10) 
9
(15) 
10
(11) 
11
(2) 
12
(5) 
13
(24) 
14
(22) 
15
(28) 
16
(23) 
17
(33) 
18
(6) 
19
(2) 
20
(15) 
21
(21) 
22
(17) 
23
(51) 
24
(24) 
25
(8) 
26
(17) 
27
(49) 
28
(40) 
29
(35) 
30
(14) 
31
(14) 

From: Travis Oliphant <oliphant@ee...>  20060330 23:54:14

Simon Burton wrote: >>>>a=numpy.array(list('foabcdeef'),dtype=numpy.dtype("O")) >>>>numpy.equal(a,'f') >>>> >>>> A couple of things: 1) dtype=numpy.dtype("O") is equivalent to dtype="O" 2) Because you have an object array this should work. You can work around the bug using numpy.equal(a,array('f','O')) Travis 
From: Sasha <ndarray@ma...>  20060330 23:48:12

On 3/30/06, Simon Burton <simon@...> wrote: > > >>> a=3Dnumpy.array(list('foabcdeef'),dtype=3Dnumpy.dtype("O")) > >>> numpy.equal(a,'f') > NotImplemented > > So where do I start implementing this ? > core/src/ufuncobject.c ? > Yes, 879 if (PyTypeNum_ISFLEXIBLE(arg_types[i])) { 880 loop>notimplemented =3D 1; 881 return nargs; 882 } (line numbers from r2310) 
From: Tim Hochberg <tim.hochberg@co...>  20060330 23:17:46

The following snippet utilizing a rank0 array will segfault numpy: import numpy a = numpy.array(4) b = numpy.arange(10) a *= b (Build '0.9.7.2301' using VC7 on windows). I'll file a better bug report tomorrow, assuming this hasn't been fixed, but I'm on my way out the door. tim 
From: Simon Burton <simon@ar...>  20060330 22:49:08

>>> a=numpy.array(list('foabcdeef'),dtype=numpy.dtype("O")) >>> numpy.equal(a,'f') NotImplemented So where do I start implementing this ? core/src/ufuncobject.c ? Simon.  Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com 
From: Tim Hochberg <tim.hochberg@co...>  20060330 19:21:48

There's a problem with the _wrapit function. If the function that it wraps, returns a scalar, it blows up. Here's an example: import numpy class narray(numpy.ndarray): def get_argmax(self): raise AttributeError argmax = property(get_argmax) a = narray([3], int, numpy.arange(3)) print type(a), isinstance(a, numpy.ndarray) print a print numpy.argmax(a) ==> <class '__main__.narray'> True [0 1 2] Traceback (most recent call last): File "find_bug.py", line 13, in ? print numpy.argmax(a) File "C:\python24\lib\sitepackages\numpy\core\oldnumeric.py", line 278, in argmax return _wrapit(a, 'argmax', axis) File "C:\python24\lib\sitepackages\numpy\core\oldnumeric.py", line 170, in _wrapit result = wrap(result) TypeError: can only be called with ndarray object A possible fix is to do another isinstance check on the way out: def _wrapit(obj, method, *args, **kwds): try: wrap = obj.__array_wrap__ except AttributeError: wrap = None result = getattr(asarray(obj),method)(*args, **kwds) if wrap and isinstance(result, mu.ndarray): result = wrap(result) return result That fixes this problem, and I think it should be OK in general, but I'd like a second opinion before comitting it. regards, tim 
From: David Huard <david.huard@gm...>  20060330 17:09:16

Thanks Pearu, From the documentation in freeze.py, it is possible to tell freeze the explicit path to modules. freeze [options...] script [module] where module is an absolute path. I'll try this out. David 
From: Tim Hochberg <tim.hochberg@co...>  20060330 16:52:59

Norbert Nemec wrote: >Sorry, Travis, I missed your answer for a week... > >I confess, my efficiency concerns about the histogram routine are to >some extent, of theoretical nature. However, given the widespread use of >the function and considering the simplicity of the solution, I think it >is still worth thinking about it: > >The current histogram routine is based on a "sort" of the incoming data. >Quicksort is usually O(N log N), worst case O(N**2). Doing the histogram >by simply counting is a simple O(N) procedure. The absolute cost of the >quicksort algorithm is low, but the simple counting should be even >lower, if done efficiently in C. > > I'm not so sure about this analysis: histogram allows aribtrarily spaced bins, so I think the actual comparison is O(N log N) versus O(N log M) where M is the number of bins. The number of bins will typically be much lower than N it's true, but the log will tend to wash that out some. Take, for example, 1024 items into 32 bins. Then log N is 10 versus log M being 5. This difference is small enough that probably the differences in constant factors will dominate. >What probably weighs heavier though, is the memory usage: sorting can >either be done in place, destroying the original data, or requires a >copy. > I wouldn't worry about the memory usage itself so much. We all have oodles of RAM and virtual memory these days anyway. In addition, you'll probably end up copying discontiguous data anyway, which one ends up with rather frequently. However, the counting algorithm should be more cache friendly than the sort based on. I find that operations on matrices that don't fit in the cache are dominated by memory access time, not CPU time. On my machine that happens somewhere between 10k and 100k elements. For arrays with 100k or so elements, the counting algorithm might be a big win. >Counting could be done even on an iterator without storing all the >data. > > This is true. However, if you go through the iterator interface, it will be much slower than directly addressing the array memory. Such a thing might be cool to have somewhere (itertools or something), but probably isn't appropriate for numpy. >Lacking a comparable implementation of the counting algorithm, I have >not done any actual speed comparisons. Why nobody ever found this >inefficiency, I cannot say. Probably nobody ever had a real comparison >how fast the histogram could be. Unless you are dealing with really huge >data, the difference will not show up. > > This is the crux of the issue I think. The implementaion of histogram looks fine for what it does. For reasonably large arrays, the overhead of it being implemented in Python will be negligible. Without someone who actually needs something different, a new implementation is liable to wander off into the realm of pointless microoptimization. So, my advice is to leave it alone till it actually causes you problems. >Anyway, as I said, a solution should be simple to code once it is >decided how to do it. Simply recoding the histogram routine itself in C >would be the minimal solution. Implementing a more flexible counting >routine that can be used in other contexts as well would certainly be >more desirable, but I have no clear vision what that should look like. > > Well if you were going to do this. I would code a drop in replacement for the current histogram. No iterators (they belong in a different library). Variable spaces bins allowed, etc. It doesn't sound like we need a different histogram function and the more overlapping functions that there are, the less each individual one gets used and tested and the more likely that bugs and bitrot set in. What I'd acutally do is implent something that behaved like this: def histogram_core(data, bins): # I hope I grabbed the right stuff out histogram_core # bins is an actual list of bins edges as per histogram # which could really us a docstring n = sort(a).searchsorted(bins) n = concatenate([n, [len(a)]]) n = n[1:]n[:1] return n Except written in C and using a counting algorithm. Then the histogram can be just a thin wrapper over histogram_core. Then test it with a bunch of different array sizes and bin counts and see how it does. My guess is that the sort based algoritm will do better in some cases (arrays with 10k or fewer elements and lots of bins) while the counting algorithm does better in others (few bins or 100k or more elements). But we'll see. Or maybe we won't. Regards, tim >Greetings, >Norbert > > > >Travis Oliphant wrote: > > > >>Norbert Nemec wrote: >> >> >> >>>I have a very much related problem: Not only that the idea described by >>>Mads Ipsen does not work, but I could generally find no efficient way to >>>do a "counting" of elements in an array, as it is needed for a >>>histogram. >>> >>> >>> >>This may be something we are lacking. >> >>It depends on what you mean by efficient, I suppose. The sorting >>algorithms are very fast, and the histogram routines that are >>scattered all over the place (including the histogram function in >>numpy) has been in use for a long time, and you are the first person >>to complain of its efficiency. That isn't to say your complaint may >>not be valid, it's just that for most people the speed has been >>sufficient. >> >> >> >>>What would instead be needed is a function that simply gives the count >>>of occurances of given values in a given array: >>> >>> >>> >>I presume you are talking of "integer" arrays, since >>equalitycomparison of floatingpoint values is usually not very >>helpful so most histograms on floatingpoint values are given in terms >>of bins. Thus, the searchsorted function uses bins for it's >>"counting" operation. >> >> >> >>> >>> >>> >>> >>>>>>[4,5,2,3,2,1,4].count([0,1,2,3,4,5]) >>>>>> >>>>>> >>>>>> >>>[0,1,2,1,1,2] >>> >>> >>> >>> >>A count function for integer arrays could certainly be written using a >>Cloop. But, I would first just use histogram([4,5,2,3,2,1,4], >>[0,1,2,3,4,5]) and make sure that's really too slow, before worrying >>about it too much. >> >>Also, I according to the above function, the right answer is: >> >>[0, 1, 2, 1, 2, 1] >> >> >>Best, >> >> >>Travis >> >> >> >> >> >>This SF.Net email is sponsored by xPML, a groundbreaking scripting >>language >>that extends applications into web and mobile media. Attend the live >>webcast >>and join the prime developer group breaking into this new coding >>territory! >>http://sel.asus.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >>_______________________________________________ >>Numpydiscussion mailing list >>Numpydiscussion@... >>https://lists.sourceforge.net/lists/listinfo/numpydiscussion >> >> >> >> > > > > >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.asus.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Numpydiscussion mailing list >Numpydiscussion@... >https://lists.sourceforge.net/lists/listinfo/numpydiscussion > > > > 
From: Norbert Nemec <Norbert.N<emec.list@gm...>  20060330 14:13:32

Sorry, Travis, I missed your answer for a week... I confess, my efficiency concerns about the histogram routine are to some extent, of theoretical nature. However, given the widespread use of the function and considering the simplicity of the solution, I think it is still worth thinking about it: The current histogram routine is based on a "sort" of the incoming data. Quicksort is usually O(N log N), worst case O(N**2). Doing the histogram by simply counting is a simple O(N) procedure. The absolute cost of the quicksort algorithm is low, but the simple counting should be even lower, if done efficiently in C. What probably weighs heavier though, is the memory usage: sorting can either be done in place, destroying the original data, or requires a copy. Counting could be done even on an iterator without storing all the data. Lacking a comparable implementation of the counting algorithm, I have not done any actual speed comparisons. Why nobody ever found this inefficiency, I cannot say. Probably nobody ever had a real comparison how fast the histogram could be. Unless you are dealing with really huge data, the difference will not show up. Anyway, as I said, a solution should be simple to code once it is decided how to do it. Simply recoding the histogram routine itself in C would be the minimal solution. Implementing a more flexible counting routine that can be used in other contexts as well would certainly be more desirable, but I have no clear vision what that should look like. Greetings, Norbert Travis Oliphant wrote: > Norbert Nemec wrote: > >> I have a very much related problem: Not only that the idea described by >> Mads Ipsen does not work, but I could generally find no efficient way to >> do a "counting" of elements in an array, as it is needed for a >> histogram. >> > > This may be something we are lacking. > > It depends on what you mean by efficient, I suppose. The sorting > algorithms are very fast, and the histogram routines that are > scattered all over the place (including the histogram function in > numpy) has been in use for a long time, and you are the first person > to complain of its efficiency. That isn't to say your complaint may > not be valid, it's just that for most people the speed has been > sufficient. > >> What would instead be needed is a function that simply gives the count >> of occurances of given values in a given array: >> > > I presume you are talking of "integer" arrays, since > equalitycomparison of floatingpoint values is usually not very > helpful so most histograms on floatingpoint values are given in terms > of bins. Thus, the searchsorted function uses bins for it's > "counting" operation. > >> >> >>>>> [4,5,2,3,2,1,4].count([0,1,2,3,4,5]) >>>>> >>>> >> [0,1,2,1,1,2] >> >> > > > A count function for integer arrays could certainly be written using a > Cloop. But, I would first just use histogram([4,5,2,3,2,1,4], > [0,1,2,3,4,5]) and make sure that's really too slow, before worrying > about it too much. > > Also, I according to the above function, the right answer is: > > [0, 1, 2, 1, 2, 1] > > > Best, > > > Travis > > > > >  > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.asus.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Numpydiscussion mailing list > Numpydiscussion@... > https://lists.sourceforge.net/lists/listinfo/numpydiscussion > > 
From: Vicent Mas (V+) <vmas@ca...>  20060330 11:45:49

El S=E1bado 25 Marzo 2006 13:59, Ajith Prasad (OFN) escribi=F3: > I posted this problem  arising from my work at the local university >  some years back in comp.lang.python and received a solution that > did not require the use of matrix algebra. The solution was: > > def enrollment(year, intake, survivalrate): > return sum([intake[yeari]*rate > for i, rate in enumerate(survivalrate)]) > > > I would welcome help in formulating a solution using NumPy. Thanks in > advance for any suggestion. > > > The Problem: > > > The enrolment E(n) of an institution at the beginning of year n is > the sum of the intake for year n, I(n), and the survivors from the > intakes of previous r years. Thus, if s(1) is the 1year intake > survival rate, s(2) is the 2year survival rate, etc, we have: > > > E(n)=3D I(n)+I(n1)*s(1)+ I(n2)*s(2)+...+I(nr)*s(r) > E(n+1)=3D I(n+1)+I(n)*s(1)+I(n1)*s(2)+... +I(nr1)*s(r) > . > . > . > E(n+k)=3D I(n+k)+I(n+k1)*s(1)+I(n+k2)*s(2)+...+I(n+kr)*s(r) > > > Given: > (a) the actual intakes for the current and previous r years, I(n), > I(n1),I(n2),..,I(nr), and the planned intakes for the next n+k > years: I(n+1), I(n+2),..., I(n+k), we have the intake vector I =3D > (I(nr), I(nr1),...,I(n),I(n+1),..., I(n+k)); and > (b) the survival rate vector, s =3D (1,s(1), s(2),...,s(r)) > Find: > The k*1 enrolment projection column vector, E =3D > (E(n+1),E(n+2),...,E(n+k)) in terms of a k*(r+1) matrix P (derived > from I) and the (r+1)*1 column vector, s. > > > I =3D P*s > > > Is there a compact Python representation of the relevant matrix P > where: > > > P =3D [I(n+1) I(n) I(n1).. . I(nr) > I(n+2) I(n+1) I(n)... I(nr1) > . > . > I(n+k) I(n+k1) I(n+k2)... I(n+kr)] > > > If I've understood properly you simply want to multiply two matrices. Just store your intakes in an array, your survival rates in another one=20 and call matrixmultiply (or dot). The following interactive session=20 shows it: In [1]: import numarray In [2]: p_matrix =3D=20 numarray.array([1,2,3,4,5,10,1,2,3,4,20,10,1,2,3,30,20,10,1,2], ...: shape=3D(4, 5), type=3D"Int8") In [3]: sr_array =3D numarray.array([1, 0.2, 0.15, 0.25, 0.3]) In [4]: enrolment_array =3D numarray.matrixmultiply(p_matrix, sr_array) In [5]: print p_matrix [[ 1 2 3 4 5] [10 1 2 3 4] [20 10 1 2 3] [30 20 10 1 2]] In [6]: print sr_array [ 1. 0.2 0.15 0.25 0.3 ] In [7]: print enrolment_array [ 4.35 12.45 23.55 36.35] Regards =2D=20 :: \ / Vicent Mas http://www.carabos.com 0;0=09 / \ C=E1rabos Coop. Enjoy Data V V " " 
From: Pearu Peterson <pearu@sc...>  20060330 08:37:25

On Wed, 29 Mar 2006, David Huard wrote: > I would like to freeze some code in order to run it on machines without > installing all the modules I use. I compiled Python 2.4.3 from source and > rebuilt numpy. When I try to freeze the following code : > > #test.py > from numpy import mean, rand > x = rand(1000) > print mean(x) > > with > > python /usr/share/doc/python2.4/examples/Tools/freeze/freeze.py test.py > make > > I get the following error message : > > No scipystyle subpackage 'testing' found in n:u:m:p:y. Ignoring. > No scipystyle subpackage 'core' found in n:u:m:p:y. Ignoring. > No scipystyle subpackage 'lib' found in n:u:m:p:y. Ignoring. > No scipystyle subpackage 'linalg' found in n:u:m:p:y. Ignoring. > No scipystyle subpackage 'dft' found in n:u:m:p:y. Ignoring. > No scipystyle subpackage 'random' found in n:u:m:p:y. Ignoring. > No scipystyle subpackage 'f2py' found in n:u:m:p:y. Ignoring. > Traceback (most recent call last): > File "test.py", line 1, in ? > from numpy import mean, rand > File "/usr/lib/python2.4/sitepackages/numpy/__init__.py", line 44, in ? > __doc__ += pkgload.get_pkgdocs() > File "/usr/lib/python2.4/sitepackages/numpy/_import_tools.py", line 320, > in get_pkgdocs > retstr = self._format_titles(titles) +\ > File "/usr/lib/python2.4/sitepackages/numpy/_import_tools.py", line 283, > in _format_titles > max_length = max(lengths) > ValueError: max() arg is an empty sequence I have fixed these errors in svn. Now I get File "/usr/local/lib/python2.4/sitepackages/numpy/core/numerictypes.py", line 85, in ? from multiarray import typeinfo, ndarray, array, empty ImportError: cannot import name typeinfo I checked that given multiarray comes from Numeric. It looks like freeze is not able to freeze extension modules that are not in path. Pearu 
From: Sebastian Haase <haase@ms...>  20060330 04:53:54

Hi, Please consider this a bug report (I have never filed a bug with SF...) I just don't want this falling through the cracks... Again: na.maximum.reduce(arr,3) returned the transpose of what it should have given ( na.maximum.reduce(arr,1) in my case  see below for details ) Thanks, Sebastian haase Sebastian Haase wrote: > On Wednesday 22 March 2006 05:32, Paul Barrett wrote: >> On 3/21/06, Sebastian Haase <haase@...> wrote: > <snip> >> The above behavior for maximum.reduce looks consistent to me. >> >> The reduce axis for examples 1 and 2 above is 0, so maximum is comparing >> arrays [[0 1] [2 3]] and [[4 5] [6 7]], which gives [[4 5] [6 7]]. Example >> 3 is comparing arrays [[0 1] [4 5]] and [[2 3] [6 7]], giving [[2 3] [6 >> 7]]. And the last example is comparing arrays [[0 2] [4 6]] and [[1 3] [5 >> 7]], giving [[1 3] [5 7]]. >> >> I think it depends on how you look at the shape of the array. >> >>  Paul > Sorry > I did the test wrong  >>>> na.maximum.reduce(q,2) > [[1 3] > [5 7]] >>>> na.maximum.reduce(q,1) > [[1 3] > [5 7]] > So it obviously works as advertised. > > The array where I noticed the transpose behaviour was really of shape > 32,15,521,512 and my command was na.maximum.reduce(arr,3) which "looked" > tranpose to what I got with na.maximum.reduce(arr,1). > I using numarray for image analysis and the array might have been a memmaped > image file. I'm just worried because I found an "accidental transpose bug" > on type conversion a few years back (see mailing list)... > ( I forgot to say that I running Python 2.2 and numarray version '1.4.0' ) > > I just reran the test with python2.4 and arr=arr.copy() [which should give a > nonmemmap version of arr] > >>>> arrM = na.maximum.reduce(arr,3) >>>> arrMt = na.transpose(arrM,(0,2,1)) >>>> arrM1= na.maximum.reduce(arr,1) >>>> U.mmms(arrM1arrMt) # returns min,max,mean,stddev > (0, 0, 0.0, 0.0) > > So it definitely transposes the last two axes ! Maybe the bug shows up on > rank >=4 !?  which is the case Robert tested. > > Thanks, > Sebastian Haase > 
From: Piotr Luszczek <luszczek@cs...>  20060330 03:25:17

On Wednesday 29 March 2006 19:03, Zachary Pincus wrote: > Can anyone tell me what the difference between numpy.linalg.eig and > numpy.linalg.eigh is? (Ditto for eigvals and eigvalsh.) > > Thanks, > > Zach eig() is for nonsymmetric matrices and eigh() is for symmetric (or hermitian matrices). The former most likely will return complex eigen values. The latter always returns real eigen values. eig() is slower and numerically less reliable (it calls LAPACK's DGEEV and ZGEEV). Even for symmetric matrices it can produce complex eigen pairs due to numerical roundoff. eigh() can be called with an optional parameter UPLO that tells the routine which triangle of the matrix it should operate on. That triangle is destroyed and the other triangle is left untouched. Piotr 
From: <aeronautic@hr...>  20060330 03:21:28

From: Zachary Pincus <zpincus@st...>  20060330 00:03:49

Can anyone tell me what the difference between numpy.linalg.eig and numpy.linalg.eigh is? (Ditto for eigvals and eigvalsh.) Thanks, Zach 