Re: [Numpy-discussion] getting numPy happening for sciPy
David Cournapeau wrote: Robert Kern wrote: David Cournapeau wrote: I am willing to volunteer for the scipy part: I have quite extensive experience with building on linux now, and I can now build on windows without too much difficulties (I mean hardware-wise). Concerning the release date: it basically means giving enough time to solve the current bugs, right ? There are too many. Build bugs should be fixed and anything that impairs the functioning of whole packages. Incorporating patches already submitted would be the next priority. Fixing isolated little bugs can be pushed back. I thought that releasing something before the end of summer would be a good release date: a new release is available before the beginning of the new university year. Would you agree on a date like end of august ? (if I become the release manager, this is also more compatible with my schedule). For the bugs, I was not talking about all the bugs in trac, but the ones in 0.5.3 milestone (10-11 bugs, I think). David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion Actually 8 tickets http://projects.scipy.org/scipy/scipy/query?status=newstatus=assignedstatus=reopenedmilestone=0.5.3+Release Ticket #389 can be closed. It's already fixed. AFAIK Dmitrey is working on ticket #464. I didn't check the patch by bart for ticket #360. IMHO ticket #406 is not so important for 0.5.3 release. I cannot reproduce the problem concerning #401. It is Mac specific problem. Am I missing something ? Nils ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] build on windows 64-bit platform
Stefan van der Walt wrote: Hi all, The build is still failing on winXP 64-bit, as shown on the buildbot page http://buildbot.scipy.org/Windows%20XP%20x86_64%20MSVC/builds/25/step-shell/0 with the error AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root' Could someone familiar with the MSVC compilers please take a look? I think the problem is in the environment of the buildbot machine `Windows XP x86_64 MSVC`. Basically, I would try setting the following environment variables in this machine: DISTUTILS_USE_SDK and MSSdk Then the build might succeed. For more information, read the code in Python distutils/msvccompiler.py file. Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] build on windows 64-bit platform
On Fri, Jul 27, 2007 at 04:54:45PM +0200, Pearu Peterson wrote: Stefan van der Walt wrote: Hi all, The build is still failing on winXP 64-bit, as shown on the buildbot page http://buildbot.scipy.org/Windows%20XP%20x86_64%20MSVC/builds/25/step-shell/0 with the error AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root' Could someone familiar with the MSVC compilers please take a look? I think the problem is in the environment of the buildbot machine `Windows XP x86_64 MSVC`. Basically, I would try setting the following environment variables in this machine: DISTUTILS_USE_SDK and MSSdk Then the build might succeed. For more information, read the code in Python distutils/msvccompiler.py file. Thanks, Pearu -- I'll take a look. Why the uninformative error message, though? Isn't distutils supposed to automagically detect the MSVC compiler? Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Bug with MA and reduce?
I have ma.minimum.reduce return a minimum value that does not exist in the array. The following code prints -1 as the minimum of the MA, I believe it should be 1. import numpy shape = (100) data = numpy.ones(shape, numpy.int16) data[2:40] = 3 # dummy data data[45:70] = -999 # null values mask = numpy.ma.make_mask_none(data.shape) mask[data == -999] = True ma = numpy.ma.MaskedArray(data, mask = mask) min = numpy.ma.minimum.reduce(ma,0) print min Am I doing something really stupid here? Ludwig ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] build on windows 64-bit platform
Hi all, The build is still failing on winXP 64-bit, as shown on the buildbot page http://buildbot.scipy.org/Windows%20XP%20x86_64%20MSVC/builds/25/step-shell/0 with the error AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root' Could someone familiar with the MSVC compilers please take a look? Thanks Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] build on windows 64-bit platform
Stefan van der Walt wrote: On Fri, Jul 27, 2007 at 04:54:45PM +0200, Pearu Peterson wrote: Stefan van der Walt wrote: Hi all, The build is still failing on winXP 64-bit, as shown on the buildbot page http://buildbot.scipy.org/Windows%20XP%20x86_64%20MSVC/builds/25/step-shell/0 with the error AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root' Could someone familiar with the MSVC compilers please take a look? I think the problem is in the environment of the buildbot machine `Windows XP x86_64 MSVC`. Basically, I would try setting the following environment variables in this machine: DISTUTILS_USE_SDK and MSSdk Then the build might succeed. For more information, read the code in Python distutils/msvccompiler.py file. Thanks, Pearu -- I'll take a look. Why the uninformative error message, though? Isn't distutils supposed to automagically detect the MSVC compiler? I think this is bug in Python distutils/msvccompiler.py. Let me know if defining these variables work, then we can implement a workaround or show more informative messages on failure. Note that one may get such an error only on AMD64 platform, the MSVC compiler uses other code on Intel machines and that works automagically indeed. Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug with MA and reduce?
This is a follow-up to an earlier mail that reported a suspected bug in the reduce/minimum operation of numpy.ma. I have tried the same code with the scipy sandbox maskedarray implementation and that gives me the correct output. For comparison: # import numpy.core.ma as MA import maskedarray as MA shape = (100) data = numpy.ones(shape, numpy.int16) data[2:40] = 3 data[45:70] = -999 mask = MA.make_mask_none(data.shape) mask[data == -999] = True ma = MA.MaskedArray(data, mask = mask) min = MA.minimum.reduce(ma,0) print min With maskedarray I get, as expected 1, with numpy.core.ma I get -1, a value that is not in the array. I am using Python 2.44 on XP, the maskedarray is the svn latest, the numpy.core.ma was 1.0.2, but I have tested it with only the current svn version of ma.py and it produces the wrong output. Ludwig On 27/07/07, Ludwig M Brinckmann [EMAIL PROTECTED] wrote: I have ma.minimum.reduce return a minimum value that does not exist in the array. The following code prints -1 as the minimum of the MA, I believe it should be 1. import numpy shape = (100) data = numpy.ones (shape, numpy.int16) data[2:40] = 3 # dummy data data[45:70] = -999 # null values mask = numpy.ma.make_mask_none(data.shape) mask[data == -999] = True ma = numpy.ma.MaskedArray(data, mask = mask) min = numpy.ma.minimum.reduce(ma,0) print min Am I doing something really stupid here? Ludwig ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] getting numPy happening for sciPy
On Jul 27, 2007, at 2:42 AM, Nils Wagner wrote: I cannot reproduce the problem concerning #401. It is Mac specific problem. Am I missing something ? I can't reproduce this problem either. I just yesterday built scipy from SVN on two different OS X 10.4.10 boxes, one using the fortran compiler from hpc.sourceforge.net (not the latest 2007 release, but the december 2006 one), and the other using the compiler from r.research.att.com/tools. Everything else was similar, and everything worked fine with regard to ticket 401. On the other hand, when I tried to compile scipy using the latest (2007-05) gfortran from hpc.sourceforge.net, I got bizarre link errors about MACOSX_DEPLOYMENT_TARGET being set incorrectly. (See previous email here http://projects.scipy.org/pipermail/scipy-user/ 2007-June/012542.html ). Interestingly, with the earlier version of gfortran from hpc.sourceforge.net, and with the r.research.att.com/ tools version, this problem does not arise. Anyhow, my point is that there are still odd linker errors (as in ticket 401) lurking that may or may not have anything to do with scipy per se, but might have to do with odd and perhaps buggy builds of gfortran. Feh -- I wish Apple would just start including a fortran compiler with the rest of their dev tools. The situation otherwise is not good. Zach ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug with MA and reduce?
Ludwig M Brinckmann wrote: This is a follow-up to an earlier mail that reported a suspected bug in the reduce/minimum operation of numpy.ma http://numpy.ma. I have tried the same code with the scipy sandbox maskedarray implementation and that gives me the correct output. For comparison: Yes, I think I see where the bug is coming from in numpy.ma; it is assigning fill values for min and max operations as if all integer types were the system default integer. Maskedarray uses a dictionary to assign fill values for these operations, so it correctly takes into account the type. Maskedarray has had much more recent development and maintenance than ma, and may replace it in numpy 1.1. I have not seen any objections to this proposal. From my standpoint, the sooner it happens, the better--unless someone raises a fundamental objection to the approach maskedarray is taking. Eric # import numpy.core.ma http://numpy.core.ma as MA import maskedarray as MA shape = (100) data = numpy.ones(shape, numpy.int16) data[2:40] = 3 data[45:70] = -999 mask = MA.make_mask_none (data.shape) mask[data == -999] = True ma = MA.MaskedArray(data, mask = mask) min = MA.minimum.reduce(ma,0) print min With maskedarray I get, as expected 1, with numpy.core.ma http://numpy.core.ma I get -1, a value that is not in the array. I am using Python 2.44 on XP, the maskedarray is the svn latest, the numpy.core.ma http://numpy.core.ma was 1.0.2, but I have tested it with only the current svn version of ma.py and it produces the wrong output. Ludwig On 27/07/07, *Ludwig M Brinckmann* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have ma.minimum.reduce return a minimum value that does not exist in the array. The following code prints -1 as the minimum of the MA, I believe it should be 1. import numpy shape = (100) data = numpy.ones (shape, numpy.int16) data[2:40] = 3 # dummy data data[45:70] = -999 # null values mask = numpy.ma.make_mask_none(data.shape) mask[data == -999] = True ma = numpy.ma.MaskedArray(data, mask = mask) min = numpy.ma.minimum.reduce(ma,0) print min Am I doing something really stupid here? Ludwig ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] build on windows 64-bit platform
Ok, I have now enabled DISTUTILS_USE_SDK for AMD64 Windows platform and it seems working.. However, the build still fails but now the reason seems to be related to numpy ticket 164: http://projects.scipy.org/scipy/numpy/ticket/164 Pearu I think buildbot is great! ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] build on windows 64-bit platform
On Sat, Jul 28, 2007 at 12:54:52AM +0200, Pearu Peterson wrote: Ok, I have now enabled DISTUTILS_USE_SDK for AMD64 Windows platform and it seems working.. Fantastic, thanks! However, the build still fails but now the reason seems to be related to numpy ticket 164: http://projects.scipy.org/scipy/numpy/ticket/164 I'll ask Albert whether he would have a look at it again. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] build on windows 64-bit platform
Hello all On Sat, 28 Jul 2007, Stefan van der Walt wrote: On Sat, Jul 28, 2007 at 12:54:52AM +0200, Pearu Peterson wrote: Ok, I have now enabled DISTUTILS_USE_SDK for AMD64 Windows platform and it seems working.. Fantastic, thanks! However, the build still fails but now the reason seems to be related to numpy ticket 164: http://projects.scipy.org/scipy/numpy/ticket/164 I'll ask Albert whether he would have a look at it again. Let's see. Using this build log: http://buildbot.scipy.org/Windows%20XP%20x86_64%20MSVC/builds/31/step-shell/0 numpy\core\src\umathmodule.c.src(73) : warning C4273: 'logf' : inconsistent dll linkage numpy\core\src\umathmodule.c.src(74) : warning C4273: 'sqrtf' : inconsistent dll linkage Judging from the math.h on my 32-bit system, these declarations should look like this: float __cdecl logf(float); float __cdecl sqrtf(float); but they're missing the __cdecl in the NumPy code. Somewhere a macro needs to be defined to __cdecl on Windows (and left empty on other platforms) and including in the NumPy declarations. numpy\core\src\umathmodule.c.src(604) : warning C4013: 'fabsf' undefined; assuming extern returning int numpy\core\src\umathmodule.c.src(604) : warning C4013: 'hypotf' undefined; assuming extern returning int Judging from the patch attached to ticket #164, these functions aren't available for some reason. Maybe check the header to see if there's a way to turn them on using some preprocessor magic. If not, do what the patch does. numpy\core\src\umathmodule.c.src(604) : warning C4244: 'function' : conversion from 'int' to 'float', possible loss of data A cast should suppress this warning. numpy\core\src\umathmodule.c.src(625) : warning C4013: 'rintf' undefined; assuming extern returning int Add this function like the patch does. numpy\core\src\umathmodule.c.src(625) : warning C4244: '=' : conversion from 'int' to 'float', possible loss of data numpy\core\src\umathmodule.c.src(626) : warning C4244: '=' : conversion from 'int' to 'float', possible loss of data numpy\core\src\umathmodule.c.src(632) : warning C4244: 'initializing' : conversion from 'int' to 'float', possible loss of data numpy\core\src\umathmodule.c.src(641) : warning C4244: 'initializing' : conversion from 'int' to 'float', possible loss of data numpy\core\src\umathmodule.c.src(1107) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data numpy\core\src\umathmodule.c.src(1107) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data numpy\core\src\umathmodule.c.src(1107) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data numpy\core\src\umathmodule.c.src(1107) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data numpy\core\src\umathmodule.c.src(1349) : warning C4244: '=' : conversion from 'npy_longlong' to 'double', possible loss of data numpy\core\src\umathmodule.c.src(1350) : warning C4244: '=' : conversion from 'npy_longlong' to 'double', possible loss of data numpy\core\src\umathmodule.c.src(1349) : warning C4244: '=' : conversion from 'npy_ulonglong' to 'double', possible loss of data numpy\core\src\umathmodule.c.src(1350) : warning C4244: '=' : conversion from 'npy_ulonglong' to 'double', possible loss of data More casts probably. numpy\core\src\umathmodule.c.src(1583) : warning C4146: unary minus operator applied to unsigned type, result still unsigned numpy\core\src\umathmodule.c.src(1583) : warning C4146: unary minus operator applied to unsigned type, result still unsigned numpy\core\src\umathmodule.c.src(1583) : warning C4146: unary minus operator applied to unsigned type, result still unsigned Potential bugs. Look closely at these. numpy\core\src\umathmodule.c.src(1625) : warning C4244: '=' : conversion from 'int' to 'float', possible loss of data Cast. numpy\core\src\umathmodule.c.src(2013) : warning C4013: 'frexpf' undefined; assuming extern returning int Add this function. numpy\core\src\umathmodule.c.src(2013) : warning C4244: '=' : conversion from 'int' to 'float', possible loss of data Cast probably. numpy\core\src\umathmodule.c.src(2030) : warning C4013: 'ldexpf' undefined; assuming extern returning int Add this function. numpy\core\src\umathmodule.c.src(2030) : warning C4244: '=' : conversion from 'int' to 'float', possible loss of data Cast probably. build\src.win32-2.5\numpy\core\__umath_generated.c(15) : error C2099: initializer is not a constant build\src.win32-2.5\numpy\core\__umath_generated.c(21) : error C2099: initializer is not a constant build\src.win32-2.5\numpy\core\__umath_generated.c(27) : error C2099: initializer is not a constant build\src.win32-2.5\numpy\core\__umath_generated.c(30) : error C2099: initializer is not a constant build\src.win32-2.5\numpy\core\__umath_generated.c(45) : error C2099: initializer is not a constant build\src.win32-2.5\numpy\core\__umath_generated.c(45) :
Re: [Numpy-discussion] build on windows 64-bit platform
Hello On Sat, 28 Jul 2007, Albert Strasheim wrote: float __cdecl logf(float); float __cdecl sqrtf(float); but they're missing the __cdecl in the NumPy code. Somewhere a macro needs to be defined to __cdecl on Windows (and left empty on other platforms) and including in the NumPy declarations. included numpy\core\src\umathmodule.c.src(632) : warning C4244: 'initializing' : conversion from 'int' to 'float', possible loss of data numpy\core\src\umathmodule.c.src(641) : warning C4244: 'initializing' : conversion from 'int' to 'float', possible loss of data More casts probably. Looks like initializing these values with a float value (e.g., 0.0f and not 0) will fix these. If it's hard to modify the code generate to do this, a cast should be fine. Cheers, Albert ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
