The NumPy array: a structure for efficient numerical computation (2011) [pdf] | Hacker News Reader

The NumPy array: a structure for efficient numerical computation (2011) [pdf]

hal.inria.fr

126 pointskercker31 comments

The numpy array is a great data structure. I know it's not python but I wanted to plug our attempt at this for the jvm, nd4j:

http://nd4j.org/tensor

We have a java wrapper:

https://github.com/deeplearning4j/nd4j

Scala:

https://github.com/deeplearning4j/nd4s

And underlying c++:

https://github.com/deeplearning4j/libnd4j

We heavily dog food it in our deep learning library but we're hoping this can be more broadly useful for people.

That's great but what about nd4j's data structures resemble numpy arrays? Without making connection to the original most this comment just reads like typical spam.

In my experience, it's perfectly acceptable on HN to plug a related project in a comment, as long as it's not done repeatedly for totally unrelated projects (in 5+ years here, I can only think of 1 or 2 examples of this actually happening on a frequent basis).

Given that these are open source and not even commercial projects, and that this is presumably an enthusiastic developer for those projects just sharing his/her work with a potentially interested audience, I hardly think the "spam" label is appropriate.

And to answer your question specifically, based on what I've just read, ND4J offers an optimized n-dimensional array intended for numeric/scientific computing, very much in the manner of numpy. This is presumably what the comment's "our attempt at this for the jvm" refers to.

Yes it's a port of the associated concepts to the jvm. FWIW: we actually do use this commercially ;). It's apache though so do what you want with it etc.

Apologies if it came off like that but the main intent was to show an alternative implementation. If you actually look at the nd4j.org link you'll also notice a simpler/more concise description of the same concepts.

Eg: linear buffers,shapes, strides, offsets, dimensions

Apologies for assuming it wasn't commercial just because it was open source, my mistake. In any case, in my experience, comments regarding related non-commercial and commercial projects are quite welcome on HN.

It also looks like you have some support for GPU acceleration, which is cool since as far as I know (barring recent developments), numpy doesn't have this natively.

Oh haha not at all! You're right most of the time.

Yes we put a lot of work in to multi gpu and the like. Send me an email if you're interested in any details! Emails in profile.

I'll go ahead and ask a question here so others can benefit: do you have any plans to support OpenCL, or will you focus on Cuda?

We want to. Time/bandwidth is our problem right now. No one uses opencl in deep learning but we aren't against it if someone is willing to work on it.

Otherwise I'd have to pay someone a salary to do this..at the end of the day nd4j is part of what keeps us going.

your question caused me to spend a little time comparing the two (NumPy, which i know quite well, and nd4j, which i don't know at all).

so based on comparison, it's clear the nd4j uses the key structural features of numpy arrays--linear buffers, strides, bit-wise and integer indexing, etc.--and the coincidence in the two APIs is also very high (eg, comparing the methods for a 2D NumPy array versus those for a 2D nd4j array).

in my view, this is an impressive project, both w/r/t the work done to date and w/r/t the impact on java and scala open-source communities. In Scala land for instance, the most widely used matrix computation library is Breeze, which i've never found easy to use. nd4j, in particular, the Scala bindings, nd4s, seem to me to be a substantial improvement both in architecture and in the api.

If you like NumPy, it might be worth taking a look at Dask[1]. Very similar API, but designed to support arrays larger than memory, as well as operations across a network cluster.

[1] http://dask.pydata.org/en/latest/

If only it was also available for C++. Armadillo is nice but it has a lot of important differences, and doesn't seem to support more than 3 dimensional matrices.

There was some effort toward getting it in Boost. https://github.com/ndarray/Boost.NumPy

You might want to check out the Eigen library: http://eigen.tuxfamily.org/

If you want multidimensional arrays in C++, then blitz++ is your friend.

There is Eigen but it wont do multidimensional stuff. Although there might be a few projects out there that wrap the multidimensional functionality around Eigen arrays.

One such multidimensional extension of Eigen is from Google and I believe was extracted from TensorFlow:

https://bitbucket.org/eigen/eigen/src/039efd86b75ce1b72befb7...

Here is my Blitz++-inspired hobby project, supports arbitrary rank: https://github.com/lloda/ra-ra

I'm sure you can find more polished efforts if you look around.

Arrayfire is c++ with Opencl, cuda, and cpu back ends. Limited to 4d. http://arrayfire.com/indexing-with-arrayfire/

Also something like this but for .NET?

It's a shame that there is no consolidated way to provide index labels to both columns and rows without wrapping this in another class (e.g., your own, or pandas). R's matrices and arrays are very convenient as they provide this functionality out-of-the-box.

I'm not terribly familiar with R, but I've used Pandas a bit. Could you accomplish what you're looking for with structured arrays or record arrays in Numpy?

http://docs.scipy.org/doc/numpy/user/basics.rec.html

Record arrays only provide indexing by name along columns, unfortunately. So if you want index labels along both dimensions (in 2-D), Pandas is necessary. There is no good option for the N-D case that I can find (R's native array has this capability by default though).

This type is my bread and butter. I breathe numpy arrays in my research.

What an interesting juxtaposition of idioms :)

How about an efficient structure for storing "actual" arrays in python. Numpy is my friend.

Does PyPy have enough type inference smarts to figure out when it can use a homogeneous array? In CPython, everything, including every array entry, is a CObject. (Except strings and now, bytearrays. They're special.) That's why Python arrays of numbers are so slow.

NumPy's representation is very close to that of FORTRAN. This problem was mostly solved in the 1950s and 1960s, when FORTRAN DO-loop optimizations for arrays got good.

http://doc.pypy.org/en/latest/release-1.8.0.html It does this since 1.8 it seems (mentioned under 'list specialization'). Probably 'type inference' isn't the right way to describe it. It will optimistically assume it's a homogeneous array and will have to recreate this array if the assumption is broken. This will be useful in the vast majority of cases, as mixed type arrays are not usually used in performance-sensitive code.

Further, there is almost always a better data structure for any mixed-type list. So if you know your code will go through pypy, you can just use a different structure.

What kind of DO-loop optimizations were there?

The same ones we have now. Advancing through an array with pointers instead of computing the subscript each time. Advancing down a higher dimension of an array with a stride. Backus had those working in a FORTRAN compiler in the 1950s. If FORTRAN had been slower than assembly, nobody would have used it; machines were too slow and too expensive.

You mean like the array[1] that's in the standard library?

[1]: https://docs.python.org/3/library/array.html

dynd is next generation numpy for language-agnostic usage: https://github.com/libdynd/libdynd

Reply on news.ycombinator.com