[Numpy-discussion] Check out my photos on Facebook
Hi Numpy-discussion, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Aswad To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=10738053270k=Z6E3Y5PX452D4EDJPG33QPYPPQIB42ZAWTAXJr Already have an account? Add this email address to your account http://www.facebook.com/n/?merge_accounts.phpe=numpy-discuss...@scipy.orgc=2c4cfc74b301e71691b056eae286542a.numpy-discuss...@scipy.org was invited to join Facebook by Aswad Gurjar. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe. http://www.facebook.com/o.php?k=e68275u=1530048334mid=1d87694G5b32af4eG0G8 Facebook's offices are located at 1601 S. California Ave., Palo Alto, CA 94304. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Sat, Feb 6, 2010 at 10:16 PM, Travis Oliphant oliph...@enthought.com wrote: I will just work on trunk and assume that the next release will be ABI incompatible. At this point I would rather call the next version 1.5 than 2.0, though. When the date-time work is completed, then we could release an ABI-compatible-with-1.5 version 2.0. There may be repercussions if numpy starts deviating from its own conventions for what versions may introduce ABI incompatibilities. I attended a workshop recently where a number of scientists approached me and expressed interest in switching from IDL to python. Two of these were senior scientists leading large research groups and collaborations, both of whom had looked at python several years ago and decided they did not like the wild west nature (direct quote) of the scientific python community. I assured them that both the projects and community were maturing. At the time, I did not have to explain the situation concerning numpy-1.4.0, which, if it causes problems when they try to set up an environment to assess python, could put them off python for another 3 years, maybe even for good. It would be a lot easier to justify the disruption if one could say numpy-2.0 added support for some important features, so this disruption was unfortunate but necessary. Such disruptions are specified by major version changes, which as you can see are rare. In fact, there are no further major version changes envisioned at this time. That kind of statement might reassure a lot of people, including package maintainers etc. Regards, Darren P.S. I promise this will be my last post on the subject. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] swap elements in two arrays
I have two 1d arrays, say `a` and `b`. I need to swap elements if a 1d boolean criterion `to_swap` is met. Here's one way: a, b = np.choose([to_swap,np.logical_not(to_swap)], [a, b]) Here is a much faster way: a[to_swap], b[to_swap] = b[to_swap], a[to_swap] Other better ways? Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] swap elements in two arrays
su, 2010-02-07 kello 10:11 -0500, Alan G Isaac kirjoitti: I have two 1d arrays, say `a` and `b`. I need to swap elements if a 1d boolean criterion `to_swap` is met. [clip] Here is a much faster way: a[to_swap], b[to_swap] = b[to_swap], a[to_swap] That doesn't necessarily work -- the above code expands to tmp = a[to_swap] a[to_swap] = b[to_swap] b[to_swap] = tmp It'll work provided `to_swap` is such that `tmp` is not a view on `a`... -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Sun, Feb 7, 2010 at 7:57 AM, Darren Dale dsdal...@gmail.com wrote: On Sat, Feb 6, 2010 at 10:16 PM, Travis Oliphant oliph...@enthought.com wrote: I will just work on trunk and assume that the next release will be ABI incompatible. At this point I would rather call the next version 1.5 than 2.0, though. When the date-time work is completed, then we could release an ABI-compatible-with-1.5 version 2.0. There may be repercussions if numpy starts deviating from its own conventions for what versions may introduce ABI incompatibilities. I attended a workshop recently where a number of scientists approached me and expressed interest in switching from IDL to python. Two of these were senior scientists leading large research groups and collaborations, both of whom had looked at python several years ago and decided they did not like the wild west nature (direct quote) of the scientific python community. I assured them that both the projects and community were maturing. At the time, I did not have to explain the situation concerning numpy-1.4.0, which, if it causes problems when they try to set up an environment to assess python, could put them off python for another 3 years, maybe even for good. It would be a lot easier to justify the disruption if one could say numpy-2.0 added support for some important features, so this disruption was unfortunate but necessary. Such disruptions are specified by major version changes, which as you can see are rare. In fact, there are no further major version changes envisioned at this time. That kind of statement might reassure a lot of people, including package maintainers etc. Regards, Darren P.S. I promise this will be my last post on the subject. Don't be shy ;) You make good points and I agree with them. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] swap elements in two arrays
On 2/7/2010 10:21 AM, Alan Isaac wrote: I have two 1d arrays, say `a` and `b`. I need to swap elements if a 1d boolean criterion `to_swap` is met. [clip] Here is a much faster way: a[to_swap], b[to_swap] = b[to_swap], a[to_swap] On 2/7/2010 10:21 AM, Pauli Virtanen wrote: That doesn't necessarily work -- the above code expands to tmp = a[to_swap] a[to_swap] = b[to_swap] b[to_swap] = tmp It'll work provided `to_swap` is such that `tmp` is not a view on `a`... I thought that if `to_swap` is a boolean array that `a[to_swap]` will always own its own data. Can that fail? Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] swap elements in two arrays
su, 2010-02-07 kello 10:39 -0500, Alan G Isaac kirjoitti: [clip] I thought that if `to_swap` is a boolean array that `a[to_swap]` will always own its own data. Can that fail? Ok, I don't think it can fail, then. But it's a slightly dangerous idiom nevertheless... -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] swap elements in two arrays
On Sun, Feb 7, 2010 at 7:58 AM, Pauli Virtanen p...@iki.fi wrote: su, 2010-02-07 kello 10:39 -0500, Alan G Isaac kirjoitti: [clip] I thought that if `to_swap` is a boolean array that `a[to_swap]` will always own its own data. Can that fail? Ok, I don't think it can fail, then. But it's a slightly dangerous idiom nevertheless... I think it depends on how much you know about the inputs: to_swap = np.array([True, True]) Good: a = np.array([1, 2, 3]) b = a[1:].copy() a[to_swap], b[to_swap] = b[to_swap], a[to_swap] a array([2, 3, 3]) b array([1, 2]) Bad: a = np.array([1, 2, 3]) b = a[1:] a[to_swap], b[to_swap] = b[to_swap], a[to_swap] a array([2, 1, 2]) b array([1, 2]) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Sat, Feb 6, 2010 at 7:16 PM, Travis Oliphant oliph...@enthought.com wrote: I will just work on trunk and assume that the next release will be ABI incompatible. At this point I would rather call the next version 1.5 than 2.0, though. When the date-time work is completed, then we could release an ABI-compatible-with-1.5 version 2.0. My view of the timeline for the 1.5 release is the end of February. I would prefer that we follow our previously discussed, agreed upon, and explicitly stated version numbering policy: * The releases will be numbered major.minor.bugfix * There will be no ABI changes in minor releases * There will be no API changes in bugfix releases In addition to it being our policy, it is also more closely aligned with my general expectations for any mature open source project. Just to be clear, I would prefer to see the ABI-breaking release be called 2.0. I don't see why we have to get the release out in three weeks, though. I think it would be better to use this opportunity to take some time to make sure we get it right. I am not suggesting that we delay for months. Instead, why don't we agree to consider ABI-breakage for to 2-3 weeks. Then close the discussion and try to get the 2.0 release out as quickly after that as possible. -- Jarrod Millman Helen Wills Neuroscience Institute 10 Giannini Hall, UC Berkeley http://cirl.berkeley.edu/ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] swap elements in two arrays
On 2/7/2010 11:16 AM, Keith Goodman wrote: Bad: a = np.array([1, 2, 3]) b = a[1:] a[to_swap], b[to_swap] = b[to_swap], a[to_swap] a array([2, 1, 2]) b array([1, 2]) So that is an important point: if `a` and `b` share data, the swap is not well defined. But that affects the alternative idiom as well: to_swap array([ True, True], dtype=bool) a = np.array([1, 2, 3]) b = a[1:] temp = a.copy() a[to_swap] = b[to_swap] b[to_swap] = temp a, b (array([2, 1, 2]), array([1, 2])) Thanks, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unable to install Numpy
On Sat, Feb 6, 2010 at 5:24 PM, Vicente Soler Fraile vicentesolerfra...@hotmail.com wrote: I am using: Python 2.6.4 (r264:75708, Oct 26 2009, 07:36:50) [MSC v.1500 64 bit (AMD64)] on win32 which seems to be a 64 bits interpreter. What should I do if want to use Numpy. Can I somehow manually install Numpy? Or else should I remove Wincom and Python 64 bits and install instead a 32 bits interpreter? Any help is highly appreciated. Regards Date: Sat, 6 Feb 2010 23:03:03 +0900 From: courn...@gmail.com To: numpy-discussion@scipy.org Subject: Re: [Numpy-discussion] Unable to install Numpy On Sat, Feb 6, 2010 at 10:54 PM, Vicente Soler Fraile vicentesolerfra...@hotmail.com wrote: Hello, I try to install Numpy without success. Windows 7 Python 2.6.4 Numpy numpy-1.4.0-win32-superpack- python2.6.exe Are you using a 32 bits python ? We only provide 32 bits installers for now on windows2, Hello, Regarding this post - is there a non official numpy package for 64bit windows? And how about SciPy ? I guess it all related to problems coming from the 64bit support of cygwin (rather the lack thereof) - right ? Cheers, Sebastian Haase ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unable to install Numpy
On Sun, Feb 7, 2010 at 4:23 PM, Sebastian Haase seb.ha...@gmail.com wrote: On Sat, Feb 6, 2010 at 5:24 PM, Vicente Soler Fraile vicentesolerfra...@hotmail.com wrote: I am using: Python 2.6.4 (r264:75708, Oct 26 2009, 07:36:50) [MSC v.1500 64 bit (AMD64)] on win32 which seems to be a 64 bits interpreter. What should I do if want to use Numpy. Can I somehow manually install Numpy? Or else should I remove Wincom and Python 64 bits and install instead a 32 bits interpreter? Any help is highly appreciated. Regards Date: Sat, 6 Feb 2010 23:03:03 +0900 From: courn...@gmail.com To: numpy-discussion@scipy.org Subject: Re: [Numpy-discussion] Unable to install Numpy On Sat, Feb 6, 2010 at 10:54 PM, Vicente Soler Fraile vicentesolerfra...@hotmail.com wrote: Hello, I try to install Numpy without success. Windows 7 Python 2.6.4 Numpy numpy-1.4.0-win32-superpack- python2.6.exe Are you using a 32 bits python ? We only provide 32 bits installers for now on windows2, Hello, Regarding this post - is there a non official numpy package for 64bit windows? And how about SciPy ? I guess it all related to problems coming from the 64bit support of cygwin (rather the lack thereof) - right ? Un-official binaries that I've been using (rarely) on Windows 7 are here: http://www.scipy.org/Download#head-f64942d62faddeb27278a2c735e81ef2a7349db0 Skipper ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unable to install Numpy
Sebastian Haase wrote: Hello, Regarding this post - is there a non official numpy package for 64bit windows? And how about SciPy ? There are both unofficial individual binaries and EPD-based numpy/scipy. One example of unofficial builds are there: http://www.lfd.uci.edu/~gohlke/pythonlibs/ I guess it all related to problems coming from the 64bit support of cygwin (rather the lack thereof) - right ? Not exactly, although it prevents from building Atlas for 64 bits. The main issue is gcc/VS interoperabilities, especially for gfortran. I have not taken the time to work in it the last few months. For various reasons, I don't think it makes sense for NumPy itself to provide binaries which do not use open source compilers. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
Jarrod Millman wrote: Just to be clear, I would prefer to see the ABI-breaking release be called 2.0. I don't see why we have to get the release out in three weeks, though. I think it would be better to use this opportunity to take some time to make sure we get it right. As a compromise, what about the following: - remove ABI-incompatible changes for 1.4.x - release a 1.5.0 marked as experimental, with everything that Travis wants to put in. It would be a preview for python 3k as well, so it conveys the idea that it is experimental pretty well. - the 1.6.x branch would be a polished 1.5.x. The advantages is that 1.5.0 can be push relatively early, but we would still keep 1.4.0 as the stable release, against which every other binary installer should be built (scipy, mpl). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
I'm breaking my promise, after people wrote me offlist encouraging me to keep pushing my point of view. On Sun, Feb 7, 2010 at 8:23 PM, David Cournapeau da...@silveregg.co.jp wrote: Jarrod Millman wrote: Just to be clear, I would prefer to see the ABI-breaking release be called 2.0. I don't see why we have to get the release out in three weeks, though. I think it would be better to use this opportunity to take some time to make sure we get it right. As a compromise, what about the following: - remove ABI-incompatible changes for 1.4.x - release a 1.5.0 marked as experimental, with everything that Travis wants to put in. It would be a preview for python 3k as well, so it conveys the idea that it is experimental pretty well. Why can't this be called 2.0beta, with a __version__ like 1.9.96? I don't understand the reluctance to follow numpy's own established conventions. - the 1.6.x branch would be a polished 1.5.x. This could be called that 2.0.x instead of 1.6.x The advantages is that 1.5.0 ... or 2.0beta ... can be push relatively early, but we would still keep 1.4.0 as the stable release, against which every other binary installer should be built (scipy, mpl). Darren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
Darren Dale wrote: Why can't this be called 2.0beta, with a __version__ like 1.9.96? I don't understand the reluctance to follow numpy's own established conventions. Mostly because 2.0 conveys the idea that there are significant new features, and because it would allow breaking the API as well. I would rather avoid missing this opportunity by making a 2.0 just to allow breaking the ABI without significantly reviewing our C API. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Sun, Feb 7, 2010 at 6:23 PM, David Cournapeau da...@silveregg.co.jpwrote: Jarrod Millman wrote: Just to be clear, I would prefer to see the ABI-breaking release be called 2.0. I don't see why we have to get the release out in three weeks, though. I think it would be better to use this opportunity to take some time to make sure we get it right. As a compromise, what about the following: - remove ABI-incompatible changes for 1.4.x +1 - release a 1.5.0 marked as experimental, with everything that Travis wants to put in. It would be a preview for python 3k as well, so it conveys the idea that it is experimental pretty well. I've got to agree with Darren here. 2.0 marks the API break, nothing more, nothing less. That's what the major number is for. - the 1.6.x branch would be a polished 1.5.x. No one expects a x.0.0 release to be polished ;) The advantages is that 1.5.0 can be push relatively early, but we would still keep 1.4.0 as the stable release, against which every other binary installer should be built (scipy, mpl). Just push out 2.0 early. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Sun, Feb 7, 2010 at 6:53 PM, David Cournapeau da...@silveregg.co.jpwrote: Darren Dale wrote: Why can't this be called 2.0beta, with a __version__ like 1.9.96? I don't understand the reluctance to follow numpy's own established conventions. Mostly because 2.0 conveys the idea that there are significant new features, and because it would allow breaking the API as well. I would rather avoid missing this opportunity by making a 2.0 just to allow breaking the ABI without significantly reviewing our C API. I think you attach to much importance to the major number. It simply marks an ABI change, no matter how minor. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
Charles R Harris wrote: On Sun, Feb 7, 2010 at 6:53 PM, David Cournapeau da...@silveregg.co.jp mailto:da...@silveregg.co.jp wrote: Darren Dale wrote: Why can't this be called 2.0beta, with a __version__ like 1.9.96? I don't understand the reluctance to follow numpy's own established conventions. Mostly because 2.0 conveys the idea that there are significant new features, and because it would allow breaking the API as well. I would rather avoid missing this opportunity by making a 2.0 just to allow breaking the ABI without significantly reviewing our C API. I think you attach to much importance to the major number. It simply marks an ABI change, no matter how minor. Yes, but that's highly unusual. The convention is to only break ABI when it is absolutely necessary, at which point they change the API as well. Now, I won't won't be against putting this as a 2.0 release if that's what people can agree on, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Sun, Feb 7, 2010 at 7:03 PM, David Cournapeau da...@silveregg.co.jpwrote: Charles R Harris wrote: On Sun, Feb 7, 2010 at 6:53 PM, David Cournapeau da...@silveregg.co.jp mailto:da...@silveregg.co.jp wrote: Darren Dale wrote: Why can't this be called 2.0beta, with a __version__ like 1.9.96? I don't understand the reluctance to follow numpy's own established conventions. Mostly because 2.0 conveys the idea that there are significant new features, and because it would allow breaking the API as well. I would rather avoid missing this opportunity by making a 2.0 just to allow breaking the ABI without significantly reviewing our C API. I think you attach to much importance to the major number. It simply marks an ABI change, no matter how minor. Yes, but that's highly unusual. The convention is to only break ABI when it is absolutely necessary, at which point they change the API as well. The brand new Numpy 2.0, featuring a shiny new ABI with the same sturdy API used and loved by millions. Hey, it's just advertizing. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Unable to install Numpy
David Cournapeau wrote: Not exactly, although it prevents from building Atlas for 64 bits. The main issue is gcc/VS interoperabilities, especially for gfortran. I thought you didn't need fortran for numpy? I don't think it makes sense for NumPy itself to provide binaries which do not use open source compilers um, why not? python itself is built witht he MS compilers. I have not idea about 64 bit, but the free-of-charge MS compiler seems to build 32 bit python extensions for 2.6 OK, so you should be able to build numpy with it (without atlas, of course). -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] Unable to install Numpy
Christopher Barker wrote: David Cournapeau wrote: Not exactly, although it prevents from building Atlas for 64 bits. The main issue is gcc/VS interoperabilities, especially for gfortran. I thought you didn't need fortran for numpy? No, but you need it for Scipy. And we have always produced NumPy with Lapack support on windows. I don't think it makes sense for NumPy itself to provide binaries which do not use open source compilers um, why not? python itself is built witht he MS compilers. Because there is no free fortran compiler on windows64, except for gfortran. Since I am not sure whether it will be possible to use gfortran/Visual Stsudio together to build NumPy/SciPy, I don't want to distribute binaries which will be incompatible with each other if we change from Visual Studio to gcc. People who really need NumPy on win64 can build it by themselves, or use any other mean (EPD, unofficial binaries, etc...). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
