Re: [Numpy-discussion] PEP 465 has been accepted / volunteers needed
On 4/9/14, 10:46 PM, Chris Barker wrote: On Tue, Apr 8, 2014 at 11:14 AM, Nathaniel Smith n...@pobox.com mailto:n...@pobox.com wrote: Thank you! Though I suspect that the most important part of my contribution may have just been my high tolerance for writing emails ;-). no -- it's your high tolerance for _reading_ emails... Far too many of us have a high tolerance for writing them! Ha ha, very true! -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PEP 465 has been accepted / volunteers needed
On Thu, Apr 10, 2014 at 4:43 AM, Francesc Alted fal...@gmail.com wrote: On 4/9/14, 10:46 PM, Chris Barker wrote: On Tue, Apr 8, 2014 at 11:14 AM, Nathaniel Smith n...@pobox.com mailto:n...@pobox.com wrote: Thank you! Though I suspect that the most important part of my contribution may have just been my high tolerance for writing emails ;-). no -- it's your high tolerance for _reading_ emails... Far too many of us have a high tolerance for writing them! Ha ha, very true! I'm trying, but it's hard. Sometimes avoiding the `send` button helps. I still have a collection of draft replies. Josef I'm not going to send this reply -- oops, did it again -- 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] PEP 465 has been accepted / volunteers needed
Hello, I really think that add a new operator @ is not a good thing. Sorry I just want to make a joke... ;-) Christophe BAL 2014-04-10 15:11 GMT+02:00 josef.p...@gmail.com: On Thu, Apr 10, 2014 at 4:43 AM, Francesc Alted fal...@gmail.com wrote: On 4/9/14, 10:46 PM, Chris Barker wrote: On Tue, Apr 8, 2014 at 11:14 AM, Nathaniel Smith n...@pobox.com mailto:n...@pobox.com wrote: Thank you! Though I suspect that the most important part of my contribution may have just been my high tolerance for writing emails ;-). no -- it's your high tolerance for _reading_ emails... Far too many of us have a high tolerance for writing them! Ha ha, very true! I'm trying, but it's hard. Sometimes avoiding the `send` button helps. I still have a collection of draft replies. Josef I'm not going to send this reply -- oops, did it again -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Fwd: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication
Hey all, Given the sometimes rocky history of collaboration between numerical Python and core Python, I thought it might be helpful to flag this posting for broader distribution -- it gives one perspective on how the core devs see things. (And is certainly consistent with my experience around PEP 465.) (Nick is, among other things, core Python's packaging czar, and previously on record [1] as wishing for more feedback on how the current energy around python packaging could take our needs into account.) -n [1] https://ncoghlan_devs-python-notes.readthedocs.org/en/latest/pep_ideas/core_packaging_api.html#a-long-caveat-on-this-essay -- Forwarded message -- From: Nick Coghlan ncogh...@gmail.com Date: Tue, Apr 8, 2014 at 1:32 PM Subject: Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication To: Björn Lindqvist bjou...@gmail.com Cc: Sturla Molden sturla.mol...@gmail.com, python-...@python.org python-...@python.org On 8 April 2014 21:24, Björn Lindqvist bjou...@gmail.com wrote: 2014-04-08 12:23 GMT+02:00 Sturla Molden sturla.mol...@gmail.com: Björn Lindqvist bjou...@gmail.com wrote: import numpy as np from numpy.linalg import inv, solve # Using dot function: S = np.dot((np.dot(H, beta) - r).T, np.dot(inv(np.dot(np.dot(H, V), H.T)), np.dot(H, beta) - r)) # Using dot method: S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r) Don't keep your reader hanging! Tell us what the magical variables H, beta, r and V are. And why import solve when you aren't using it? Curious readers that aren't very good at matrix math, like me, should still be able to follow your logic. Even if it is just random data, it's better than nothing! Perhaps. But you don't need to know matrix multiplication to see that those expressions are not readable. And by extension, you can still imagine that bugs can easily hide in unreadable code. Matrix multiplications are used extensively in anything from engineering to statistics to computer graphics (2D and 3D). This operator will be a good thing for a lot of us. All I ask for is to be able to see that with my own eyes. Maybe there is some drastic improvement I can invent to make the algorithm much more readable? Then the PEP:s motivation falls down. I don't want to have to believe that the code the pep author came up with is the most optimal. I want to prove that for myself. Note that the relationship between the CPython core development team and the Numeric Python community is based heavily on trust - we don't expect them to teach us to become numeric experts, we just expect them to explain themselves well enough to persuade us that a core language or interpreter change is the only realistic way to achieve a particular goal. This does occasionally result in quirky patterns of feature adoption, as things like extended slicing, full rich comparison support, ellipsis support, rich buffer API support, and now matrix multiplication support, were added for the numeric community's benefit without necessarily offering any immediately obvious benefit for those not using the numeric Python stack - it was only later that they became pervasively adopted throughout the standard library (with matmul, for example, a follow on proposal to allow tuples, lists and arrays to handle vector dot products may make sense). This particular problem has been kicking around long enough, and is sufficiently familiar to several of us, that what's in the PEP already presents a compelling rationale for the *folks that need to be convinced* (which is primarily Guido, but if enough of the other core devs think something is a questionable idea, we can often talk him out of it - that's not the case here though). Attempting to condense that preceding 10+ years of history *into the PEP itself* wouldn't be a good return on investment - the links to the earlier PEPs are there, as are the links to these discussion threads. Cheers, Nick. P.S. We've been relatively successful in getting a similar trust based dynamic off the ground for the packaging and distribution community over the past year or so. The next big challenge in trust based delegation for the core development team will likely be around a Python 3.5+ only WSGI 2.0 (that can assume the Python 3 text model, the restoration of binary interpolation, the availability of asyncio, etc), but most of the likely principals there are still burned out from the WSGI 1.1 debate and the Python 3 transition in general :( -- mvh/best regards Björn Lindqvist ___ Python-Dev mailing list python-...@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list python-...@python.org
[Numpy-discussion] Wiki page for building numerical stuff on Windows
Hi, I've been working on a general wiki page on building numerical stuff on Windows: https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows I'm hoping to let Microsoft know what problems we're having, and seeing whether we numericists can share some work - us and R and Julia and Octave and so on. Feedback / edits very - very - welcome, Cheers, matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Wiki page for building numerical stuff on Windows
Matthew Brett matthew.br...@gmail.com wrote: Hi, I've been working on a general wiki page on building numerical stuff on Windows: https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows I'm hoping to let Microsoft know what problems we're having, and seeing whether we numericists can share some work - us and R and Julia and Octave and so on. Feedback / edits very - very - welcome, Is seems Microsoft is working on an accelerate framework on their own. https://ampblas.codeplex.com https://amplapack.codeplex.com https://ampfft.codeplex.com https://amprng.codeplex.com https://ampalgorithms.codeplex.com It seems to be written in C++ and require VS2012 to build, and possibly DirectX11 to run. Apache license, from what I can see. Sturla P.S. GotoBLAS2 is spelled with capital G and a trailing 2. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Wiki page for building numerical stuff on Windows
Hi, On Thu, Apr 10, 2014 at 8:10 PM, Sturla Molden sturla.mol...@gmail.com wrote: Matthew Brett matthew.br...@gmail.com wrote: Hi, I've been working on a general wiki page on building numerical stuff on Windows: https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows I'm hoping to let Microsoft know what problems we're having, and seeing whether we numericists can share some work - us and R and Julia and Octave and so on. Feedback / edits very - very - welcome, Is seems Microsoft is working on an accelerate framework on their own. https://ampblas.codeplex.com https://amplapack.codeplex.com https://ampfft.codeplex.com https://amprng.codeplex.com https://ampalgorithms.codeplex.com It seems to be written in C++ and require VS2012 to build, and possibly DirectX11 to run. For ampblas : https://ampblas.codeplex.com/SourceControl/latest#readme.txt This library contains an adaptation of the legacy cblas interface to BLAS for C++ AMP. At this point almost all interfaces are not implemented. One exception is the ampblas_saxpy and ampblas_daxpy which serve as a template for the implementation of other routines. Last commit appears to be October 2012 : https://ampblas.codeplex.com/SourceControl/list/changesets Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
