Thoughts on porting NumPy to PyPy
technicaldiscovery.blogspot.com
Thoughts on porting NumPy to PyPy
1–10 of 34 posts
Re: Thoughts on porting NumPy to PyPy
#2I love it when someone writes an articulate, non-inflamatory blog post with reasonable suggestions on how to improve things. It's sad how rare this is around here these days.
Re: Thoughts on porting NumPy to PyPy
#3I couldn't agree more. This is related to another recent HN posting (http://news.ycombinator.com/item?id=3104598) and discussions at PyCodeConf in Miami. There's a general feeling (which I've experienced in many of my interactions with non-scientific Python programmers) that the folks working on pure Python don't really "get" the scientific Python community. We would all understand each other better if the PyPy folks or the Python core developers spent a year, say, working at Enthought on scientific Python consulting projects or working on a core project that uses NumPy/SciPy like scikit-learn, matplotlib, statsmodels, theano, pandas, or many, many others. A small annoyance but having a matrix multiplication infix operator would actually be a huge help but the idea has met a great deal of resistance from core Python as being "too domain specific". It strikes me as very short-sighted as I think Python is well-poised to make waves in the data analysis, statistics, and high performance computing ecosystem. Having used Python to build large systems for financial applications, I am acutely aware of how Python is being used in that industry and some of the ways that it needs to adapt to be more relevant. So bravo, Travis, for speaking up!
Also, his point that Cython (http://cython.org) tends to be ignored in the broader discussion about performance computing in Python is especially flagrant when you consider how it's revolutionized the way that scipythonistas (myself included) speed up their code over the last 2-3 years.
Re: Thoughts on porting NumPy to PyPy
#4> There were a lot of young people there who understood a lot more about making web-pages and working at cool web start-ups than solving partial differential equations with arrays.
I can especially relate to this, even though I'm 26. Admittedly, I work in a microcosm though, where I'm the youngest, least educated and least experienced in my group, despite having a BS in Physics and 4 years research in particle astrophysics.
Luckily we do a little less with matrix operations, but I agree that Python, specifically PyPy, has so much potential to be the scientific computing standard and that the python community should really push for it. In a world with less python, there's so much pain involved on a regular basis setting up software like ROOT, switching between libraries of FFTs or plot libraries, installing Octave or Matlab to work nice with some bash script and dealing with OS discrepancies in getting someone else's code to run. It sucks.
If PyPy can displace that with near-C performance, the world would be a much better place.
Re: Thoughts on porting NumPy to PyPy
#5I was going to do a Cython lightning talk, but the organizers indicated that we ran out of time slots, so I could only give one talk. Half of the audience at PyCodeConf indicated they were aware of the Cython project, although perhaps it would have been useful regardless...
Re: Thoughts on porting NumPy to PyPy
#6I just don't see adding a special matrix infix operator to Python happening. It is too specialized, and yet matrix is not special enough that it must have its own operator. Isn't this what operator overloading is for?
I suspect the real problem is NumPy's type system implementation, since data-types are not visible as different Python types.
Re: Thoughts on porting NumPy to PyPy
#7I love it when someone writes an articulate, non-inflamatory blog post with reasonable suggestions on how to improve things. It's sad how rare this is around here these days.
I think they are always around but just don't make it to the front page as the link bait articles get the attention.
Re: Thoughts on porting NumPy to PyPy
#8I just don't see adding a special matrix infix operator to Python happening. It is too specialized, and yet matrix is not special enough that it must have its own operator. Isn't this what operator overloading is for? I suspect the real problem is NumPy's type system implementation, since data-types are not visible as different Python types.
If you spent a day doing some serious linear algebra in Python you might change your tune. * (multiplication) between NumPy arrays by default does element-wise multiplication (potentially with broadcasting), which is the desired default behavior. In R, for example, you can define custom infix operators so that
a * b
is elementwise but
a %* % b
is matrix multiplication. If you write down a complicated linear algebra expression, something like
A.T ! (B.T ! C ! B).T ! A
would be a lot friendlier to scientists than the current:
dot(A.T, dot(dot(B.T, dot(C, B)).T, A))
You might just say "well suck it up" but I've got to say that doing linear algebra in Matlab is a lot easier because the linear algebra that I do with pen and paper looks pretty much exactly the same as the corresponding code. On the other hand, Matlab is super clunky compared with NumPy at doing APL-style array processing with broadcasting operations, etc. In my work I tend to do more of the latter and less of the former but whenever I implement something with a lot of matrix multiplications it takes me a lot longer in Python to get things right.
Anyway, the point is: non-scientific Python folks need to take a walk in our shoes to gain an understanding of the challenges we face on a ongoing basis.
I'm having a hard time understanding your last statement. NumPy data types (dtypes) simply tell the ndarray how to interpret the block of data associated with it (the # of bytes per item, shape, and strides).
Re: Thoughts on porting NumPy to PyPy
#9I just don't see adding a special matrix infix operator to Python happening. It is too specialized, and yet matrix is not special enough that it must have its own operator. Isn't this what operator overloading is for? I suspect the real problem is NumPy's type system implementation, since data-types are not visible as different Python types.
I'm just wondering how much you were hurt by the ellipsis built-in. After all, the ellipsis built-in was (at least for many years) of absolutely no use to anyone other than those using certain libraries for scientific computing. The rest of us had to put up with the pain of having yet one more line in the documentation. Frankly, for me it didn't hurt much.
As a general rule, "Special cases aren't special enough to break the rules", but like everything in Zen it is a balance. If a very large community of Python users (and the scientific users ARE a large and important subset of Python users) say they would benefit significantly from this change, then perhaps this is the exception -- especially since the "cost" (in additional complexity) is fairly small.
Re: Thoughts on porting NumPy to PyPy
#10I just don't see adding a special matrix infix operator to Python happening. It is too specialized, and yet matrix is not special enough that it must have its own operator. Isn't this what operator overloading is for? I suspect the real problem is NumPy's type system implementation, since data-types are not visible as different Python types.
If you spent a day doing some serious linear algebra in Python you might change your tune. * (multiplication) between NumPy arrays by default does element-wise multiplication (potentially with broadcasting), which is the desired default behavior. In R, for example, you can define custom infix operators so that a * b is elementwise but a %* % b is matrix multiplication. If you write down a complicated linear algebra e…
I guess it would be possible to implement with a with-hack...
with numpy.doing_matrix:
matrixy_multiply_goodness = m1 * m2