Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.
On Fri, Feb 10, 2012 at 8:51 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Fri, Feb 10, 2012 at 10:25 AM, David Cournapeau courn...@gmail.comwrote: On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant tra...@continuum.io wrote: I think supporting Python 2.5 and above is completely fine. I'd even be in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy 2.8 +1 for dropping Python 2.5 support also for an LTS release. That will make it a lot easier to use str.format() and the with statement (plus many other things) going forward, without having to think about if your changes can be backported to that LTS release. At the risk of sounding like a broken record, I would really like to stay to 2.4, especially for a long term release :) This is still the basis used by a lots of long-term python products. If we can support 2.4 for a LTS, I would then be much more comfortable to allow bumping to 2.5 for 1.8. At the very least someone should step up to do the testing or maintain a buildbot for Python 2.4 then. Also for scipy, assuming that scipy keeps supporting the same Python versions as numpy. Here's a list of Python requirements for other important scientific python projects: - ipython: = 2.6 - matplotlib: v1.1 supports 2.4-2.7, v1.2 will support = 2.6 - scikit-learn: = 2.6 - scikit-image: = 2.5 - scikits.statsmodels: = 2.5 (next release probably = 2.6) That there are still some projects/products out there that still use Python 2.4 (some examples of such products would be nice by the way) is not enough of a reason by itself to continue to support it in new releases. There has to be a good reason for those products to require the very latest numpy, even though they are fine with a very old Python and older versions of almost any other Python package. It would also make sense to ship binaries (for Windows at least) of all Python versions we say we support. We haven't done so for 2.4 for a very long time. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.
On Sat, Feb 11, 2012 at 9:08 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Feb 10, 2012 at 8:51 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Feb 10, 2012 at 10:25 AM, David Cournapeau courn...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant tra...@continuum.io wrote: I think supporting Python 2.5 and above is completely fine. I'd even be in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy 2.8 +1 for dropping Python 2.5 support also for an LTS release. That will make it a lot easier to use str.format() and the with statement (plus many other things) going forward, without having to think about if your changes can be backported to that LTS release. At the risk of sounding like a broken record, I would really like to stay to 2.4, especially for a long term release :) This is still the basis used by a lots of long-term python products. If we can support 2.4 for a LTS, I would then be much more comfortable to allow bumping to 2.5 for 1.8. At the very least someone should step up to do the testing or maintain a buildbot for Python 2.4 then. Also for scipy, assuming that scipy keeps supporting the same Python versions as numpy. Here's a list of Python requirements for other important scientific python projects: - ipython: = 2.6 - matplotlib: v1.1 supports 2.4-2.7, v1.2 will support = 2.6 - scikit-learn: = 2.6 - scikit-image: = 2.5 - scikits.statsmodels: = 2.5 (next release probably = 2.6) That there are still some projects/products out there that still use Python 2.4 (some examples of such products would be nice by the way) is not enough of a reason by itself to continue to support it in new releases. There has to be a good reason for those products to require the very latest numpy, even though they are fine with a very old Python and older versions of almost any other Python package. I don't think that last argument is relevant for a LTS. Numpy is used in environments where you cannot easily control what's installed. RHEL still uses python 2.4 and will be supported until 2014 in the production phase. As for projects still using python 2.4, using the most downloaded packages from this list http://taichino.appspot.com/pypi_ranking/modules?page=1, most of them supported python 2.4 or below. lxml, zc.buildout, setuptools, pip, virtualenv and sqlalchemy do. Numpy itself is also used outside the strict scientific realm, which is why I am a bit warry about just comparing with other scientific python packages. Now, if everybody else is against it, I don't want to be a pain about it either :) David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.
On Sat, Feb 11, 2012 at 12:05 PM, David Cournapeau courn...@gmail.comwrote: On Sat, Feb 11, 2012 at 9:08 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Feb 10, 2012 at 8:51 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Feb 10, 2012 at 10:25 AM, David Cournapeau courn...@gmail.com wrote: On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant tra...@continuum.io wrote: I think supporting Python 2.5 and above is completely fine. I'd even be in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy 2.8 +1 for dropping Python 2.5 support also for an LTS release. That will make it a lot easier to use str.format() and the with statement (plus many other things) going forward, without having to think about if your changes can be backported to that LTS release. At the risk of sounding like a broken record, I would really like to stay to 2.4, especially for a long term release :) This is still the basis used by a lots of long-term python products. If we can support 2.4 for a LTS, I would then be much more comfortable to allow bumping to 2.5 for 1.8. At the very least someone should step up to do the testing or maintain a buildbot for Python 2.4 then. Also for scipy, assuming that scipy keeps supporting the same Python versions as numpy. Here's a list of Python requirements for other important scientific python projects: - ipython: = 2.6 - matplotlib: v1.1 supports 2.4-2.7, v1.2 will support = 2.6 - scikit-learn: = 2.6 - scikit-image: = 2.5 - scikits.statsmodels: = 2.5 (next release probably = 2.6) That there are still some projects/products out there that still use Python 2.4 (some examples of such products would be nice by the way) is not enough of a reason by itself to continue to support it in new releases. There has to be a good reason for those products to require the very latest numpy, even though they are fine with a very old Python and older versions of almost any other Python package. I don't think that last argument is relevant for a LTS. I think it's a relevant argument right now, irrespective of whether or not 1.7 will be an LTS. Numpy is used in environments where you cannot easily control what's installed. RHEL still uses python 2.4 and will be supported until 2014 in the production phase. As Bruce said, 29 Feb 2012 and not 2014: https://access.redhat.com/support/policy/updates/errata/ Ralf As for projects still using python 2.4, using the most downloaded packages from this list http://taichino.appspot.com/pypi_ranking/modules?page=1, most of them supported python 2.4 or below. lxml, zc.buildout, setuptools, pip, virtualenv and sqlalchemy do. Numpy itself is also used outside the strict scientific realm, which is why I am a bit warry about just comparing with other scientific python packages. Now, if everybody else is against it, I don't want to be a pain about it either :) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] simple manipulations of numpy arrays
On 2/10/2012 8:53 AM, Francesc Alted wrote: On Feb 10, 2012, at 4:50 PM, Francesc Alted wrote: https://github.com/FrancescAlted/carry Hmm, this should be: https://github.com/FrancescAlted/carray Blame my (too) smart spell corrector. -- Francesc Alted Thank you, Francesc and Tom, for your suggestions. -Brad ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.
On Sat, Feb 11, 2012 at 1:30 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: As Bruce said, 29 Feb 2012 and not 2014: https://access.redhat.com/support/policy/updates/errata/ I think Bruce and me were not talking about the same RHEL version (4 vs 5). Let me see if I can set up a buildbot for 2.4. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.
On Sat, Feb 11, 2012 at 4:08 PM, David Cournapeau courn...@gmail.comwrote: On Sat, Feb 11, 2012 at 1:30 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: As Bruce said, 29 Feb 2012 and not 2014: https://access.redhat.com/support/policy/updates/errata/ I think Bruce and me were not talking about the same RHEL version (4 vs 5). Ah, in that case it makes more sense to keep supporting it for two more years. Let me see if I can set up a buildbot for 2.4. That would be very helpful, thanks. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.
NumPy 1.7 is due out in the next few weeks. This will obviously support 2.4. It can be used for as long as people want. Right now, there is a plan for NumPy 1.8 to be released in the summer which will have much attention paid to it in order to improve the documentation, add bug-fixes, as well as make feature additions.Right now, the plan is to have that release support 2.5, however, major bug-fixes will be back-ported to the 1.7 series as patches are available. I suspect that different organizations will use different versions of NumPy as their own LTS.I plan on encouraging people to use 1.8 as the LTS. Work on NumPy 2.0 is already underway, but it will likely not be ready until January of 2013 at the earliest. Of course, there may be happy circumstances that accelerate that plan and other events that delay it. But, that is my best guess at the moment. Best, -Travis On Feb 10, 2012, at 3:25 AM, David Cournapeau wrote: On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant tra...@continuum.io wrote: I think supporting Python 2.5 and above is completely fine. I'd even be in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy 2.8 +1 for dropping Python 2.5 support also for an LTS release. That will make it a lot easier to use str.format() and the with statement (plus many other things) going forward, without having to think about if your changes can be backported to that LTS release. At the risk of sounding like a broken record, I would really like to stay to 2.4, especially for a long term release :) This is still the basis used by a lots of long-term python products. If we can support 2.4 for a LTS, I would then be much more comfortable to allow bumping to 2.5 for 1.8. 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] Commit rights to NumPy for Francesc Alted
I propose to give Francesc Alted commit rights to the NumPy project. Francesc will be working full time on NumPy for several months and it will enable him to participate in pull requests. Francesc Alted has been very active in the larger Python for Science community and has written PyTables, Blosc, carray and made contributions to NumExpr. He was also instrumental in early design efforts around the fully-recursive dtype functionality of NumPy. Thoughts? -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Migrating issues to GitHub
How to people feel about moving the issue tracking for NumPy to Github?It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Migrating issues to GitHub
On Saturday, February 11, 2012, Travis Oliphant tra...@continuum.io wrote: How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments. The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves. Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration. Cheers! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Commit rights to NumPy for Francesc Alted
On Sat, Feb 11, 2012 at 12:11 PM, Travis Oliphant tra...@continuum.iowrote: I propose to give Francesc Alted commit rights to the NumPy project. Francesc will be working full time on NumPy for several months and it will enable him to participate in pull requests. Francesc Alted has been very active in the larger Python for Science community and has written PyTables, Blosc, carray and made contributions to NumExpr.He was also instrumental in early design efforts around the fully-recursive dtype functionality of NumPy. Thoughts? Oh, definitely. +1. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] @Dag re numpy.pxd
Hi Dag, This probably needs to be on the cython mailing list at some point, but I thought I'd start the discussion here. Numpy is going to begin deprecating direct access to ndarray/dtype internals, ala arr-data etc. There are currently macros/functions for many of these operations in the numpy development branch and I expect more to go in over the coming year. Also, some of the macros have been renamed. I don't know the best way for Cython to support this, but the current version (0.15 here) generates code that will fail if the deprecated things are excluded. Ideally, numpy.pxd would have numpy version dependent parts but I don't know if that is possible. In any case, I'd like your thoughts on the best way to coordinate this migration with Cython. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Migrating issues to GitHub
11.02.2012 20:44, Travis Oliphant kirjoitti: How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. The lack of attachments is the main problem with this transition. It's not so seldom that numerical input data or scripts demonstrating an issue come useful. This is probably less of an issue for Numpy than for Scipy, though. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Migrating issues to GitHub
This is good feedback. It looks like there are 2 concerns: 1) no way to add attachments --- it would seem that gists and indeed other github repos solves that problem. 2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth). This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins. On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing. So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal. -Travis On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote: On Saturday, February 11, 2012, Travis Oliphant tra...@continuum.io wrote: How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments. The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves. Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration. Cheers! Ben Root ___ 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] Migrating issues to GitHub
On Sat, Feb 11, 2012 at 1:44 PM, Travis Oliphant tra...@continuum.iowrote: This is good feedback. It looks like there are 2 concerns: 1) no way to add attachments --- it would seem that gists and indeed other github repos solves that problem. 2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth). This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins. On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing. So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal. It does present a problem for migrating current trac as a number of the tickets have attachments and we don't want to lose them. On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote: On Saturday, February 11, 2012, Travis Oliphant tra...@continuum.io wrote: How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments. The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves. Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration. Cheers! Ben Root ___ Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Migrating issues to GitHub
On Sat, Feb 11, 2012 at 12:36 PM, Pauli Virtanen p...@iki.fi wrote: The lack of attachments is the main problem with this transition. It's not so seldom that numerical input data or scripts demonstrating an issue come useful. This is probably less of an issue for Numpy than for Scipy, though. We've taken to using gist for scripts/data and free image hosting sites for screenshots, using img src=http:// /img to show the screenshot in the bug report when relevant. Not always ideal, but it does get the job done, and actually with gist, it's kind of nice that the 'attachment' can evolve with version control too. The lack of real priorities *is* a hassle, at least for me. I understand the rationale behind a very simple UI and unstructured labels, but priority is such a central concept to bug tracking that its absence is a shortcoming, pure and simple. In summary, in IPython we've been using the gh tracker for almost 2 years, and since the updates to issues 2.0, with milestones and individual assignee fields, they are quite serviceable. In the balance, I feel the benefits of tight integration with the rest of the site outweigh the limitations, though I'll be very happy if those limitations are removed in future upgrades to the site. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Want to eliminate direct for-loop
Could the following be written without the direct for-loop? import numpy # numpy vector r of any data type and length, eg. r = numpy.ones(25, dtype='int') # s is a list of values (of any data type), eg. s = [47, 27, 67] # c is a list of (variable length) lists where the sub-list elements are index values of r and len(s) = len(c), eg. c = [[3, 6, 9], [6, 11, 19, 24], [4, 9, 11, 21 ]] # for each element in each sub-list c, add corresponding s value to the index value in r, eg. for i, j in enumerate(c): r[j] += s[i] So, we get: r[[3, 6, 9]] += s[0] = 1 + 47 = 48 r[[6, 11, 19, 24]] += s[1] = 1 + 27 = 28 r[[4, 9, 11, 21]] += s[2] = 1 + 67 = 68 ie. r = array([ 1, 1, 1, 95, 68, 1, 122, 1, 1, 162, 1, 95, 1, 1, 1, 1, 1, 1, 1, 28, 1, 68, 1, 1, 28]) Thank-you! ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Migrating issues to GitHub
On 2/11/12 1:44 PM, Travis Oliphant wrote: How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? Are there any good github trac plugins? For example: http://davglass.lighthouseapp.com/projects/21212/home http://trac-hacks.org/wiki/GitPlugin (git, not github, but still maybe useful) Thanks, Jason ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Migrating issues to GitHub
I think that migration will require some amount of manual intervention, and that this is a perfect opportunity to review the issues which can be part of the NumPy 1.8 work-load. There is an intern I am working with who is looking for something more substantial to do, and this would also be a good opportunity for others who would like to get some experience with NumPy. -Travis On Feb 11, 2012, at 2:53 PM, Charles R Harris wrote: On Sat, Feb 11, 2012 at 1:44 PM, Travis Oliphant tra...@continuum.io wrote: This is good feedback. It looks like there are 2 concerns: 1) no way to add attachments --- it would seem that gists and indeed other github repos solves that problem. 2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth). This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins. On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing. So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal. It does present a problem for migrating current trac as a number of the tickets have attachments and we don't want to lose them. On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote: On Saturday, February 11, 2012, Travis Oliphant tra...@continuum.io wrote: How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments. The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves. Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration. Cheers! Ben Root ___ 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] Migrating issues to GitHub
11.02.2012 22:02, Jason Grout kirjoitti: [clip] Are there any good github trac plugins? For example: http://davglass.lighthouseapp.com/projects/21212/home http://trac-hacks.org/wiki/GitPlugin (git, not github, but still maybe useful) The Numpy Scipy Trac is currently running on this: https://github.com/pv/githubsimple-trac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Migrating issues to GitHub
On 02/11/2012 10:44 AM, Travis Oliphant wrote: This is good feedback. It looks like there are 2 concerns: 1) no way to add attachments --- it would seem that gists and indeed other github repos solves that problem. Not really, in practice. Yes one can use these mechanisms, but they are much clunkier and more obscure than simply being able to attach files via an immediate interface. So the barrier to actual use is high. 2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth). A third problem is that the entire style of presentation is poorly designed from a use standpoint, in comparison to the sourceforge tracker which mpl used previously. The github tracker appears to have been designed by a graphics person, not a software maintainer. The information density in the issue list is very low; it is impossible to scan a large number of issues at once; there doesn't seem to be any useful sorting and selection mechanism. This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins. This doesn't seem so bad to me, at least compared to the *really* bad aspects. On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing. So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal. The one good thing about the github tracker is its integration with the code. Otherwise it is still just plain bad, and will remain so until it is given an information-dense tabular interface, with things like initiation date, last update, category, priority, etc. Down with whitespace and icons! We need information! Eric -Travis On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote: On Saturday, February 11, 2012, Travis Oliphant tra...@continuum.io mailto:tra...@continuum.io wrote: How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments. The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves. Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration. Cheers! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto: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] @Dag re numpy.pxd
On 11 February 2012 20:31, Charles R Harris charlesr.har...@gmail.com wrote: Hi Dag, This probably needs to be on the cython mailing list at some point, but I thought I'd start the discussion here. Numpy is going to begin deprecating direct access to ndarray/dtype internals, ala arr-data etc. There are currently macros/functions for many of these operations in the numpy development branch and I expect more to go in over the coming year. Also, some of the macros have been renamed. I don't know the best way for Cython to support this, but the current version (0.15 here) generates code that will fail if the deprecated things are excluded. Ideally, numpy.pxd would have numpy version dependent parts but I don't know if that is possible. In any case, I'd like your thoughts on the best way to coordinate this migration with Cython. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion This was discussed not too long ago on the cython-devel mailing list: http://mail.python.org/pipermail/cython-devel/2012-January/001848.html I personally think it'd be nice to not break existing Cython code, by e.g. writing nogil cdef properties (something which doesn't currently exist). That way the properties could use the non-deprecated way to actually access the data from numpy. (In any case the deprecated numpy functionality should go through a deprecation process before being removed). Alternatively, as Dag mentioned in the cython-devel thread, we could just deprecate the fields in Cython as well and place the burden on the user (and possibly issue warnings for their use). ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Migrating issues to GitHub
On 2/11/12 3:12 PM, Eric Firing wrote: A third problem is that the entire style of presentation is poorly designed from a use standpoint, in comparison to the sourceforge tracker which mpl used previously. The github tracker appears to have been designed by a graphics person, not a software maintainer. The information density in the issue list is very low; it is impossible to scan a large number of issues at once; there doesn't seem to be any useful sorting and selection mechanism. I agree. Also, another thing that is really frustrating is that the issue number does not appear in the listing. So when you are trying to refer to another issue, and try finding it by scanning the list, you have to mouse over the title and extract the information mentally from the url. Google code issues are much, much better in these regards. Jason ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] @Dag re numpy.pxd
On Sat, Feb 11, 2012 at 3:27 PM, mark florisson markflorisso...@gmail.comwrote: On 11 February 2012 20:31, Charles R Harris charlesr.har...@gmail.com wrote: Hi Dag, This probably needs to be on the cython mailing list at some point, but I thought I'd start the discussion here. Numpy is going to begin deprecating direct access to ndarray/dtype internals, ala arr-data etc. There are currently macros/functions for many of these operations in the numpy development branch and I expect more to go in over the coming year. Also, some of the macros have been renamed. I don't know the best way for Cython to support this, but the current version (0.15 here) generates code that will fail if the deprecated things are excluded. Ideally, numpy.pxd would have numpy version dependent parts but I don't know if that is possible. In any case, I'd like your thoughts on the best way to coordinate this migration with Cython. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion This was discussed not too long ago on the cython-devel mailing list: http://mail.python.org/pipermail/cython-devel/2012-January/001848.html I personally think it'd be nice to not break existing Cython code, by e.g. writing nogil cdef properties (something which doesn't currently exist). That way the properties could use the non-deprecated way to actually access the data from numpy. (In any case the deprecated numpy functionality should go through a deprecation process before being removed). In the nditer, some functions are explicitly documented with a mechanism to be called without holding the GIL. http://docs.scipy.org/doc/numpy/reference/c-api.iterator.html#NpyIter_Reset Internally, this produces a generic message that doesn't include the normal user-friendly context, but is still better than just spitting out runtime error. Is this style good for cython, or do you have any other ideas of how to support nogil while adding the possibility of raising errors? -Mark Alternatively, as Dag mentioned in the cython-devel thread, we could just deprecate the fields in Cython as well and place the burden on the user (and possibly issue warnings for their use). ___ 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] Migrating issues to GitHub
On Sat, Feb 11, 2012 at 3:12 PM, Eric Firing efir...@hawaii.edu wrote: On 02/11/2012 10:44 AM, Travis Oliphant wrote:snip 2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth). A third problem is that the entire style of presentation is poorly designed from a use standpoint, in comparison to the sourceforge tracker which mpl used previously. The github tracker appears to have been designed by a graphics person, not a software maintainer. The information density in the issue list is very low; it is impossible to scan a large number of issues at once; there doesn't seem to be any useful sorting and selection mechanism. The lack of a tabular way to mass-edit bugs is one of my biggest problems with the current trac. One thing that ideally we could do regularly is to rapidly triage 100s of bugs. Currently trac requires you to go through them one by one, like harvesting wheat with a scythe instead of a combine. Users who are mentioned in a lot of tickets also get spammed by a large number of message, instead of getting a single summary update of all the triaging that was done. Does the github bug tracker have a good story about mass bug-updating? -Mark This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins. This doesn't seem so bad to me, at least compared to the *really* bad aspects. On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing. So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal. The one good thing about the github tracker is its integration with the code. Otherwise it is still just plain bad, and will remain so until it is given an information-dense tabular interface, with things like initiation date, last update, category, priority, etc. Down with whitespace and icons! We need information! Eric -Travis On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote: On Saturday, February 11, 2012, Travis Oliphant tra...@continuum.io mailto:tra...@continuum.io wrote: How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments. The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves. Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration. Cheers! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto: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 mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] @Dag re numpy.pxd
On 11 February 2012 21:45, Mark Wiebe mwwi...@gmail.com wrote: On Sat, Feb 11, 2012 at 3:27 PM, mark florisson markflorisso...@gmail.com wrote: On 11 February 2012 20:31, Charles R Harris charlesr.har...@gmail.com wrote: Hi Dag, This probably needs to be on the cython mailing list at some point, but I thought I'd start the discussion here. Numpy is going to begin deprecating direct access to ndarray/dtype internals, ala arr-data etc. There are currently macros/functions for many of these operations in the numpy development branch and I expect more to go in over the coming year. Also, some of the macros have been renamed. I don't know the best way for Cython to support this, but the current version (0.15 here) generates code that will fail if the deprecated things are excluded. Ideally, numpy.pxd would have numpy version dependent parts but I don't know if that is possible. In any case, I'd like your thoughts on the best way to coordinate this migration with Cython. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion This was discussed not too long ago on the cython-devel mailing list: http://mail.python.org/pipermail/cython-devel/2012-January/001848.html I personally think it'd be nice to not break existing Cython code, by e.g. writing nogil cdef properties (something which doesn't currently exist). That way the properties could use the non-deprecated way to actually access the data from numpy. (In any case the deprecated numpy functionality should go through a deprecation process before being removed). In the nditer, some functions are explicitly documented with a mechanism to be called without holding the GIL. http://docs.scipy.org/doc/numpy/reference/c-api.iterator.html#NpyIter_Reset Internally, this produces a generic message that doesn't include the normal user-friendly context, but is still better than just spitting out runtime error. Is this style good for cython, or do you have any other ideas of how to support nogil while adding the possibility of raising errors? That's a nice way to support it. Cython itself often acquires the GIL in the exception case in nogil contexts, sets the exception, and then takes the error path. The problem with that is of course overhead, but it should usually do it for exceptional conditions only (i.e. things that normally should not occur, so not for normal conditions like raising StopIteration etc). However, we also want to get rid of the 'except' clause and in general need a way to check for error conditions for functions that have non-object return types and no known exceptional values for those types. For externally shared Cython functions this may mean exporting multiple versions with different ABIs, the point being that the user will not have to care, as taking the address or making it public would still give the normal C ABI compatible version of the function. Anyway, I digress. For NumPy that seems like a good thing to do. Perhaps it would be even nicer to pass in a pointer to npy_errorstate or some such, which holds complete error information. Then, with the GIL one could call something like npy_raise_from_errorstate(my_error_state). Functions could easily set the error type as well in there through a borrowed reference. -Mark Alternatively, as Dag mentioned in the cython-devel thread, we could just deprecate the fields in Cython as well and place the burden on the user (and possibly issue warnings for their use). ___ 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] Commit rights to NumPy for Francesc Alted
On Sat, Feb 11, 2012 at 2:13 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Feb 11, 2012 at 12:11 PM, Travis Oliphant tra...@continuum.iowrote: I propose to give Francesc Alted commit rights to the NumPy project. Francesc will be working full time on NumPy for several months and it will enable him to participate in pull requests. Francesc Alted has been very active in the larger Python for Science community and has written PyTables, Blosc, carray and made contributions to NumExpr.He was also instrumental in early design efforts around the fully-recursive dtype functionality of NumPy. Thoughts? Oh, definitely. +1. +1 as well -Mark 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] Migrating issues to GitHub
On Sat, Feb 11, 2012 at 9:49 PM, Mark Wiebe mwwi...@gmail.com wrote: On Sat, Feb 11, 2012 at 3:12 PM, Eric Firing efir...@hawaii.edu wrote: On 02/11/2012 10:44 AM, Travis Oliphant wrote:snip 2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth). A third problem is that the entire style of presentation is poorly designed from a use standpoint, in comparison to the sourceforge tracker which mpl used previously. The github tracker appears to have been designed by a graphics person, not a software maintainer. The information density in the issue list is very low; it is impossible to scan a large number of issues at once; there doesn't seem to be any useful sorting and selection mechanism. The lack of a tabular way to mass-edit bugs is one of my biggest problems with the current trac. One thing that ideally we could do regularly is to rapidly triage 100s of bugs. Currently trac requires you to go through them one by one, like harvesting wheat with a scythe instead of a combine. Users who are mentioned in a lot of tickets also get spammed by a large number of message, instead of getting a single summary update of all the triaging that was done. Does the github bug tracker have a good story about mass bug-updating? Github is better than trac on that issue: updating the milestone for many bugs at once is simple. You don't have priorities, etc…, though. The Rest API also enables in principle to write tools to automate the repetitive tasks. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Commit rights to NumPy for Francesc Alted
On Sat, Feb 11, 2012 at 11:11 AM, Travis Oliphant tra...@continuum.io wrote: I propose to give Francesc Alted commit rights to the NumPy project. I'm only surprised he didn't have them already, given how much he has contributed over the years! I remember when numpy was reaching 1.0 stage, the insane amount of careful, detailed feedback he provided, which I think was an important part of numpy 1.0 being a great success out of the gate. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Commit rights to NumPy for Francesc Alted
On Sat, Feb 11, 2012 at 11:06 PM, Fernando Perez fperez@gmail.comwrote: On Sat, Feb 11, 2012 at 11:11 AM, Travis Oliphant tra...@continuum.io wrote: I propose to give Francesc Alted commit rights to the NumPy project. +1. I'm only surprised he didn't have them already, given how much he has contributed over the years! With the github move, anyone who didn't ask for commit rights again doesn't have them anymore. Ralf I remember when numpy was reaching 1.0 stage, the insane amount of careful, detailed feedback he provided, which I think was an important part of numpy 1.0 being a great success out of the gate. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.
On Sat, Feb 11, 2012 at 7:51 PM, Travis Oliphant tra...@continuum.iowrote: NumPy 1.7 is due out in the next few weeks. This depends on whether all the issues regarding the move to gcc 4.x on Windows will be solved. Right now numpy is not releasable. Either those issues get solved, or we have to do something about the part of datetime that requires 4.x. Neither seems to be very easy. Ralf This will obviously support 2.4. It can be used for as long as people want. Right now, there is a plan for NumPy 1.8 to be released in the summer which will have much attention paid to it in order to improve the documentation, add bug-fixes, as well as make feature additions.Right now, the plan is to have that release support 2.5, however, major bug-fixes will be back-ported to the 1.7 series as patches are available. I suspect that different organizations will use different versions of NumPy as their own LTS.I plan on encouraging people to use 1.8 as the LTS. Work on NumPy 2.0 is already underway, but it will likely not be ready until January of 2013 at the earliest. Of course, there may be happy circumstances that accelerate that plan and other events that delay it. But, that is my best guess at the moment. Best, -Travis On Feb 10, 2012, at 3:25 AM, David Cournapeau wrote: On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant tra...@continuum.io wrote: I think supporting Python 2.5 and above is completely fine. I'd even be in favor of bumping up to Python 2.6 for NumPy 1.7 and certainly for NumPy 2.8 +1 for dropping Python 2.5 support also for an LTS release. That will make it a lot easier to use str.format() and the with statement (plus many other things) going forward, without having to think about if your changes can be backported to that LTS release. At the risk of sounding like a broken record, I would really like to stay to 2.4, especially for a long term release :) This is still the basis used by a lots of long-term python products. If we can support 2.4 for a LTS, I would then be much more comfortable to allow bumping to 2.5 for 1.8. 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] Want to eliminate direct for-loop
Hi, On Sat, Feb 11, 2012 at 10:56 PM, Dinesh B Vadhia dineshbvad...@hotmail.com wrote: ** Could the following be written without the direct for-loop? import numpy # numpy vector r of any data type and length, eg. r = numpy.ones(25, dtype='int') # s is a list of values (of any data type), eg. s = [47, 27, 67] # c is a list of (variable length) lists where the sub-list elements are index values of r and len(s) = len(c), eg. c = [[3, 6, 9], [6, 11, 19, 24], [4, 9, 11, 21 ]] # for each element in each sub-list c, add corresponding s value to the index value in r, eg. for i, j in enumerate(c): r[j] += s[i] So, we get: r[[3, 6, 9]] += s[0] = 1 + 47 = 48 r[[6, 11, 19, 24]] += s[1] = 1 + 27 = 28 r[[4, 9, 11, 21]] += s[2] = 1 + 67 = 68 ie. r = array([ 1, 1, 1, 95, 68, 1, 122, 1, 1, 162, 1, 95, 1, 1, 1, 1, 1, 1, 1, 28, 1, 68, 1, 1, 28]) Thank-you! Could you describe more detailed manner about why you want to get rid of that loop? Performance wise? If so, do you have profiled what's the bottleneck? Please provide also a more detailed description of your problem, since now your current spec seems to yield: r= array([ 1, 1, 1, 48, 68, 1, 75, 1, 1, 115, 1, 95, 1, 1, 1, 1, 1, 1, 1, 28, 1, 68, 1, 1, 28]) My 2 cents, -eat ___ 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] @Dag re numpy.pxd
On Sat, Feb 11, 2012 at 2:57 PM, mark florisson markflorisso...@gmail.comwrote: On 11 February 2012 21:45, Mark Wiebe mwwi...@gmail.com wrote: On Sat, Feb 11, 2012 at 3:27 PM, mark florisson markflorisso...@gmail.com wrote: On 11 February 2012 20:31, Charles R Harris charlesr.har...@gmail.com wrote: Hi Dag, This probably needs to be on the cython mailing list at some point, but I thought I'd start the discussion here. Numpy is going to begin deprecating direct access to ndarray/dtype internals, ala arr-data etc. There are currently macros/functions for many of these operations in the numpy development branch and I expect more to go in over the coming year. Also, some of the macros have been renamed. I don't know the best way for Cython to support this, but the current version (0.15 here) generates code that will fail if the deprecated things are excluded. Ideally, numpy.pxd would have numpy version dependent parts but I don't know if that is possible. In any case, I'd like your thoughts on the best way to coordinate this migration with Cython. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion This was discussed not too long ago on the cython-devel mailing list: http://mail.python.org/pipermail/cython-devel/2012-January/001848.html I personally think it'd be nice to not break existing Cython code, by e.g. writing nogil cdef properties (something which doesn't currently exist). That way the properties could use the non-deprecated way to actually access the data from numpy. (In any case the deprecated numpy functionality should go through a deprecation process before being removed). In the nditer, some functions are explicitly documented with a mechanism to be called without holding the GIL. http://docs.scipy.org/doc/numpy/reference/c-api.iterator.html#NpyIter_Reset Internally, this produces a generic message that doesn't include the normal user-friendly context, but is still better than just spitting out runtime error. Is this style good for cython, or do you have any other ideas of how to support nogil while adding the possibility of raising errors? That's a nice way to support it. Cython itself often acquires the GIL in the exception case in nogil contexts, sets the exception, and then takes the error path. The problem with that is of course overhead, but it should usually do it for exceptional conditions only (i.e. things that normally should not occur, so not for normal conditions like raising StopIteration etc). However, we also want to get rid of the 'except' clause and in general need a way to check for error conditions for functions that have non-object return types and no known exceptional values for those types. For externally shared Cython functions this may mean exporting multiple versions with different ABIs, the point being that the user will not have to care, as taking the address or making it public would still give the normal C ABI compatible version of the function. Anyway, I digress. For NumPy that seems like a good thing to do. Perhaps it would be even nicer to pass in a pointer to npy_errorstate or some such, which holds complete error information. Then, with the GIL one could call something like npy_raise_from_errorstate(my_error_state). Functions could easily set the error type as well in there through a borrowed reference. Another thing to worry about, arr-data can be NULL. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Want to eliminate direct for-loop
Sorry, I copy and pasted the wrong example r result - it should be as you say: r = array([ 1, 1, 1, 48, 68, 1, 75, 1, 1, 115, 1, 95, 1, 1, 1, 1, 1, 1, 1, 28, 1, 68, 1, 1, 28]) The reason for looking for an alternative solution is performance as the sizes of r, s and c are very large with the for-loop calculation repeated continuously (with different r, s and c). From: eat Sent: Saturday, February 11, 2012 3:12 PM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Want to eliminate direct for-loop Hi, On Sat, Feb 11, 2012 at 10:56 PM, Dinesh B Vadhia dineshbvad...@hotmail.com wrote: Could the following be written without the direct for-loop? import numpy # numpy vector r of any data type and length, eg. r = numpy.ones(25, dtype='int') # s is a list of values (of any data type), eg. s = [47, 27, 67] # c is a list of (variable length) lists where the sub-list elements are index values of r and len(s) = len(c), eg. c = [[3, 6, 9], [6, 11, 19, 24], [4, 9, 11, 21 ]] # for each element in each sub-list c, add corresponding s value to the index value in r, eg. for i, j in enumerate(c): r[j] += s[i] So, we get: r[[3, 6, 9]] += s[0] = 1 + 47 = 48 r[[6, 11, 19, 24]] += s[1] = 1 + 27 = 28 r[[4, 9, 11, 21]] += s[2] = 1 + 67 = 68 ie. r = array([ 1, 1, 1, 95, 68, 1, 122, 1, 1, 162, 1, 95, 1, 1, 1, 1, 1, 1, 1, 28, 1, 68, 1, 1, 28]) Thank-you! Could you describe more detailed manner about why you want to get rid of that loop? Performance wise? If so, do you have profiled what's the bottleneck? Please provide also a more detailed description of your problem, since now your current spec seems to yield: r= array([ 1, 1, 1, 48, 68, 1, 75, 1, 1, 115, 1, 95, 1, 1, 1, 1, 1, 1, 1, 28, 1, 68, 1, 1, 28]) My 2 cents, -eat ___ 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
