[Numpy-discussion] numpy release process, adding a compatibility test step.
Hi, may I suggest an addition to the release process... 'Tests against popular libraries that rely on numpy at the RC stage. Test at least these libraries pass their numpy related tests: matplotlib, scipy, pygame, (insert others here?). The release manage should ask the mailing list for people to test the RC against these libraries to make sure they work ok.' - This will catch problems like the ABI one with the recent release. - It is an explicit request for testing, with concrete tasks that people can do. Rather than a more abstract request for testing. - not much extra work for the release manager. testing work can be distributed to anyone who can try an app, or library with the binaries supplied in the RC stage of a release. - binary installer users can test as well, not just people who build from source. - tests libraries the numpy developers may not be using all the time themselves. On another project, adding this simple step helped prevent a number of bugs which affected other programs and libraries using the project. Before this was added we had a couple of releases which broke a few popular libraries/apps with very simple regressions or bugs. cu, ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installed NumPy and MatPlotLib in the Wrong Order. How uninstall MPL?
stuck = placed. I'm pretty sure I used an msi file. I've brought this topic up in 3 forums where I would have thought people knew the answer. Yours is the first answer. I would have guessed that anyone dealing libraries would have known the answer. Nor have I found anything in two Python books I've used. I think I'll look at them again. Google didn't even show anything. Thanks for the response. I'll try to clear manually the locations we've mentioned. On 2/5/2010 9:01 PM, josef.p...@gmail.com wrote: On Fri, Feb 5, 2010 at 10:37 PM, Wayne Watson sierra_mtnv...@sbcglobal.net wrote: See Subject. I'm working in IDLE in Win7. It seems to me MPL gets stuck in site-packages under C:\Python25. Maybe this is as simple as deleting the entry? What does it mean that MPL gets stuck? what kind of stuck? (My experience is only windowsXP not Win7) Often I just delete all directories and files for a package. However, if the package has been installed with an installer and not with easy_install or setup.py, there might be a removexxx, (removematplotlib) under/in the Python25 directory (I have Removematplotlib.exe for python24 but not for 25) and it might also be in the windows registry, try Add/Remove Programs or whatever the Win7 equivalent is. I just checked my Add/Remove Programs and I have several entries under python 2.5 that are orphans because I deleted the directories but didn't uninstall through an uninstaller, but again I see an entry for matplotlib only for python 2.4, so maybe matplotlib doesn't pollute the windows registry anymore. If you don't find any matplotlib uninstall (as in my case for Py2.5), you can just delete all files and directories in site-packages. Josef Well, yes there's a MPL folder under site-packages and an info MPL file of 540 bytes. There are also pylab.py, pyc,and py0 files under site. What to do next? -- My life in two words. Interrupted Projects. -- WTW (quote originator) ___ 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 -- My life in two words. Interrupted Projects. -- WTW (quote originator) ___ 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 4:07 PM, Travis Oliphant oliph...@enthought.com wrote: Given all the discussions that have happened. I want to be clear about my proposal. It is: * 1.4.1 is an ABI break including datetime, hasobject, and a few place- holders in the structures * no future ABI breakages until after the Py3K transition (at least 18 months away) -- I don't foresee any future ABI changes at all, nor do I think we will need any ABI changes in the next 2 years. * 1.3.9 is a release with all the features of 1.4 except the ABI breaking date-time addition * 1.3.9 release occurs as soon as we can get it out (like next week --- I will commit Monday-Tuesday to do the date-time removal). * 1.4.1 release occurs as soon as we can get it out with all the ABI changes we know about (which are already in 1.4.0 --- we just bump up the ABI version number). I would estimate a release by the end of February. So it seems that there is an agreement of breaking the ABI only once overall. This is good. I think this plan is the least disruptive and satisfies the concerns of all parties in the discussion. The other plans that have been proposed do not address my concerns of keeping the date-time changes In that regard, your proposal is very similar to what was suggested at the beginning - the difference is only whether breaking at 1.4.x or 1.5.x. I don't care that much about where (1.4.x vs 1.5.x) the datetime is pushed. But then the hasobject-related changes should be put altogether, to respect the goal of breaking the ABI only once. If you think it can be done for the end of february, then I don't see much point in releasing what you call 1.3.9, because I really don't want to have to put numpy-version specific scipy/maplotlib/whatever. The release with datetime changes will be the one to build scipy and matplotlib against (I will then focus on releasing scipy 0.8.0). 1.4.0 would is then considered as a broken release (I am removing the files from sourceforge). 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 ?
A Saturday 06 February 2010 13:17:22 David Cournapeau escrigué: On Sat, Feb 6, 2010 at 4:07 PM, Travis Oliphant oliph...@enthought.com wrote: I think this plan is the least disruptive and satisfies the concerns of all parties in the discussion. The other plans that have been proposed do not address my concerns of keeping the date-time changes In that regard, your proposal is very similar to what was suggested at the beginning - the difference is only whether breaking at 1.4.x or 1.5.x. I'm thinking why should we so conservative in raising version numbers? Why not relabeling 1.4.0 to 2.0 and mark 1.4.0 as a broken release? Then, we can continue by putting everything except ABI breaking features in 1.4.1. With this, NumPy 2.0 will remain available for people wanting to be more on-the- bleeding-edge. Something similar to what has happened with Python 3.0, which has not prevented the 2.x series to evolve. How this sounds? -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installed NumPy and MatPlotLib in the Wrong Order. How uninstall MPL?
You should be able to have Matplotlib in Python 2.5 and in Python 2.6, no problem. But you need to get the correct installer. There are separate installers for different Pythons. Alan Isaac ___ 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 6:07 AM, Francesc Alted fal...@pytables.org wrote: A Saturday 06 February 2010 13:17:22 David Cournapeau escrigué: On Sat, Feb 6, 2010 at 4:07 PM, Travis Oliphant oliph...@enthought.com wrote: I think this plan is the least disruptive and satisfies the concerns of all parties in the discussion. The other plans that have been proposed do not address my concerns of keeping the date-time changes In that regard, your proposal is very similar to what was suggested at the beginning - the difference is only whether breaking at 1.4.x or 1.5.x. I'm thinking why should we so conservative in raising version numbers? Why not relabeling 1.4.0 to 2.0 and mark 1.4.0 as a broken release? Then, we can continue by putting everything except ABI breaking features in 1.4.1. With this, NumPy 2.0 will remain available for people wanting to be more on-the- bleeding-edge. Something similar to what has happened with Python 3.0, which has not prevented the 2.x series to evolve. How this sounds? I like the idea of pushing the version number of the ABI breaking release up to 2.0. We can't just relabel 1.4.0, though, because of the prospective hasobject addition. I think David is also concerned about having to support essentially two versions of Numpy, which would be a hassle. However, if Travis is willing to remove datetime from the current 1.4.0, then maybe that could be released with the understanding that the next release of Scipy will be built against the the ABI breaking version. 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 Sat, Feb 6, 2010 at 8:07 AM, Francesc Alted fal...@pytables.org wrote: A Saturday 06 February 2010 13:17:22 David Cournapeau escrigué: On Sat, Feb 6, 2010 at 4:07 PM, Travis Oliphant oliph...@enthought.com wrote: I think this plan is the least disruptive and satisfies the concerns of all parties in the discussion. The other plans that have been proposed do not address my concerns of keeping the date-time changes In that regard, your proposal is very similar to what was suggested at the beginning - the difference is only whether breaking at 1.4.x or 1.5.x. I'm thinking why should we so conservative in raising version numbers? Why not relabeling 1.4.0 to 2.0 and mark 1.4.0 as a broken release? Then, we can continue by putting everything except ABI breaking features in 1.4.1. With this, NumPy 2.0 will remain available for people wanting to be more on-the- bleeding-edge. Something similar to what has happened with Python 3.0, which has not prevented the 2.x series to evolve. How this sounds? I think breaking with 1.5 sounds good because it starts the second part of the 1.x series. 2.0 could be for the big overhaul that David has in mind, unless it will not be necessary anymore Josef -- Francesc Alted ___ 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] Removing datetime support for 1.4.x series ?
On Sat, Feb 6, 2010 at 6:29 AM, josef.p...@gmail.com wrote: On Sat, Feb 6, 2010 at 8:07 AM, Francesc Alted fal...@pytables.org wrote: A Saturday 06 February 2010 13:17:22 David Cournapeau escrigué: On Sat, Feb 6, 2010 at 4:07 PM, Travis Oliphant oliph...@enthought.com wrote: I think this plan is the least disruptive and satisfies the concerns of all parties in the discussion. The other plans that have been proposed do not address my concerns of keeping the date-time changes In that regard, your proposal is very similar to what was suggested at the beginning - the difference is only whether breaking at 1.4.x or 1.5.x. I'm thinking why should we so conservative in raising version numbers? Why not relabeling 1.4.0 to 2.0 and mark 1.4.0 as a broken release? Then, we can continue by putting everything except ABI breaking features in 1.4.1. With this, NumPy 2.0 will remain available for people wanting to be more on-the- bleeding-edge. Something similar to what has happened with Python 3.0, which has not prevented the 2.x series to evolve. How this sounds? I think breaking with 1.5 sounds good because it starts the second part of the 1.x series. 2.0 could be for the big overhaul that David has in mind, unless it will not be necessary anymore Well, let's just go with David then. I think the important thing is to settle this and move on. 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 Sat, Feb 6, 2010 at 8:29 AM, josef.p...@gmail.com wrote: On Sat, Feb 6, 2010 at 8:07 AM, Francesc Alted fal...@pytables.org wrote: A Saturday 06 February 2010 13:17:22 David Cournapeau escrigué: On Sat, Feb 6, 2010 at 4:07 PM, Travis Oliphant oliph...@enthought.com wrote: I think this plan is the least disruptive and satisfies the concerns of all parties in the discussion. The other plans that have been proposed do not address my concerns of keeping the date-time changes In that regard, your proposal is very similar to what was suggested at the beginning - the difference is only whether breaking at 1.4.x or 1.5.x. I'm thinking why should we so conservative in raising version numbers? Why not relabeling 1.4.0 to 2.0 and mark 1.4.0 as a broken release? Then, we can continue by putting everything except ABI breaking features in 1.4.1. With this, NumPy 2.0 will remain available for people wanting to be more on-the- bleeding-edge. Something similar to what has happened with Python 3.0, which has not prevented the 2.x series to evolve. How this sounds? I think breaking with 1.5 sounds good because it starts the second part of the 1.x series. 2.0 could be for the big overhaul that David has in mind, unless it will not be necessary anymore I don't understand why there is any debate about what to call a release that breaks ABI compatibility. Robert Kern already reminded the list of the Report from SciPy dated 2008-08-23: * 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 If numpy-2.0 suddenly shows up at sourceforge, people will either already be aware of the above convention, or if not they at least will be more likely to wonder what precipitated the jump and be more likely to read the release notes. 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 ?
On Sat, Feb 6, 2010 at 10:29 PM, josef.p...@gmail.com wrote: On Sat, Feb 6, 2010 at 8:07 AM, Francesc Alted fal...@pytables.org wrote: A Saturday 06 February 2010 13:17:22 David Cournapeau escrigué: On Sat, Feb 6, 2010 at 4:07 PM, Travis Oliphant oliph...@enthought.com wrote: I think this plan is the least disruptive and satisfies the concerns of all parties in the discussion. The other plans that have been proposed do not address my concerns of keeping the date-time changes In that regard, your proposal is very similar to what was suggested at the beginning - the difference is only whether breaking at 1.4.x or 1.5.x. I'm thinking why should we so conservative in raising version numbers? Why not relabeling 1.4.0 to 2.0 and mark 1.4.0 as a broken release? Then, we can continue by putting everything except ABI breaking features in 1.4.1. With this, NumPy 2.0 will remain available for people wanting to be more on-the- bleeding-edge. Something similar to what has happened with Python 3.0, which has not prevented the 2.x series to evolve. How this sounds? I think breaking with 1.5 sounds good because it starts the second part of the 1.x series. This is the original proposal, but one that not everybody agreed on it. I am just trying to find a middleground so that everybody is behind it. 2.0 could be for the big overhaul that David has in mind, unless it will not be necessary anymore It will still be necessary, but that's a more long term goal. I think it is relatively independent to this discussion since it is agreed that ABI will not be broken more than once. 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 Sat, Feb 6, 2010 at 10:36 PM, Darren Dale dsdal...@gmail.com wrote: I don't understand why there is any debate about what to call a release that breaks ABI compatibility. Because it means datetime support will come late (in 2.0), and Travis wanted to get it early in. 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 Sat, Feb 6, 2010 at 8:39 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Feb 6, 2010 at 10:36 PM, Darren Dale dsdal...@gmail.com wrote: I don't understand why there is any debate about what to call a release that breaks ABI compatibility. Because it means datetime support will come late (in 2.0), and Travis wanted to get it early in. Why does something called 2.0 have to come late? Why can't whatever near-term numpy release that breaks ABI compatibility and includes datetime be called 2.0? Darren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Unable to install Numpy
Hello, I try to install Numpy without success. Windows 7 Python 2.6.4 Numpy numpy-1.4.0-win32-superpack-python2.6.exe The problem is that the installer does not find Python in the Windows Registry. However, I've been using python for quite a long time now. Since I really want to try Numpy, do you have any ideas as to what can I do? Thank you for your help _ Ibex 35, comparadores de hipotecas, Euribor, foros de bolsa. ¡Nuevo MSN Dinero! http://dinero.es.msn.com/___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installed NumPy and MatPlotLib in the Wrong Order. How uninstall MPL?
On Sat, Feb 6, 2010 at 6:15 AM, Alan G Isaac ais...@american.edu wrote: You should be able to have Matplotlib in Python 2.5 and in Python 2.6, no problem. But you need to get the correct installer. There are separate installers for different Pythons. I don't know if things have changed, but long ago when I was using windows more often I found it best to delete old installations of python when moving up to later versions. Chuck ___ 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 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, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installed NumPy and MatPlotLib in the Wrong Order. How uninstall MPL?
On Sat, Feb 6, 2010 at 9:02 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Feb 6, 2010 at 6:15 AM, Alan G Isaac ais...@american.edu wrote: You should be able to have Matplotlib in Python 2.5 and in Python 2.6, no problem. But you need to get the correct installer. There are separate installers for different Pythons. I don't know if things have changed, but long ago when I was using windows more often I found it best to delete old installations of python when moving up to later versions. I never had any problems on winXP with both python 2.4 and 2.5 installed. It's a bit of work to change all environment and path settings to a new python version by hand. Someone wrote a python script that updates all path and registry settings automatically. (I don't remember on which blog I saw it.) Josef 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] Installed NumPy and MatPlotLib in the Wrong Order. How uninstall MPL?
On 2/6/2010 9:02 AM, Charles R Harris wrote: I don't know if things have changed, but long ago when I was using windows more often I found it best to delete old installations of python when moving up to later versions. I have had multiple versions running side by side for years, with never a problem. (I always use the official installers.) Well ok, one problem... By default the last Python you install becomes your system Python, so you need to pay attention to that. But you can always reset that. Do you recall what kinds of problems you ran into? fwiw, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] error fromnumeric: 254 (repeat) return repeat(repeats, axis)
Dear programmers, I'm not familiar with numpy therefore I need a little help to debug code which was not written by me. The lines which generate the error are the following: index = N.concatenate( (index, [len_i]) ) delta = index[1:] - index[:-1] return N.repeat( mask, delta.astype( N.int32 ) ) and this is the error message I get: PDBModel: 1619 (extendMask) return N.repeat( mask, delta.astype( N.int32 ) ) functions: 19 (repeat) return np.repeat(a, repeats, axis) fromnumeric: 254 (repeat) return repeat(repeats, axis) below I provide you with the values of each variables in these 3 lines of code: index = [ 09 20 29 37 44 55 66 76 88 96 103 114 123 131 138 147 155 167 176 184 192 198 209 216 224 233 242 246 255 262 274 279 290 297 301 310 316 320 326 330 339 345 352 360 368 377 385 393 402 413 421 433 441 448 455 464 468 476 484 492 499 507 515 521 531 539 547 556 564 572 580 588 597 611 625 636 642 651 659 663 670 677 683 692 700 707 715 723 734 740 748 754 762 771 779 787 795 804 816 822 830 842 848 856 865 873 881 890 895 903 912 920 932 944 953 962 970 977 985 993 1000 1012 1021 1029 1038 1046 1057 1063 1071 1079 1085 1093 1099 1107 1114 1120 1128 1137 1145 1153 1162 1170 1179 1188 1197 1209 1218 1225 1233 1242 1250 1256 1264 1271 1278 1286 1293 1299 1308 1317 1324 1332 1340 1350 1358 1369 1376 1382 1388 1396 1403 1411 1420 1432 1440 1447 1455 1462 1466 1472 1480 1485 1491 1500 1508 1514 1518 1522 1531 1540 1549 1560 1568 1574 1582 1587 1598 1603 1611 1619 1630 1638 1645 1654 1662 1670 1678 1686 1694 1703 1708 1715 1721 1727 1735 1743 1751 1760 1766 1775 1787 1795 1802 1811 1820 1827 1835 1843 1851 1859 1868 1872 1880 1889 1897 1908 1916 1923 1931 1939 1947 1952 1962 1973 1981 1987 1994 2002 2013 2025 2030 2038 2045 2053 2064 2071 2079 2085 2093 2104 2113 2124 2130 2138 2146 2154 2162 2170 2178 2186 2194 2202 2210 2218 2226 2234 2242 2250 2258 2266 2274 2282 2290] [len_i] = [2300] (index, [len_i]) = (array([ 0,9, 20, 29, 37, 44, 55, 66, 76, 88, 96, 103, 114, 123, 131, 138, 147, 155, 167, 176, 184, 192, 198, 209, 216, 224, 233, 242, 246, 255, 262, 274, 279, 290, 297, 301, 310, 316, 320, 326, 330, 339, 345, 352, 360, 368, 377, 385, 393, 402, 413, 421, 433, 441, 448, 455, 464, 468, 476, 484, 492, 499, 507, 515, 521, 531, 539, 547, 556, 564, 572, 580, 588, 597, 611, 625, 636, 642, 651, 659, 663, 670, 677, 683, 692, 700, 707, 715, 723, 734, 740, 748, 754, 762, 771, 779, 787, 795, 804, 816, 822, 830, 842, 848, 856, 865, 873, 881, 890, 895, 903, 912, 920, 932, 944, 953, 962, 970, 977, 985, 993, 1000, 1012, 1021, 1029, 1038, 1046, 1057, 1063, 1071, 1079, 1085, 1093, 1099, 1107, 1114, 1120, 1128, 1137, 1145, 1153, 1162, 1170, 1179, 1188, 1197, 1209, 1218, 1225, 1233, 1242, 1250, 1256, 1264, 1271, 1278, 1286, 1293, 1299, 1308, 1317, 1324, 1332, 1340, 1350, 1358, 1369, 1376, 1382, 1388, 1396, 1403, 1411, 1420, 1432, 1440, 1447, 1455, 1462, 1466, 1472, 1480, 1485, 1491, 1500, 1508, 1514, 1518, 1522, 1531, 1540, 1549, 1560, 1568, 1574, 1582, 1587, 1598, 1603, 1611, 1619, 1630, 1638, 1645, 1654, 1662, 1670, 1678, 1686, 1694, 1703, 1708, 1715, 1721, 1727, 1735, 1743, 1751, 1760, 1766, 1775, 1787, 1795, 1802, 1811, 1820, 1827, 1835, 1843, 1851, 1859, 1868, 1872, 1880, 1889, 1897, 1908, 1916, 1923, 1931, 1939, 1947, 1952, 1962, 1973, 1981, 1987, 1994, 2002, 2013, 2025, 2030, 2038, 2045, 2053, 2064, 2071, 2079, 2085, 2093, 2104, 2113, 2124, 2130, 2138, 2146, 2154, 2162, 2170, 2178, 2186, 2194, 2202, 2210, 2218, 2226, 2234, 2242, 2250, 2258, 2266, 2274, 2282, 2290]), [2300]) index[1:] = [ 9 20 29 37 44 55 66 76 88 96 103 114 123 131 138 147 155 167 176 184 192 198 209 216 224 233 242 246 255 262 274 279 290 297 301 310 316 320 326 330 339 345 352 360 368 377 385 393 402 413 421 433 441 448 455 464 468 476 484 492 499 507 515 521 531 539 547 556 564 572 580 588 597 611 625 636 642 651 659 663 670 677 683 692 700 707 715 723 734 740 748 754 762 771 779 787 795 804 816 822 830 842 848 856 865 873 881 890 895 903 912 920 932 944 953 962 970 977 985 993 1000 1012 1021 1029 1038 1046 1057 1063 1071 1079 1085 1093 1099 1107 1114 1120 1128 1137 1145 1153 1162 1170 1179 1188 1197 1209 1218 1225 1233 1242 1250 1256 1264 1271 1278 1286 1293 1299 1308 1317 1324 1332 1340 1350 1358 1369 1376 1382 1388 1396 1403
Re: [Numpy-discussion] error fromnumeric: 254 (repeat) return repeat(repeats, axis)
Tom, 'mask' has 285 elements and 'delta' has 284 elements. If these are to be used as arguments of numpy.repeat(), they must be the same length. Warren Thomas Evangelidis wrote: Dear programmers, I'm not familiar with numpy therefore I need a little help to debug code which was not written by me. The lines which generate the error are the following: index = N.concatenate( (index, [len_i]) ) delta = index[1:] - index[:-1] return N.repeat( mask, delta.astype( N.int32 ) ) and this is the error message I get: PDBModel: 1619 (extendMask) return N.repeat( mask, delta.astype( N.int32 ) ) functions: 19 (repeat) return np.repeat(a, repeats, axis) fromnumeric: 254 (repeat) return repeat(repeats, axis) below I provide you with the values of each variables in these 3 lines of code: index = [ 09 20 29 37 44 55 66 76 88 96 103 114 123 131 138 147 155 167 176 184 192 198 209 216 224 233 242 246 255 262 274 279 290 297 301 310 316 320 326 330 339 345 352 360 368 377 385 393 402 413 421 433 441 448 455 464 468 476 484 492 499 507 515 521 531 539 547 556 564 572 580 588 597 611 625 636 642 651 659 663 670 677 683 692 700 707 715 723 734 740 748 754 762 771 779 787 795 804 816 822 830 842 848 856 865 873 881 890 895 903 912 920 932 944 953 962 970 977 985 993 1000 1012 1021 1029 1038 1046 1057 1063 1071 1079 1085 1093 1099 1107 1114 1120 1128 1137 1145 1153 1162 1170 1179 1188 1197 1209 1218 1225 1233 1242 1250 1256 1264 1271 1278 1286 1293 1299 1308 1317 1324 1332 1340 1350 1358 1369 1376 1382 1388 1396 1403 1411 1420 1432 1440 1447 1455 1462 1466 1472 1480 1485 1491 1500 1508 1514 1518 1522 1531 1540 1549 1560 1568 1574 1582 1587 1598 1603 1611 1619 1630 1638 1645 1654 1662 1670 1678 1686 1694 1703 1708 1715 1721 1727 1735 1743 1751 1760 1766 1775 1787 1795 1802 1811 1820 1827 1835 1843 1851 1859 1868 1872 1880 1889 1897 1908 1916 1923 1931 1939 1947 1952 1962 1973 1981 1987 1994 2002 2013 2025 2030 2038 2045 2053 2064 2071 2079 2085 2093 2104 2113 2124 2130 2138 2146 2154 2162 2170 2178 2186 2194 2202 2210 2218 2226 2234 2242 2250 2258 2266 2274 2282 2290] [len_i] = [2300] (index, [len_i]) = (array([ 0,9, 20, 29, 37, 44, 55, 66, 76, 88, 96, 103, 114, 123, 131, 138, 147, 155, 167, 176, 184, 192, 198, 209, 216, 224, 233, 242, 246, 255, 262, 274, 279, 290, 297, 301, 310, 316, 320, 326, 330, 339, 345, 352, 360, 368, 377, 385, 393, 402, 413, 421, 433, 441, 448, 455, 464, 468, 476, 484, 492, 499, 507, 515, 521, 531, 539, 547, 556, 564, 572, 580, 588, 597, 611, 625, 636, 642, 651, 659, 663, 670, 677, 683, 692, 700, 707, 715, 723, 734, 740, 748, 754, 762, 771, 779, 787, 795, 804, 816, 822, 830, 842, 848, 856, 865, 873, 881, 890, 895, 903, 912, 920, 932, 944, 953, 962, 970, 977, 985, 993, 1000, 1012, 1021, 1029, 1038, 1046, 1057, 1063, 1071, 1079, 1085, 1093, 1099, 1107, 1114, 1120, 1128, 1137, 1145, 1153, 1162, 1170, 1179, 1188, 1197, 1209, 1218, 1225, 1233, 1242, 1250, 1256, 1264,
Re: [Numpy-discussion] Unable to install Numpy
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, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion _ Recibe las alertas Hotmail en tu móvil ¡Actívalas ya! http://home.mobile.live.com/MobileAttach.mvc/?mkt=es-es___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installed NumPy and MatPlotLib in the Wrong Order. How uninstall MPL?
All the official matplotlib installers on sourceforge are bdist_wininst executables, not msi. The installer for Python 2.5 was built with Python 2.5 itself, which does not know about Windows user account control (UAC). Unless you specifically run the installer as administrator, the uninstall registry settings can not be created. I also replied to you on matplotlib-users on how to manually remove matplotlib. Christoph On 2/6/2010 3:43 AM, Wayne Watson wrote: stuck = placed. I'm pretty sure I used an msi file. I've brought this topic up in 3 forums where I would have thought people knew the answer. Yours is the first answer. I would have guessed that anyone dealing libraries would have known the answer. Nor have I found anything in two Python books I've used. I think I'll look at them again. Google didn't even show anything. Thanks for the response. I'll try to clear manually the locations we've mentioned. On 2/5/2010 9:01 PM, josef.p...@gmail.com wrote: On Fri, Feb 5, 2010 at 10:37 PM, Wayne Watson sierra_mtnv...@sbcglobal.net wrote: See Subject. I'm working in IDLE in Win7. It seems to me MPL gets stuck in site-packages under C:\Python25. Maybe this is as simple as deleting the entry? What does it mean that MPL gets stuck? what kind of stuck? (My experience is only windowsXP not Win7) Often I just delete all directories and files for a package. However, if the package has been installed with an installer and not with easy_install or setup.py, there might be a removexxx, (removematplotlib) under/in the Python25 directory (I have Removematplotlib.exe for python24 but not for 25) and it might also be in the windows registry, try Add/Remove Programs or whatever the Win7 equivalent is. I just checked my Add/Remove Programs and I have several entries under python 2.5 that are orphans because I deleted the directories but didn't uninstall through an uninstaller, but again I see an entry for matplotlib only for python 2.4, so maybe matplotlib doesn't pollute the windows registry anymore. If you don't find any matplotlib uninstall (as in my case for Py2.5), you can just delete all files and directories in site-packages. Josef Well, yes there's a MPL folder under site-packages and an info MPL file of 540 bytes. There are also pylab.py, pyc,and py0 files under site. What to do next? -- My life in two words. Interrupted Projects. -- WTW (quote originator) ___ 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
[Numpy-discussion] numpy 10x slower than native Python arrays for simple operations?
I have done some profiling, and the results are completely
counterintuitive. For simple array access operations, numpy and
array.array are 10x slower than native Python arrays.
I am using numpy 1.3.0, the standard Ubuntu 9.03 package.
Why am I getting such slow access speeds?
Note that for array access, I am doing operations of the form:
a[i] += 1
Profiles:
[0] * 2000
Access: 2.3M / sec
Initialization: 0.8s
numpy.zeros(shape=(2000,), dtype=numpy.int32)
Access: 160K/sec
Initialization: 0.2s
array.array('L', [0] * 2000)
Access: 175K/sec
Initialization: 2.0s
array.array('L', (0 for i in range(2000)))
Access: 175K/sec, presumably, based upon the profile for the other
array.array
Initialization: 6.7s
Any idea why my numpy array access is so slow?
Thanks,
Joseph
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy 10x slower than native Python arrays for simple operations?
On Sat, Feb 6, 2010 at 2:21 PM, Joseph Turian tur...@gmail.com wrote:
I have done some profiling, and the results are completely
counterintuitive. For simple array access operations, numpy and
array.array are 10x slower than native Python arrays.
I am using numpy 1.3.0, the standard Ubuntu 9.03 package.
Why am I getting such slow access speeds?
Note that for array access, I am doing operations of the form:
a[i] += 1
Profiles:
[0] * 2000
Access: 2.3M / sec
Initialization: 0.8s
numpy.zeros(shape=(2000,), dtype=numpy.int32)
Access: 160K/sec
Initialization: 0.2s
array.array('L', [0] * 2000)
Access: 175K/sec
Initialization: 2.0s
array.array('L', (0 for i in range(2000)))
Access: 175K/sec, presumably, based upon the profile for the other
array.array
Initialization: 6.7s
Any idea why my numpy array access is so slow?
Without seeing the whole script it is hard to tell. But numpy indexing is
slow and should be avoided when possible.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy 10x slower than native Python arrays for simple operations?
la, 2010-02-06 kello 16:21 -0500, Joseph Turian kirjoitti: I have done some profiling, and the results are completely counterintuitive. For simple array access operations, numpy and array.array are 10x slower than native Python arrays. I am using numpy 1.3.0, the standard Ubuntu 9.03 package. Why am I getting such slow access speeds? Note that for array access, I am doing operations of the form: a[i] += 1 Profiles: [0] * 2000 Access: 2.3M / sec Initialization: 0.8s numpy.zeros(shape=(2000,), dtype=numpy.int32) Access: 160K/sec Initialization: 0.2s The speed difference comes here from the fact that a[i] += 1 effectively calls numpy.core.umath.add(a[i], 1, a[i]). Since it is designed to handle operations on arrays, and at the moment there is no short-circuit for 1-d numbers, it has a fixed overhead that is larger than for Python's simple number+number addition. In vectorized operations the overhead does not matter, but changing a single element at a time makes it show. If `i` is an index vector, Numpy has faster per-element access times, In [1]: import numpy as np In [2]: a = np.zeros((200,), 'i4') In [3]: b = [0] * 200 In [5]: i = np.arange(0, 200, 5) In [8]: %timeit b[0] += 1 100 loops, best of 3: 260 ns per loop In [20]: %timeit a[i] += 1 10 loops, best of 3: 71.2 ms per loop In [25]: 71.2e-3/len(i) Out[25]: 1.7801e-07 ie., 178 ns per element -- 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 Feb 6, 2010, at 7:07 AM, Francesc Alted wrote: A Saturday 06 February 2010 13:17:22 David Cournapeau escrigué: On Sat, Feb 6, 2010 at 4:07 PM, Travis Oliphant oliph...@enthought.com wrote: I think this plan is the least disruptive and satisfies the concerns of all parties in the discussion. The other plans that have been proposed do not address my concerns of keeping the date-time changes In that regard, your proposal is very similar to what was suggested at the beginning - the difference is only whether breaking at 1.4.x or 1.5.x. I'm thinking why should we so conservative in raising version numbers? Why not relabeling 1.4.0 to 2.0 and mark 1.4.0 as a broken release? Then, we can continue by putting everything except ABI breaking features in 1.4.1. With this, NumPy 2.0 will remain available for people wanting to be more on-the- bleeding-edge. Something similar to what has happened with Python 3.0, which has not prevented the 2.x series to evolve. This is not advisable in my mind because we don't have nearly enough developer resources to start having 2 maintained branches of NumPy. The expectation that bug-fixes and other improvements will be happening on two different release tracks of NumPy is just not realistic right now. I was only mildly supportive of making another ABI compatible release. The resistance to my approach has dampened my enthusiasm for doing the work necessary to make it happen.That's quite O.K. though. If David or somebody else wants to make a 1.4.1 release that is ABI compatible with the 1.3 series then great. 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. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release process, adding a compatibility test step.
On Sat, Feb 6, 2010 at 6:44 PM, René Dudfield ren...@gmail.com wrote: Hi, may I suggest an addition to the release process... 'Tests against popular libraries that rely on numpy at the RC stage. Test at least these libraries pass their numpy related tests: matplotlib, scipy, pygame, (insert others here?). The release manage should ask the mailing list for people to test the RC against these libraries to make sure they work ok.' - This will catch problems like the ABI one with the recent release. - It is an explicit request for testing, with concrete tasks that people can do. Rather than a more abstract request for testing. - not much extra work for the release manager. testing work can be distributed to anyone who can try an app, or library with the binaries supplied in the RC stage of a release. - binary installer users can test as well, not just people who build from source. - tests libraries the numpy developers may not be using all the time themselves. On another project, adding this simple step helped prevent a number of bugs which affected other programs and libraries using the project. Before this was added we had a couple of releases which broke a few popular libraries/apps with very simple regressions or bugs. Thanks for the suggestion, I agree this will be useful. And a lot easier to do than automated testing against other libraries, which will hopefully happen at some point in the future. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
