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: Dav Clark <dav@al...>  20060310 22:58:00

So mod_python 3.2(.8) included a major overhaul of the import mechanism. I'm still not sure what the problem is, and I think an 'import numpy' from sitepackages/numpy _shouldn't_ cause an error (though it does). But I can at least do my work. DC 
From: Dav Clark <dav@al...>  20060310 20:21:12

First  I realized I failed to include version numbers. I'm using numpy 0.9.5, and mod_python 3.1.4 and apache 2.0.54. Standard (I think) for red hat FC4 on an intel box. So, I've spent some time tracing through mod_python... the bad code is here, from the import_module def in mod_python/apache.py: parts = module_name.split('.') for i in range(len(parts)): f, p, d = imp.find_module(parts[i], path) try: mname = ".".join(parts[:i+1]) module = imp.load_module(mname, f, p, d) finally: if f: f.close() if hasattr(module, "__path__"): path = module.__path__ From a mod_python interpreter  all calls to import get replaced with import_module (to prevent reloads). The setting of the 'path' parameter in this way is (I think) invoking the same bug that causes the crash when imoporting numpy from ../sitepackages/numpy. Can anyone even replicate this? Should I crosspost this to mod_python? Cheers, Dav 
From: David Ian Brown <dbrown@uc...>  20060310 19:51:31

Hi Travis, Yes, now I see that I just wasn't looking closely enough at the the docs, that Numeric's getitem did have only one argument, and the docs have the arguments in the correct order both for the function and the macro. I was just confused by the fact that the macro has the arguments in the opposite order of the function. So the only problem was the missing 'f' in the macro. dave On Mar 9, 2006, at 10:28 PM, Travis Oliphant wrote: > David Ian Brown wrote: >>> >>> I have recently been engaged in updating the PyNIO module >>> (http://www.pyngl.ucar.edu/Nio.html) >>> to work with the NumPy C API. It was originally coded using the >>> Numeric's C API. >>> >>> In the process I have encountered what appear to me to be a couple >>> of bugs in the interface. They were relatively minor and not >>> difficult to work around, but you would probably like to know of >>> them if you don't already. >>> >>> In the NumPy version of arrayobject.h the macros PyArray_GETITEM and >>> PyArray_SETITEM >>> are defined in way that does not work. Here is the GETITEM macro: >>> >>> #define PyArray_GETITEM(obj,itemptr) \ >>> ((char *)itemptr, \ >>> (PyArrayObject *)obj); >>> > > Thank you very much for catching this. The introduction of 'f' was > more recent then the writing of these macros and so this error crept > in. I'm definitely glad to fix it. > >> Correction: actually "Guide to NumPy" has the 'getitem' function >> documented with the arguments ordered >> as implemented in NumPy (but still opposite from Numeric). Only the >> macro is documented opposite from >> its implementation. > > I think further clarification is needed. > First of all Numeric did not have macros. They just had function > pointers to getitem. Second, Numpy's function pointers to getitem and > setitem are almost exactly the same. The only difference is the > *addition* of another argument to both functions to allow the array to > be passed in (so that the size of the array and whether or not it's > wellbehaved can be known). > So, the order is *not* different in NumPy and Numeric, there is just > another argument needed. > The new macros introduced do have a different order (and I don't think > it's documented oppositely  it's perhaps not documented well at > all, however :) and so may be confusing). > > It is recommended to use the macros. They are > > PyArray_GETITEM(array, itemptr) > > Return a Python object corresponding to the item in the array at the > location itemptr. > > PyArray_SETITEM(array, itemptr, obj) > > Set object into the array at the memory pointed to by itemptr (an > attempt is made to convert to the right type if that is possible). > > Thanks for the report. > > 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: Francesc Altet <faltet@ca...>  20060310 18:19:52

Hi, I'm in a hurry, so not able to track this right down, but I have just checked the numpy SVN version of numpy and discovered that the 'i' entry for typeNA has disappeared: >>> numpy.__version__ '0.9.6.2214' >>> numpy.typeNA['i'] Traceback (most recent call last): File "<stdin>", line 1, in ? KeyError: 'i' >>> numpy.typeNA['l'] 'Int32' Cheers, =2D=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "" 
From: Paul Dubois <pfdubois@gm...>  20060310 15:06:46

It was a design decision: if an automatic conversion of a masked array to a numeric one is attempted, and there actually are masked values, it is logical to either: a. raise an exception, because there is no equivalent numeric array, or; b. fill the masked value with the fill value (b) suffers from a problem: the default fill value might not be appropriate for the use that is about to occur. My original conclusion was that it was better to choose (a) to force the user to explicitly do the conversion with x.fill(value) and pass THAT to whatever was going to consume it. I don't think I've changed my mind. On 10 Mar 2006 02:32:19 0800, Travis Oliphant <oliphant.travis@...> wrote: > > Sasha wrote: > > I would say it is an ma bug, but don't know how to fix it properly > > without changing numpy scalar arithmetic to call an enhanced version > > of __array__ and pass context in. > > > I think it was an array scalar bug. I've fixed it by always calling the > ufunc (which handles conversions to and from other objects better than > the array scalars were doing in the generic arithmetic code). > > The result is shorter code and symmetric handling of the > <array_scalar>*<masked array> vs. <masked array> * <array_scalar> case. > > I also changed the error to a warning for backward compatibility. > Calling __array__() on a masked array should succeed and we will assume > the user knows what they are doing. > > 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=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Numpydiscussion mailing list > Numpydiscussion@... > https://lists.sourceforge.net/lists/listinfo/numpydiscussion > > 
From: Travis Oliphant <oliphant.travis@ie...>  20060310 10:31:50

Sasha wrote: > I would say it is an ma bug, but don't know how to fix it properly > without changing numpy scalar arithmetic to call an enhanced version > of __array__ and pass context in. > I think it was an array scalar bug. I've fixed it by always calling the ufunc (which handles conversions to and from other objects better than the array scalars were doing in the generic arithmetic code). The result is shorter code and symmetric handling of the <array_scalar>*<masked array> vs. <masked array> * <array_scalar> case. I also changed the error to a warning for backward compatibility. Calling __array__() on a masked array should succeed and we will assume the user knows what they are doing. Travis 
From: Zachary Pincus <zpincus@st...>  20060310 05:33:34

Thanks for your reply, Travis. > Note that the __index__ PEP I wrote was just accepted and checked > in so in fact *all* numpy scalar types will be acceptable as > indices in Python2.5 (but we have to write the code for that still > in numpy). So, it's possible that something in Python 2.5 changed > is causing it not to work. > > This verywell could be a bug in the new implementation of __index__. The problem is that I can't reproduce this bug outside of numpy. If I go to the python people, they'll most likely say it's a numpy problem, unless I can show some other test case. Right now, all of the following classes work as indices in 2.5. The only thing that doesn't work is a raw numpy.int32 value. I'd be happy to file a bug report on python if I could figure out a test case. Zach Cases which work fine: class int_sublcass(int): pass class empty(object): pass class int_1(int, empty): pass class int_2(empty, int): pass class int_numpy_1(numpy.signedinteger, int): def __init__(self, i): int.__init__(self, i) class int_numpy_2(int, numpy.signedinteger): def __init__(self, i): int.__init__(self, i) l = [1,2,3] l[int_sublcass(1)] l[int_1(1)] l[int_2(1)] l[int_numpy_1(1)] l[int_numpy_2(1)] 
From: Travis Oliphant <oliphant.travis@ie...>  20060310 05:28:30

David Ian Brown wrote: >> >> I have recently been engaged in updating the PyNIO module >> (http://www.pyngl.ucar.edu/Nio.html) >> to work with the NumPy C API. It was originally coded using the >> Numeric's C API. >> >> In the process I have encountered what appear to me to be a couple >> of bugs in the interface. They were relatively minor and not >> difficult to work around, but you would probably like to know of them >> if you don't already. >> >> In the NumPy version of arrayobject.h the macros PyArray_GETITEM and >> PyArray_SETITEM >> are defined in way that does not work. Here is the GETITEM macro: >> >> #define PyArray_GETITEM(obj,itemptr) \ >> ((char *)itemptr, \ >> (PyArrayObject *)obj); >> Thank you very much for catching this. The introduction of 'f' was more recent then the writing of these macros and so this error crept in. I'm definitely glad to fix it. > Correction: actually "Guide to NumPy" has the 'getitem' function > documented with the arguments ordered > as implemented in NumPy (but still opposite from Numeric). Only the > macro is documented opposite from > its implementation. I think further clarification is needed. First of all Numeric did not have macros. They just had function pointers to getitem. Second, Numpy's function pointers to getitem and setitem are almost exactly the same. The only difference is the *addition* of another argument to both functions to allow the array to be passed in (so that the size of the array and whether or not it's wellbehaved can be known). So, the order is *not* different in NumPy and Numeric, there is just another argument needed. The new macros introduced do have a different order (and I don't think it's documented oppositely  it's perhaps not documented well at all, however :) and so may be confusing). It is recommended to use the macros. They are PyArray_GETITEM(array, itemptr) Return a Python object corresponding to the item in the array at the location itemptr. PyArray_SETITEM(array, itemptr, obj) Set object into the array at the memory pointed to by itemptr (an attempt is made to convert to the right type if that is possible). Thanks for the report. Travis 
From: Travis Oliphant <oliphant.travis@ie...>  20060310 05:07:07

Zachary Pincus wrote: > Hi folks, > > I'm using a fresh build of numpy and python 2.5, both checked out from > SVN yesterday. It seems that numpy.argmax() and ndarray.argmax() are > now returning 'int32scalar' types instead of 'int' types. This has always been the case for numpy so it's not new. > Despite the fact that the former seems to inherit from the latter, > 'int32scalar' types do not appear to be usable as indices into python > lists. This is new and is a Python 2.5 problem it would appear. > > Anyhow, I'm not sure if this is a python 2.5 regression, or a problem > in all versions of python that's exposed by this behavior, or a numpy > problem. > Note that the __index__ PEP I wrote was just accepted and checkedin so in fact *all* numpy scalar types will be acceptable as indices in Python2.5 (but we have to write the code for that still in numpy). So, it's possible that something in Python 2.5 changed is causing it not to work. This verywell could be a bug in the new implementation of __index__. Travis 
From: Sasha <ndarray@ma...>  20060310 01:32:39

I would say it is an ma bug, but don't know how to fix it properly without changing numpy scalar arithmetic to call an enhanced version of __array__ and pass context in. The core problem can be demonstrated by the following session: >>> from numpy import * >>> x =3D ma.array([1],mask=3D[1]) >>> int_(1)*x Traceback (most recent call last): File "<stdin>", line 1, in ? File ".../numpy/core/ma.py", line 622, in __array__ raise MAError, \ numpy.core.ma.MAError: Cannot automatically convert masked array to numeric because data is masked in one or more locations. Note that x*int_(1) works as expected. This is so because python dispatches multiplication to int.__mul__ rather than ma.array.__mul__ if int_(1) is the first multiplicand. I've fixed a similar problem for array*ma.array case and array(1)*x works in the current version of numpy. I will not have time to work on this before the weekend, so if someone is motivated enought to fix this bug before the upcoming release, please take a look at http://projects.scipy.org/scipy/numpy/wiki/MaskedArray ("Ufuncs and Masked Arrays"). It should be straightforward to generalize that approach for array scalars. On 3/9/06, Eric Firing <efiring@...> wrote: > Travis et al., > > Jeff Whitaker found that the imaged_masked.py example (with the colorbar > line uncommented) in matplotlib 0.87 triggered a numpy bugthe script > works normally with Numeric and numarray. He committed a workaround to > mpl svn, but I suspect you may want to track it down and squash it in > numpy before the next release. It is not clear to me whether it is > really in ma, or merely revealed by ma. The attached script triggers > the bug. > > Thanks. > > Eric > > > > 
From: David Ian Brown <dbrown@uc...>  20060310 00:58:13

On Mar 9, 2006, at 4:56 PM, David Ian Brown wrote: > > Hi Travis and NumPy developers, > > I have recently been engaged in updating the PyNIO module > (http://www.pyngl.ucar.edu/Nio.html) > to work with the NumPy C API. It was originally coded using the > Numeric's C API. > > In the process I have encountered what appear to me to be a couple of > bugs in the interface. They were relatively minor and not difficult > to work around, but you would probably like to know of them if you > don't already. > > In the NumPy version of arrayobject.h the macros PyArray_GETITEM and > PyArray_SETITEM > are defined in way that does not work. Here is the GETITEM macro: > > #define PyArray_GETITEM(obj,itemptr) \ > ((char *)itemptr, \ > (PyArrayObject *)obj); > > When I try to use this macro in my code I get a compile error, because > 'getitem' is not a member of NumPy's > PyArray_Descr struct. Instead it is further nested within the struct > member 'PyArray_ArrFuncs *f'. > So, unless I misunderstand, the macro needs to access the 'getitem' > function as > > ((PyArrayObject *)(obj))>descr>f>getitem(... > > The other issue with 'getitem', apparently the actual method, not just > this macro, is that the 2 arguments are > ordered oppositely from what is stated in "Guide To NumPy", as well > as from the way this method was > implemented in Numeric. Notice in the macro (and in NumPy's > implementation), 'itemptr' is first and > the PyArrayObject pointer is second. The documentation and Numeric has > it the other way around. Correction: actually "Guide to NumPy" has the 'getitem' function documented with the arguments ordered as implemented in NumPy (but still opposite from Numeric). Only the macro is documented opposite from its implementation. > > I hope this is useful. > dave > > > >  > 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 