[Numpy-discussion] status of numpy 1.3.0
Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 The original plan was to release 1.3 at the end of November. At this point, we are going to have to push back the release date a bit. I would like to get 1.3 out ASAP, so I would like aim for the third week of December. This is how I see the current development trunk: * 2.6 compatablity (Linux 32- and 64-bit done, Windows 32-bit done, Mac 32-bit done) * Generalized Ufuncs (committed) * Ufunc clean-up (committed) * Refactoring numpy.core math configuration (?? bump to 1.4 ??) * Improvements to build warnings (?? bump to 1.4 ??) * Histogram (committed) * NumPy testing improvements (http://projects.scipy.org/scipy/numpy/ticket/957) * Documentation improvements * MaskedArray improvements * Bugfixes Am I missing anything? Is there anything else that we should get in before releasing 1.3? Does it seem reasonable that we could release 1.3 during the third week of December? Who will have time to work on NumPy for the next month? Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
Jarrod Millman wrote: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 For completeness, we were wondering with Jarrod if the main focus of 1.3 could be python 2.6 compatibility (plus what is already in, of course). This is mainly a concern on Mac OS X and Windows (numpy seems to build and work OK on 2.6 on linux last time I tried). The rationale was that although python 2.6 is not really a must have compared to 2.5 for most usage of numpy/scipy, since people are now directed to python 2.6 on python.org for windows and mac os X installs, getting it working on 2.6. ASAP would avoid too much trouble for newcomers. The original plan was to release 1.3 at the end of November. At this point, we are going to have to push back the release date a bit. I would like to get 1.3 out ASAP, so I would like aim for the third week of December. This is how I see the current development trunk: * 2.6 compatablity (Linux 32- and 64-bit done, Windows 32-bit done, Mac 32-bit done) A small summary of the issues: I don:t know the status on Mac OS X for python 2.6 - last time I tried, after having installed python 2.6, my installation was broken, and numpy had many trouble, but that may well be my own mistake. Since many developers are on Mac OS X, I guess any problem would be quickly fixed. On Windows: numpy.distutils should now build a working numpy with mingw, as long as the official binary for python 2.6 is built (I won:t go into the details, but python 2.6 lacks some useful build info for numpy to be reliably built with mingw for an arbitrary build - I am working on an upstream patch , but this is unlikely to be available before python 2.7/python 3k). Windows 64 is a PITA, because we can:t use any mingw or cygwin-based toolchain (cygwin only supports 32 bits, mingw is experimental for 64 bits, and not even officially a part of the mingw project AFAIK). It also looks like ATLAS cannot be built on 64 bits, too, since it requires cygwin on windows, and ATLAS configuration fails right at the beginning when I tried the 32 bits cywgin. Assuming I am the only one working on this, I don:t see much hope to see more than a simple numpy built with lapack-lite. This could be useful for people who use numpy for matplotlib, for example; not sure if it worths the trouble. * Refactoring numpy.core math configuration (?? bump to 1.4 ??) This has been committed already * Improvements to build warnings (?? bump to 1.4 ??) Some has been committed as well, but this has no consequence on distutils-based build (the warnings are only emitted with -W, which distutils does not use by default). David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
A Monday 24 November 2008, David Cournapeau escrigué: Jarrod Millman wrote: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 For completeness, we were wondering with Jarrod if the main focus of 1.3 could be python 2.6 compatibility (plus what is already in, of course). This is mainly a concern on Mac OS X and Windows (numpy seems to build and work OK on 2.6 on linux last time I tried). The rationale was that although python 2.6 is not really a must have compared to 2.5 for most usage of numpy/scipy, since people are now directed to python 2.6 on python.org for windows and mac os X installs, getting it working on 2.6. ASAP would avoid too much trouble for newcomers. Not only newcomers, we all know people that likes to have the latest software in their machines even, as you said, 2.6 is not a big step forward in terms of new functionality. So +1 for having support for 2.6 ASAP. Cheers, -- Francesc Alted ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
Well, talking about support to 2.6: When using explicit outputs for some functions (eg, ma.max, ma.min...), a value that should be masked is transformed into np.nan when the explicit output is not a ma.MaskedArray. That worked great in 2.5, with np.nan automatically transformed when the explicit output had a int dtype. With 2.6, a ValueError is raised instead, as np.nan can no longer be casted to int. What should be the recommended behavior ? Raise a ValueError or some other exception, or silently replace np.nan by some value acceptable by int dtype (0, or something else) ? On Nov 24, 2008, at 8:57 AM, Francesc Alted wrote: A Monday 24 November 2008, David Cournapeau escrigué: Jarrod Millman wrote: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 For completeness, we were wondering with Jarrod if the main focus of 1.3 could be python 2.6 compatibility (plus what is already in, of course). This is mainly a concern on Mac OS X and Windows (numpy seems to build and work OK on 2.6 on linux last time I tried). The rationale was that although python 2.6 is not really a must have compared to 2.5 for most usage of numpy/scipy, since people are now directed to python 2.6 on python.org for windows and mac os X installs, getting it working on 2.6. ASAP would avoid too much trouble for newcomers. Not only newcomers, we all know people that likes to have the latest software in their machines even, as you said, 2.6 is not a big step forward in terms of new functionality. So +1 for having support for 2.6 ASAP. Cheers, -- Francesc Alted ___ 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] status of numpy 1.3.0
On Mon, Nov 24, 2008 at 4:34 AM, Jarrod Millman [EMAIL PROTECTED]wrote: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 The original plan was to release 1.3 at the end of November. At this point, we are going to have to push back the release date a bit. I would like to get 1.3 out ASAP, so I would like aim for the third week of December. This is how I see the current development trunk: * 2.6 compatablity (Linux 32- and 64-bit done, Windows 32-bit done, Mac 32-bit done) * Generalized Ufuncs (committed) The generalized ufunc tests have a blas linkage problem at the moment. I've commented out the call/build code to work on other things but it need to be fixed for release. The problem is finding the proper name in the library to link to and is likely one of those _ fortran thingies. I think the fix can probably be found in the the lapack_lite module. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
David Cournapeau wrote: Windows 64 is a PITA, ... I don:t see much hope to see more than a simple numpy built with lapack-lite. This could be useful for people who use numpy for matplotlib, for example; not sure if it worths the trouble. I think there is a great deal of use for it beyond simple MPL use -- I hardly ever use the LAPACK stuff. Granted, I don't use Win64 either... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] status of numpy 1.3.0
A Monday 24 November 2008, Jarrod Millman escrigué: Now that scipy 0.7.0b1 has been tagged, I wanted to start planning for the NumPy 1.3.0: http://projects.scipy.org/scipy/numpy/milestone/1.3.0 The original plan was to release 1.3 at the end of November. At this point, we are going to have to push back the release date a bit. I would like to get 1.3 out ASAP, so I would like aim for the third week of December. This is how I see the current development trunk: * 2.6 compatablity (Linux 32- and 64-bit done, Windows 32-bit done, Mac 32-bit done) * Generalized Ufuncs (committed) * Ufunc clean-up (committed) * Refactoring numpy.core math configuration (?? bump to 1.4 ??) * Improvements to build warnings (?? bump to 1.4 ??) * Histogram (committed) * NumPy testing improvements (http://projects.scipy.org/scipy/numpy/ticket/957) * Documentation improvements * MaskedArray improvements * Bugfixes Am I missing anything? Is there anything else that we should get in before releasing 1.3? Does it seem reasonable that we could release 1.3 during the third week of December? Who will have time to work on NumPy for the next month? Just went ahead and compiled the NumPy trunk version in a Windows platform, and although most of the nose tests of NumPy passes well (there are some failures, but seem harmless), my tests say there is an inconsistency in the positive limit value (+1.) of arctanh between 1.2.x and 1.3.x in trunk: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import numpy numpy.__version__ '1.2.1' numpy.arctanh(1.) 1.#INF numpy.isinf ufunc 'isinf' numpy.isinf(numpy.arctanh(1.)) True numpy.arctanh(-1.) -1.#INF numpy.isinf(numpy.arctanh(-1.)) True Python 2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import numpy numpy.__version__ '1.3.0.dev6085' numpy.arctanh(1.) nan numpy.isinf(numpy.arctanh(1.)) False numpy.arctanh(-1.) -inf numpy.isinf(numpy.arctanh(-1.)) True As you see, the trunk version returns ``nan`` for arctanh(1.), while 1.2.1 returns ``inf`` (the correct value). For arctanh(-1.) both versions correctly returns ``-inf``. I used the official binaries for 1.2.1, while I've used the MSVC 2008 (32-bit) for compiling trunk (the resuilting binaries works badly in both Windows XP 32-bit and Windows Vista 64-bit). My experiments on Linux shows that they both return ``+inf`` and ``-inf``, so it seems that this is a Windows specific issue. Should I file a ticket for this? Cheers, -- Francesc Alted ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
