Re: [Numpy-discussion] non-integer index misfeature?
I'd be happy with disallowing floating point index at all. I would think it was almost always a mistake. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] www.numpy.org home page
For people interested in the www.numpy.org home page: Jon Turner has officially transferred the www.numpy.org domain to NumFOCUS. Thank you, Jon for this donation and for being a care-taker of the domain-name. We have setup the domain registration to point to numpy.github.com and I've changed the CNAME in that repostiory to www.numpy.org I've sent an email to have the numpy.scipy.org page to redirect to www.numpy.org. The NumPy home page can still be edited in this repository: g...@github.com:numpy/numpy.org.git. Pull requests are always welcome --- especially pull requests that improve the look and feel of the web-page. Two of the content changes that we need to make a decision about is 1) whether or not to put links to books published (Packt publishing for example has offered a higher percentage of their revenues if we put a prominent link on www.numpy.org) 2) whether or not to accept Sponsored by links on the home page for donations to the project (e.g. Continuum Analytics has sponsored Ondrej release management, other companies have sponsored pull requests, other companies may want to provide donations and we would want to recognize their contributions to the numpy project). These decisions should be made by the NumPy community which in my mind are interested people on this list. Who is interested in this kind of discussion? We could have these discussions on this list or on the numfo...@googlegroups.com list and keep this list completely technical (which I prefer, but I will do whatever the consensus is). Best regards, -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
A big +1 from me --- but I don't have anyone I know using 2.4 anymore -Travis On Dec 13, 2012, at 10:34 AM, Charles R Harris wrote: Time to raise this topic again. Opinions welcome. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
As a point of reference, python 2.4 is on RH5/CentOS5. While RH6 is the current version, there are still enterprises that are using version 5. Of course, at this point, one really should be working on a migration plan and shouldn't be doing new development on those machines... Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
+1, if someone wants to use an older version of Python they can use an older version of numpy. On Thu, Dec 13, 2012 at 10:36 AM, Travis Oliphant tra...@continuum.iowrote: A big +1 from me --- but I don't have anyone I know using 2.4 anymore -Travis On Dec 13, 2012, at 10:34 AM, Charles R Harris wrote: Time to raise this topic again. Opinions welcome. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
On Thu, Dec 13, 2012 at 5:34 PM, Charles R Harris charlesr.har...@gmail.com wrote: Time to raise this topic again. Opinions welcome. I am ok if 1.7 is the LTS. I would even go as far as dropping 2.5 as well then (RHEL 6 uses python 2.6). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
On Thu, Dec 13, 2012 at 12:00 PM, David Cournapeau courn...@gmail.com wrote: snip I would even go as far as dropping 2.5 as well then (RHEL 6 uses python 2.6). +1 Skipper ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
Yes, and ditto for SciPy. With dropped 2.4 support we can also use the new memoryview syntax instead of ndarray syntax in Cython. That is more important for SciPy, but it has some relevance for NumPy too. Sturla Sendt fra min iPad Den 13. des. 2012 kl. 17:34 skrev Charles R Harris charlesr.har...@gmail.com: Time to raise this topic again. Opinions welcome. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
Targeting = 2.6 would be preferable to me. Several other packages including IPython, support only Python = 2.6, = 3.2. This change would help me from accidentally writing Python syntax which is allowable in 2.6 2.7 (but not in 2.4 or 2.5). Compiling a newer Python interpreter isn't very hard… probably about as difficult as installing NumPy. -Brad On Thursday, December 13, 2012 at 9:03 AM, Skipper Seabold wrote: On Thu, Dec 13, 2012 at 12:00 PM, David Cournapeau courn...@gmail.com (mailto:courn...@gmail.com) wrote: snip I would even go as far as dropping 2.5 as well then (RHEL 6 uses python 2.6). +1 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
On Thu, Dec 13, 2012 at 10:12 AM, Bradley M. Froehle brad.froe...@gmail.com wrote: Targeting = 2.6 would be preferable to me. Several other packages including IPython, support only Python = 2.6, = 3.2. This change would help me from accidentally writing Python syntax which is allowable in 2.6 2.7 (but not in 2.4 or 2.5). Compiling a newer Python interpreter isn't very hard… probably about as difficult as installing NumPy. -Brad On Thursday, December 13, 2012 at 9:03 AM, Skipper Seabold wrote: On Thu, Dec 13, 2012 at 12:00 PM, David Cournapeau courn...@gmail.com(mailto: courn...@gmail.com) wrote: snip I would even go as far as dropping 2.5 as well then (RHEL 6 uses python 2.6). +1 OK. Dropping support for python 2.4 looks like the majority opinion. I'll put up another post for 2.5. Do we need to coordinate with scipy? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
On 12/13/2012 09:39 AM, Benjamin Root wrote: As a point of reference, python 2.4 is on RH5/CentOS5. While RH6 is the current version, there are still enterprises that are using version 5. Of course, at this point, one really should be working on a migration plan and shouldn't be doing new development on those machines... FWIW this RHEL5* shop uses a local install of 2.6 rather than dealing with 2.4. Happy with dropping 2.4 support. Bonus from dropping 2.5: it's pretty easy to support a 2.6/3.x combined codebase without relying on 2to3. (*Not the same as RH5, from days of yore...) -- Jonathan Niehof ISR-3 Space Data Systems Los Alamos National Laboratory MS-D466 Los Alamos, NM 87545 Phone: 505-667-9595 email: jnie...@lanl.gov Correspondence / Technical data or Software Publicly Available ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
I'd say it's a good idea, although I hope 1.7.x will still be maintained for a while for those who are still stuck with Python 2.4-5 (sometimes you don't have a choice). -=- Olivier 2012/12/13 Charles R Harris charlesr.har...@gmail.com The previous proposal to drop python 2.4 support garnered no opposition. How about dropping support for python 2.5 also? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] site.cfg: Custom BLAS / LAPACK configuration
On 12/07/2012 07:58 PM, Dag Sverre Seljebotn wrote: One way of fixing this I'm sort of itching to do is to create a pylapack project which can iterate quickly on these build issues, run-time selection of LAPACK backend and so on. (With some templates generating some Cython code it shouldn't be more than a few days for an MVP.) Then patch NumPy to attempt to import pylapack (and if it's there, get a table of function pointers from it). The idea would be that powerusers could more easily build pylapack the way they wanted, in isolation, and then have other things switch to that without a rebuild (note again that it would need to export a table of function pointers). But I'm itching to do too many things, we'll see. Update: This can be tackled as part of Hashdist funding, so I'm hoping that I can 3-4 days on improving the LAPACK situation in January; as an option for power-users at first, hopefully something nice for everybody eventually. Opinions on the plan above welcome. Dag Sverre Dag Sverre On 12/07/2012 07:09 PM, Bradley M. Froehle wrote: Aha, thanks for the clarification. I've always been surpassed that NumPy doesn't ship with a copy of CBLAS. It's easy to compile --- just a thin wrapper over BLAS, if I remember correctly. -Brad On Friday, December 7, 2012 at 4:01 AM, David Cournapeau wrote: On Thu, Dec 6, 2012 at 7:35 PM, Bradley M. Froehle brad.froe...@gmail.com (mailto:brad.froe...@gmail.com) wrote: Right, but if I link to libcblas, cblas would be available, no? No, because we don't explicitly check for CBLAS. We assume it is there if Atlas, Accelerate or MKL is found. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris charlesr.har...@gmail.com wrote: The previous proposal to drop python 2.4 support garnered no opposition. How about dropping support for python 2.5 also? Chuck matplotlib 1.2 supports py2.5. I haven't seen any plan to move off of that for 1.3. Is there a compelling reason for dropping 2.5? Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
My apologies... we support 2.6 and above. +1 on dropping 2.5 support. Ben On Thu, Dec 13, 2012 at 1:12 PM, Benjamin Root ben.r...@ou.edu wrote: On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris charlesr.har...@gmail.com wrote: The previous proposal to drop python 2.4 support garnered no opposition. How about dropping support for python 2.5 also? Chuck matplotlib 1.2 supports py2.5. I haven't seen any plan to move off of that for 1.3. Is there a compelling reason for dropping 2.5? Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
On Thu, Dec 13, 2012 at 7:12 PM, Benjamin Root ben.r...@ou.edu wrote: On Thu, Dec 13, 2012 at 12:38 PM, Charles R Harris charlesr.har...@gmail.com wrote: The previous proposal to drop python 2.4 support garnered no opposition. How about dropping support for python 2.5 also? Chuck matplotlib 1.2 supports py2.5. I haven't seen any plan to move off of that for 1.3. Is there a compelling reason for dropping 2.5? A rationale for the record: I don't think people who don't care about 2.4 care about 2.5, and 2.6 is a significant improvement compared to 2.5: - context manager - python 3-compatible exception syntax (writing code that works with 2 and 3 without any change is significantly easier if your baseline in 2.6 instead of 2.4/2.5) - json, ast, multiprocessing are available and potentially quite useful for NumPy itself. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] site.cfg: Custom BLAS / LAPACK configuration
On Fri, Dec 7, 2012 at 7:58 PM, Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no wrote: One way of fixing this I'm sort of itching to do is to create a pylapack project which can iterate quickly on these build issues, run-time selection of LAPACK backend and so on. (With some templates generating some Cython code it shouldn't be more than a few days for an MVP.) Then patch NumPy to attempt to import pylapack (and if it's there, get a table of function pointers from it). The idea would be that powerusers could more easily build pylapack the way they wanted, in isolation, and then have other things switch to that without a rebuild (note again that it would need to export a table of function pointers). But I'm itching to do too many things, we'll see. It would be hard to support in a cross platform way I think (windows being the elephant in the room). I would be more than happy to be proven wrong, though :) cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] site.cfg: Custom BLAS / LAPACK configuration
On 12/13/2012 07:59 PM, David Cournapeau wrote: On Fri, Dec 7, 2012 at 7:58 PM, Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no wrote: One way of fixing this I'm sort of itching to do is to create a pylapack project which can iterate quickly on these build issues, run-time selection of LAPACK backend and so on. (With some templates generating some Cython code it shouldn't be more than a few days for an MVP.) Then patch NumPy to attempt to import pylapack (and if it's there, get a table of function pointers from it). The idea would be that powerusers could more easily build pylapack the way they wanted, in isolation, and then have other things switch to that without a rebuild (note again that it would need to export a table of function pointers). But I'm itching to do too many things, we'll see. It would be hard to support in a cross platform way I think (windows being the elephant in the room). I would be more than happy to be proven wrong, though :) Right, perhaps I should have said Linux users rather than power users :-) But seriously, I'd like to have a few more details here. Is it something about calling conventions and libc and so on that makes the function-pointer-table approach difficult? (But the NumPy C API is exported in the same way?) Or is it about the build? Can't one just lift whatever numpy.distutils or the NumPy Bento build does for detection? Though what I'll aim for at first is the complete opposite, no auto-detection, but a Windows user should also be able to specify the right flags manually... Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Calling LAPACK function dbdsqr()?
Hi all, I'm porting some Fortran code that makes use of a number of BLAS and LAPACK functions, including dbdsqr(). I've found all of the functions I need via scipy.linalg.lapack.get_lapack_funcs/get_blas_funcs() except for dbdsqr(). I see that the numpy source code (I looked at numpy-1.6.0b2) contains dbdsqr() in numpy/linalg/dlapack_lite.c, but grep can't find that string in the binary distribution on my Mac nor on Linux. If it's buried in a numpy binary somewhere, I'm comfortable with using ctypes to call it, but I suspect it isn't. Can anyone point me to a cross-platform (OS X, Linux Windows) way I can call this function? I'm unfortunately quite naïve about the math in the code I'm porting, so I'm porting the code blindly -- if you ask me what problem I'm trying to solve with dbdsqr(), I won't be able to explain. Thanks in advance for any suggestions, Philip ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Calling LAPACK function dbdsqr()?
On Thu, Dec 13, 2012 at 12:26 PM, Philip Semanchuk phi...@semanchuk.comwrote: Hi all, I'm porting some Fortran code that makes use of a number of BLAS and LAPACK functions, including dbdsqr(). I've found all of the functions I need via scipy.linalg.lapack.get_lapack_funcs/get_blas_funcs() except for dbdsqr(). I see that the numpy source code (I looked at numpy-1.6.0b2) contains dbdsqr() in numpy/linalg/dlapack_lite.c, but grep can't find that string in the binary distribution on my Mac nor on Linux. If it's buried in a numpy binary somewhere, I'm comfortable with using ctypes to call it, but I suspect it isn't. Can anyone point me to a cross-platform (OS X, Linux Windows) way I can call this function? I'm unfortunately quite naïve about the math in the code I'm porting, so I'm porting the code blindly -- if you ask me what problem I'm trying to solve with dbdsqr(), I won't be able to explain. Not all the functions in lapack_lite are exposed in numpy. You might want to post on the scipy list, there have been recent additions supporting more lapack functions. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Calling LAPACK function dbdsqr()?
13.12.2012 21:26, Philip Semanchuk kirjoitti: I'm porting some Fortran code that makes use of a number of BLAS and LAPACK functions, including dbdsqr(). I've found all of the functions I need via scipy.linalg.lapack.get_lapack_funcs/get_blas_funcs() except for dbdsqr(). [clip] If you tolerate having compiled code, you can relatively easily wrap the LAPACK routine you need using f2py. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
On Thu, Dec 13, 2012 at 6:36 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Dec 13, 2012 at 10:12 AM, Bradley M. Froehle brad.froe...@gmail.com wrote: Targeting = 2.6 would be preferable to me. Several other packages including IPython, support only Python = 2.6, = 3.2. This change would help me from accidentally writing Python syntax which is allowable in 2.6 2.7 (but not in 2.4 or 2.5). Compiling a newer Python interpreter isn't very hard… probably about as difficult as installing NumPy. -Brad On Thursday, December 13, 2012 at 9:03 AM, Skipper Seabold wrote: On Thu, Dec 13, 2012 at 12:00 PM, David Cournapeau courn...@gmail.com(mailto: courn...@gmail.com) wrote: snip I would even go as far as dropping 2.5 as well then (RHEL 6 uses python 2.6). +1 +1 OK. Dropping support for python 2.4 looks like the majority opinion. I'll put up another post for 2.5. Do we need to coordinate with scipy? Not much to coordinate I think. I'll send a message to scipy-dev proposing to simply follow the Numpy decision. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Calling LAPACK function dbdsqr()?
On Dec 13, 2012, at 3:03 PM, Pauli Virtanen wrote: 13.12.2012 21:26, Philip Semanchuk kirjoitti: I'm porting some Fortran code that makes use of a number of BLAS and LAPACK functions, including dbdsqr(). I've found all of the functions I need via scipy.linalg.lapack.get_lapack_funcs/get_blas_funcs() except for dbdsqr(). [clip] If you tolerate having compiled code, you can relatively easily wrap the LAPACK routine you need using f2py. Hi Pauli, THanks for the tip. We already have access to a compiled version, but maintaining that across 3 platforms and 32/64-bit is a headache, which is why we're aiming for pure Python plus numpy/scipy. bye Philip ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Calling LAPACK function dbdsqr()?
On Dec 13, 2012, at 2:47 PM, Charles R Harris wrote: On Thu, Dec 13, 2012 at 12:26 PM, Philip Semanchuk phi...@semanchuk.comwrote: Hi all, I'm porting some Fortran code that makes use of a number of BLAS and LAPACK functions, including dbdsqr(). I've found all of the functions I need via scipy.linalg.lapack.get_lapack_funcs/get_blas_funcs() except for dbdsqr(). I see that the numpy source code (I looked at numpy-1.6.0b2) contains dbdsqr() in numpy/linalg/dlapack_lite.c, but grep can't find that string in the binary distribution on my Mac nor on Linux. If it's buried in a numpy binary somewhere, I'm comfortable with using ctypes to call it, but I suspect it isn't. Can anyone point me to a cross-platform (OS X, Linux Windows) way I can call this function? I'm unfortunately quite naïve about the math in the code I'm porting, so I'm porting the code blindly -- if you ask me what problem I'm trying to solve with dbdsqr(), I won't be able to explain. Not all the functions in lapack_lite are exposed in numpy. You might want to post on the scipy list, there have been recent additions supporting more lapack functions. Thanks, I'll check scipy. In numpy, I can see that lapack_litemodule.c is the layer that exposes select lapack functions via the Python interface, and dbdsqr isn't present in that file which is why I figured I would have to use ctypes to call it. I just can't figure out why dbdsqr appears in the source code but neither grep nor nm find any reference to it in the compiled binary. Cheers Philip ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
How about dropping support for python 2.5 also? Im still dumfounded that people are working on projects where they are free to use the latest an greatest numpy, but *have* to use a more-than-four-year-old-python: Python 2.6 (final) was released on October 1st, 2008. so +1 on moving forward! -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 chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ValueError: low level cast function is for unequal type numbers
Hi, the following code using np.object_ data types works with numpy 1.5.1 but fails with 1.6.2. Is this intended or a regression? Other data types, np.float64 for example, seem to work. I am also seeing this problem; there was a change to how string types are handled in h5py 2.1.0 which triggers this bug. It's a serious inconvenience, as people can't do e.g. np.copy(hdf5 dataset object) any more. These downstream issues could be related: http://code.google.com/p/h5py/issues/detail?id=217 Yes, this seems to be the cause of issue 217. Andrew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
On Thu, Dec 13, 2012 at 10:07 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: How about dropping support for python 2.5 also? Im still dumfounded that people are working on projects where they are free to use the latest an greatest numpy, but *have* to use a more-than-four-year-old-python: It happens very easily in corporate environments. Compiling python it a major headache compared to numpy, not because of python itself, but because you need to recompile every single extension you're gonna use. Compiling numpy + its dependencies is at least feasable, but building things like pygtk when you don't have X11 headers installed is more or less impossible. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ValueError: low level cast function is for unequal type numbers
On 12/13/2012 1:57 PM, Andrew Collette wrote: Hi, the following code using np.object_ data types works with numpy 1.5.1 but fails with 1.6.2. Is this intended or a regression? Other data types, np.float64 for example, seem to work. I am also seeing this problem; there was a change to how string types are handled in h5py 2.1.0 which triggers this bug. It's a serious inconvenience, as people can't do e.g. np.copy(hdf5 dataset object) any more. These downstream issues could be related: http://code.google.com/p/h5py/issues/detail?id=217 Yes, this seems to be the cause of issue 217. Andrew Sorry, I forgot to mention that I submitted a pull request at https://github.com/numpy/numpy/pull/2798. Christoph ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
Yes, but the point was that since you can live with an older version on Python you can probably live with an older version of NumPy. On Thursday, December 13, 2012, David Cournapeau wrote: Im still dumfounded that people are working on projects where they are free to use the latest an greatest numpy, but *have* to use a more-than-four-year-old-python: It happens very easily in corporate environments. Compiling python it a major headache compared to numpy, not because of python itself, but because you need to recompile every single extension you're gonna use. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Travis failures with no errors
Hi, I found these recent weird failures in Travis, but I can't find any problem with the log and all tests pass. Any ideas what is going on? https://travis-ci.org/numpy/numpy/jobs/3570123 https://travis-ci.org/numpy/numpy/jobs/3539549 https://travis-ci.org/numpy/numpy/jobs/3369629 Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
On Thu, Dec 13, 2012 at 3:01 PM, Bradley M. Froehle brad.froe...@gmail.com wrote: Yes, but the point was that since you can live with an older version on Python you can probably live with an older version of NumPy. exactly -- also: How likely are you to nee the latest and greatest numpy but not a new PyGTK, or a new name_your_package_here. And, in fact, other packages drop support for older Python's too. However, what I can imagine is pretty irrelevant -- sorry I brought it up -- either there are a significant number of folks for whom support for old Pythons in important, or there aren't. -Chris On Thursday, December 13, 2012, David Cournapeau wrote: Im still dumfounded that people are working on projects where they are free to use the latest an greatest numpy, but *have* to use a more-than-four-year-old-python: It happens very easily in corporate environments. Compiling python it a major headache compared to numpy, not because of python itself, but because you need to recompile every single extension you're gonna use. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- 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 chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Failure in test_iterator.py at Travis
Hi, Another weird bug sometimes happen in numpy/core/tests/test_iterator.py, it looks like this: == FAIL: test_iterator.test_iter_array_cast -- Traceback (most recent call last): File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/core/tests/test_iterator.py, line 836, in test_iter_array_cast assert_equal(i.operands[0].strides, (-96,8,-32)) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/testing/utils.py, line 252, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/testing/utils.py, line 314, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=0 ACTUAL: 96 DESIRED: -96 -- But the problem is that there is no numpy/core/tests/test_iterator.py file in current branches This error was triggered for example by these PRs: https://github.com/numpy/numpy/pull/2765 https://github.com/numpy/numpy/pull/2815 and here are links to the failing Travis tests: https://travis-ci.org/certik/numpy/builds/3656959 https://travis-ci.org/numpy/numpy/builds/3330234 Any idea what is happening here and how to fix it? Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Failure in test_iterator.py at Travis
On Thu, Dec 13, 2012 at 7:23 PM, Ondřej Čertík ondrej.cer...@gmail.comwrote: Hi, Another weird bug sometimes happen in numpy/core/tests/test_iterator.py, it looks like this: == FAIL: test_iterator.test_iter_array_cast -- Traceback (most recent call last): File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/core/tests/test_iterator.py, line 836, in test_iter_array_cast assert_equal(i.operands[0].strides, (-96,8,-32)) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/testing/utils.py, line 252, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/testing/utils.py, line 314, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=0 ACTUAL: 96 DESIRED: -96 -- But the problem is that there is no numpy/core/tests/test_iterator.py file in current branches This error was triggered for example by these PRs: https://github.com/numpy/numpy/pull/2765 https://github.com/numpy/numpy/pull/2815 and here are links to the failing Travis tests: https://travis-ci.org/certik/numpy/builds/3656959 https://travis-ci.org/numpy/numpy/builds/3330234 Any idea what is happening here and how to fix it? That should have been fixed by Nathaniel's travis fix. Hmm... Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Failure in test_iterator.py at Travis
On Thu, Dec 13, 2012 at 8:04 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Dec 13, 2012 at 7:23 PM, Ondřej Čertík ondrej.cer...@gmail.comwrote: Hi, Another weird bug sometimes happen in numpy/core/tests/test_iterator.py, it looks like this: == FAIL: test_iterator.test_iter_array_cast -- Traceback (most recent call last): File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/core/tests/test_iterator.py, line 836, in test_iter_array_cast assert_equal(i.operands[0].strides, (-96,8,-32)) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/testing/utils.py, line 252, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/testing/utils.py, line 314, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=0 ACTUAL: 96 DESIRED: -96 -- But the problem is that there is no numpy/core/tests/test_iterator.py file in current branches This error was triggered for example by these PRs: https://github.com/numpy/numpy/pull/2765 https://github.com/numpy/numpy/pull/2815 and here are links to the failing Travis tests: https://travis-ci.org/certik/numpy/builds/3656959 https://travis-ci.org/numpy/numpy/builds/3330234 Any idea what is happening here and how to fix it? That should have been fixed by Nathaniel's travis fix. Hmm... And a quick check here shows pip not removing a previous 1.6.2 install. Maybe it is a pip version problem, pip 1.0.2 here. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Failure in test_iterator.py at Travis
On Thu, Dec 13, 2012 at 7:16 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Dec 13, 2012 at 8:04 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Dec 13, 2012 at 7:23 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: Hi, Another weird bug sometimes happen in numpy/core/tests/test_iterator.py, it looks like this: == FAIL: test_iterator.test_iter_array_cast -- Traceback (most recent call last): File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/nose/case.py, line 197, in runTest self.test(*self.arg) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/core/tests/test_iterator.py, line 836, in test_iter_array_cast assert_equal(i.operands[0].strides, (-96,8,-32)) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/testing/utils.py, line 252, in assert_equal assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k,err_msg), verbose) File /home/travis/virtualenv/python2.5/lib/python2.5/site-packages/numpy/testing/utils.py, line 314, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: item=0 ACTUAL: 96 DESIRED: -96 -- But the problem is that there is no numpy/core/tests/test_iterator.py file in current branches This error was triggered for example by these PRs: https://github.com/numpy/numpy/pull/2765 https://github.com/numpy/numpy/pull/2815 and here are links to the failing Travis tests: https://travis-ci.org/certik/numpy/builds/3656959 https://travis-ci.org/numpy/numpy/builds/3330234 Any idea what is happening here and how to fix it? That should have been fixed by Nathaniel's travis fix. Hmm... And a quick check here shows pip not removing a previous 1.6.2 install. Maybe it is a pip version problem, pip 1.0.2 here. That's what I thought as well. I think we need to update the Travis script to manually remove the installed numpy. Btw, Travis seems to be using pip 1.2.1, at least according to: https://travis-ci.org/numpy/numpy/jobs/3330236 Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Support for python 2.4 dropped. Should we drop 2.5 also?
2012/12/13 Chris Barker - NOAA Federal chris.bar...@noaa.gov On Thu, Dec 13, 2012 at 3:01 PM, Bradley M. Froehle brad.froe...@gmail.com wrote: Yes, but the point was that since you can live with an older version on Python you can probably live with an older version of NumPy. exactly -- also: How likely are you to nee the latest and greatest numpy but not a new PyGTK, or a new name_your_package_here. And, in fact, other packages drop support for older Python's too. However, what I can imagine is pretty irrelevant -- sorry I brought it up -- either there are a significant number of folks for whom support for old Pythons in important, or there aren't. I doubt it's a common situation, but just to give an example: I am developing some machine learning code that heavily relies on Numpy, and it is meant to run into a large Python 2.4 software environment, which can't easily be upgraded because it contains lots of libraries that have been built against Python 2.4. And even if I could rebuild it, they wouldn't let me ;) This Python code is mostly proprietary and doesn't require external dependencies to be upgraded... except my little module that may take advantage of Numpy improvements. -=- Olivier ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal to drop python 2.4 support in numpy 1.8
+1 from me For what is worth, we are just moving forward from Python 2.2 / Numeric and are going to 2.6 and it has been rather painful because of the several little details of extensions and other subtleties. I believe we will settle there for a while. For companies like ours, it is a big problem to upgrade versions. There is always this or that hiccup that works great in a version but not so much in another and we also have all sorts of extensions. Raul On 13/12/2012 9:34 AM, Charles R Harris wrote: Time to raise this topic again. Opinions welcome. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Attaching metadata to dtypes: what's the best way?
Hi all,
I have a question for the list sparked by this discussion of a bug in
NumPy 1.6.2 and 1.7:
http://mail.scipy.org/pipermail/numpy-discussion/2012-December/064682.html
and this open issue in h5py:
https://code.google.com/p/h5py/issues/detail?id=217
In h5py we need to represent variable length strings and HDF5 object
references within the existing NumPy dtype system. The way this is
handled at the moment is with object (type O) dtypes with a small
amount of metadata attached; in other words, an O array could have a
dtype marked as representing variable-length strings, and HDF5 would
convert the Python string objects into the corresponding type in the
HDF5 file. Likewise, an O dtype marked as containing HDF5 object
references (h5py.Reference instances) would be converted to native
HDF5 references when written.
The trouble I'm having is trying to attach metadata to a dtype in such
a way that it is preserved in NumPy. Right now I create an O dtype
with a single field and store the information in the field
description, e.g.:
dtype(('O', [( ({'type': bytes},'vlen'), 'O' )] ))
This works (it's how special types have worked in h5py for years) but
is quite unwieldy, and leads to interesting side effects. For
example, because of the single field used, array[index] returns a
1-element NumPy array containing a Python object, instead of the
Python object itself. Worse, our fix for this behavior (remove the
field when returning data from h5py) triggered the above bug in NumPy.
Is there a better way to add metadata to dtypes I'm not aware of?
Note I'm *not* interested in creating a custom type; one of the
advantages of the current system is that people deal with the
resulting O object arrays like any other object array in NumPy.
Andrew Collette
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] www.numpy.org home page
On Thu, 13 Dec 2012 17:35:01 +0100, Travis Oliphant teoliph...@gmail.com wrote: The NumPy home page can still be edited in this repository: g...@github.com:numpy/numpy.org.git. Pull requests are always welcome --- especially pull requests that improve the look and feel of the web-page. Hi, let me comment on it. 1. Page uses too intense color. Choosing color is sensitive question, but any reasonable suggestion should be better then current one 2. Numpy logo is of low quality: http://www.numpy.org/_static/numpy_logo.png and icon it's cropped carelessly 3. Links icons look messy as they look like patched from different themes - there are scipy shiny icons and then scipy matte icon and then RSS icon which links to blog. IMHO no one uses shiny icons anymore, and I don't know if these icons should have large scipy logo with thematic overlay as is. I'd suggest flat and informative icons if link icons are wanted 4. Favicon could be changed 5. Screenshot(s) could be added, but this is easier to say that suggest one. Maybe shots representing each numpy selected feature, and/or perhaps side links to Packt, as mentioned in your email, or similar, can add some dynamics in page look ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
