Thoughts on porting NumPy to PyPy • Hacker News Board

Re: Thoughts on porting NumPy to PyPy

#31

Post by hogu » Tue, Oct 18, 2011, 2:02 AM UTC

wesm wrote: post #8

eastwest wrote: post #6

I 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…

operator overloading doesn't solve the problem because you frequently mix elementwise operations with matrix multiplication and division. Converting types between numpy arrays and matrices gets cumbersome

Re: Thoughts on porting NumPy to PyPy

#32

Post by scott_s » Tue, Oct 18, 2011, 11:35 AM UTC

kragen wrote: post #28

scott_s wrote: post #18

Earlier quoted context omitted.

I see your point, and it is why I tend to like operator overloading in languages. However, Python is a general purpose language, and scientific computing is a single domain. It is used in many different domains. Consider that there are many changes that individual communities would like, and if Python granted all of those requests, the language would be a mess. That's the challenge in designing a general purpose prog…

> Python is a general purpose language, and scientific computing is a single domain. I think this is shortsighted to the point of ignorance. "Scientific computing" here really means "performance-critical numerical computation on regular arrays". Basically all of the new things that people are doing with computers in the last five years and the next five years — machine learning and other statistics, software-defined…

I do research in high performance computing. I am well aware of the importance of performance critical, number crunching code that operates on large arrays. I wrote an entire dissertation based around better ways of expressing large computations on dense vectors and matrices for new multicores.

I am, however, self-aware enough to recognize that what I care about is a subset of what everyone in computing cares about. Scientific computing may be important in multiple places, but it is still a single domain. An important domain, sure. But Python is still used in many places were such concerns are not important. Arguments about the utility of number crunching on dense vectors and matrices are great. But the attitude I've seen in this thread is "the domain I care about is so important that my concerns should be elevated above the concerns of other domains." That is not going to fly when it comes to changing a general purpose language used in many domains.

Re: Thoughts on porting NumPy to PyPy

#33

Post by kragen » Wed, Oct 19, 2011, 12:58 AM UTC

scott_s wrote: post #32

kragen wrote: post #28

Earlier quoted context omitted.

> Python is a general purpose language, and scientific computing is a single domain. I think this is shortsighted to the point of ignorance. "Scientific computing" here really means "performance-critical numerical computation on regular arrays". Basically all of the new things that people are doing with computers in the last five years and the next five years — machine learning and other statistics, software-defined…

I do research in high performance computing. I am well aware of the importance of performance critical, number crunching code that operates on large arrays. I wrote an entire dissertation based around better ways of expressing large computations on dense vectors and matrices for new multicores. I am, however, self-aware enough to recognize that what I care about is a subset of what everyone in computing cares about.…

I'm sure you know enormously more than I do about how to do dense-array number crunching. My claim, though, is that it's being applied much more widely than previously, not that there are new and better ways of doing it; so there are fewer and fewer places where such concerns are not important.

In the 1960s, there were those who claimed that the benefit of recursion was not worth the complexity it added to programming languages, except in certain special domains. In the 1970s and 1980s, we had the same argument about depth-first search — SNOBOL's and Prolog's backtracking feature. It turned out that the proponents of recursion were right, and the proponents of backtracking were probably wrong. (Although the backtracking feature of SNOBOL's child Icon directly inspired Python's generators, although implementationally they're maybe more similar to CLU iterators.)

Now, when it comes to matrix and vector manipulation, should we imagine it as a single domain, or as a feature that's useful across a wide range of domains?

I'm arguing for the latter.

Re: Thoughts on porting NumPy to PyPy

#34

Post by scott_s » Wed, Oct 19, 2011, 2:56 AM UTC

kragen wrote: post #33

scott_s wrote: post #32

Earlier quoted context omitted.

I do research in high performance computing. I am well aware of the importance of performance critical, number crunching code that operates on large arrays. I wrote an entire dissertation based around better ways of expressing large computations on dense vectors and matrices for new multicores. I am, however, self-aware enough to recognize that what I care about is a subset of what everyone in computing cares about.…

I'm sure you know enormously more than I do about how to do dense-array number crunching. My claim, though, is that it's being applied much more widely than previously, not that there are new and better ways of doing it; so there are fewer and fewer places where such concerns are not important. In the 1960s, there were those who claimed that the benefit of recursion was not worth the complexity it added to programmin…

And I'm arguing that's still one concern among many when it comes to a language used in so many different places. The arguments here are, I think, unsympathetic to the difficulties of designing and maintaing a general purpose programming language, in particular one with the design goals of Python.