[Numpy-discussion] ANN: Biggus 0.5
I'm pleased to announce the release of Biggus version 0.5.0. Biggus is a pure Python library for handling virtual n-dimensional arrays of arbitrary size, and providing lazy/deferred evaluation of arithmetic and statistical operations. Biggus works with your n-dimensional array data in whatever form it currently resides - no data conversion is necessary. The documentation can be found at: http://biggus.readthedocs.org/ And it can be installed with pip via: pip install biggus The main feature of this release is a new multi-threaded evaluation engine which provides the ability to compute statistics efficiently across any axis. Future plans include: - Expand the range of arithmetic and statistical operators. - Extend the evaluation API to allow multiple simultaneous file-based outputs. - An API to simplify the creation of user-defined operators. - Multiply-concurrent execution of CPU intensive operators. - Low-level evaluation optimisation, e.g numexpr/numba. Constructive feedback is very welcome! - Raise an issue on GitHub, https://github.com/SciTools/biggus - Post on the discussion group: https://groups.google.com/forum/#!forum/scitools-biggus ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] GSoC project: draft of proposal
Hi, The attachment is my draft of proposal. The project is vector math library integration. I think I need some feedback to make it solider. Any comment will be appreciated. Thanks in advance. Regards, Leo Mao text/html; charset=US-ASCII; name="proposal.html": Unrecognized ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] GSoC project: draft of proposal
Hi Leo, Out of curiosity, which vector math libraries did you have in mind as likely candidates for inclusion? How are you planning on selecting the library to integrate? Cheers, Aron On Wed, Mar 12, 2014 at 12:52 PM, Leo Mao lmao20...@gmail.com wrote: Hi, The attachment is my draft of proposal. The project is vector math library integration. I think I need some feedback to make it solider. Any comment will be appreciated. Thanks in advance. Regards, Leo Mao ___ 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] GSoC project: draft of proposal
Hi Aron, Previously mentioned by Julian, Yeppp may be a good candidate. As for selecting a good library, I will consider the performance and the API of the library. The integration of the library should improve the performance of numpy and also not make the source too complicated to maintain. And I think the library should be mature so that the API will not be changed significantly. Please point out if there is something I miss. Also I will be grateful to any suggestions for my proposal. Regards, Leo Mao On Thu, Mar 13, 2014 at 12:54 AM, Aron Ahmadia a...@ahmadia.net wrote: Hi Leo, Out of curiosity, which vector math libraries did you have in mind as likely candidates for inclusion? How are you planning on selecting the library to integrate? Cheers, Aron On Wed, Mar 12, 2014 at 12:52 PM, Leo Mao lmao20...@gmail.com wrote: Hi, The attachment is my draft of proposal. The project is vector math library integration. I think I need some feedback to make it solider. Any comment will be appreciated. Thanks in advance. Regards, Leo Mao ___ 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] GSoC project: draft of proposal
On Wed, Mar 12, 2014 at 11:12 AM, Leo Mao lmao20...@gmail.com wrote: Hi Aron, Previously mentioned by Julian, Yeppp may be a good candidate. As for selecting a good library, I will consider the performance and the API of the library. The integration of the library should improve the performance of numpy and also not make the source too complicated to maintain. And I think the library should be mature so that the API will not be changed significantly. Please point out if there is something I miss. Also I will be grateful to any suggestions for my proposal. Regards, Leo Mao On Thu, Mar 13, 2014 at 12:54 AM, Aron Ahmadia a...@ahmadia.net wrote: Hi Leo, Out of curiosity, which vector math libraries did you have in mind as likely candidates for inclusion? How are you planning on selecting the library to integrate? Cheers, Aron On Wed, Mar 12, 2014 at 12:52 PM, Leo Mao lmao20...@gmail.com wrote: Hi, The attachment is my draft of proposal. The project is vector math library integration. I think I need some feedback to make it solider. Any comment will be appreciated. Thanks in advance. Regards, Leo Mao The proposal as it stands is too open ended and lacking in specifics. Probably you should select a library before the start of GSOC, or at least have a list of candidates, and also narrow the part of numpy you want to improve to something definite: linalg, special functions, etc. That doesn't mean you can't do more if time allows ;) An estimate of expected gains over current code would also help. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Matrix multiplication infix operator PEP nearly ready to go
Hi all, The proposal to add an infix operator to Python for matrix multiplication is nearly ready for its debut on python-ideas; so if you want to look it over first, just want to check out where it's gone, then now's a good time: https://github.com/numpy/numpy/pull/4351 The basic idea here is to try to make the strongest argument we can for the simplest extension that we actually want, and then whether it gets accepted or rejected at least we'll know that's final. Absolutely all comments and feedback welcome. Cheers, -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Matrix multiplication infix operator PEP nearly ready to go
On 3/12/2014 6:04 PM, Nathaniel Smith wrote: https://github.com/numpy/numpy/pull/4351 The Semantics section still begins with 0d, then 2d, then 1d, then nd. Given the context of the proposal, the order should be: 2d (the core need expressed in the proposal) nd (which generalizes via broadcasting the 2d behavior) 1d (special casing) 0d (error) In this context I see one serious problem: is there a NumPy function that produces the proposed nd behavior? If not why not, and can it really be sold as a core need if the need to implement it has never been pressed to the point of an implementation? Unless this behavior is first implemented, the obvious question remains: why will `@` not just implement `dot`, for which there is a well tested and much used implementation? Note I am not taking a position on the semantics. I'm just pointing out a question that is sure to arise. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Matrix multiplication infix operator PEP nearly ready to go
On Thu, Mar 13, 2014 at 1:03 AM, Alan G Isaac alan.is...@gmail.com wrote: On 3/12/2014 6:04 PM, Nathaniel Smith wrote: https://github.com/numpy/numpy/pull/4351 The Semantics section still begins with 0d, then 2d, then 1d, then nd. Given the context of the proposal, the order should be: 2d (the core need expressed in the proposal) nd (which generalizes via broadcasting the 2d behavior) 1d (special casing) 0d (error) I've just switched it to 2d - 1d - 3d+ - 0d. You're right that 2d should go first, but IMO 1d should go after it because 2d and 1d are the two cases that really get used heavily in practice. In this context I see one serious problem: is there a NumPy function that produces the proposed nd behavior? If not why not, and can it really be sold as a core need if the need to implement it has never been pressed to the point of an implementation? The logic isn't we have a core need to implement these exact semantics. It's: we have a core need for this operator; given that we are adding an operator we have to figure out exactly what the semantics should be; we did that and documented it and got consensus from a bunch of projects on it. I don't think the actual details of the semantics matter nearly as much as the fact that they exist. Unless this behavior is first implemented, the obvious question remains: why will `@` not just implement `dot`, for which there is a well tested and much used implementation? Because of the reason above, I'm not sure it will come up (I don't think python-dev is nearly as familiar with the corner cases of numpy.dot as we are :-)). But if it does the answer is easy: no-one ever thought through exactly how `dot` should work in these rare edge cases, now we did. But we can't just change `dot` quickly, because of backwards compatibility considerations. `@` is new, there's no compatibility problem, so we might as well get it right from the start. If the behavioural differences between `dot` and `@` were more controversial then I'd worry more. But the consequences of the 0d thing are trivial to understand, and in the 3d+ case we're already shipping dozens of functions that have exactly these broadcasting semantics. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
