Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's worth noting that the behavior is totally different if you pass higher dimensional matrices. The Fortran, Python, Haskell, etc. code will all break or fail to typecheck, whereas the APL/J/K implicitly maps over them. Understanding this topic ("rank") is a major source of confusion for new users and power for existing users, as lots of different mapping regimes can be obtained without a lot of additional operators.

The rank operator in J (and probably Dyalog APL) allows you to treat a 3D matrix as an array of 2D matrices, a 2D matrix of arrays, a single item or a bunch of unit-sized boxes. This concept generalizes to higher dimensions. I don't think this aspect of array programming has gotten as much airtime as it deserves, probably because it is complex, but this is where the semantics of array languages and conventional languages really differ.



The Python-with-NumPy example I gave at https://news.ycombinator.com/item?id=16849500 supports higher dimensional matrices:

  >>> import numpy as np
  >>> np.multiply.reduce(np.array([[1,2,3,4], [5,6,7,8]]))
  array([ 5, 12, 21, 32])
and it lets you reshape into different forms, like:

  >>> arr = np.array([[1,2,3,4], [5,6,7,8]])
  >>> np.multiply.reduce(arr.flatten())
  40320
  >>> np.multiply.reduce(arr.reshape((4,2)))
  array([105, 384])
  >>> np.multiply.reduce(arr.reshape((2,2,2)))
  array([[ 5, 12],
         [21, 32]])
I believe this was influenced by the array languages.


Very cool, I did not know that! Thank you for posting this example!


It seems to me that mathematical higher dimensional matrices are, in the broad scheme of programming languages, a corner case. Certainly a big one and an important one, but not one that was ever likely to drive general purpose languages.

Indeed, I'd argue that if that was your primary use case you are and always were better off with a relatively custom language (relative to programming as a whole), because the needs are so different and the wins so big using an environment set up to support those needs that you'll want that in the end. You can fuzz the line with things like NumPy, because all these lines are fuzzy, but dedicated support will be a big win in the end.


I think it's kind of a chicken-and-egg question, personally. Compared to array languages, most other programming languages are, in a sense, tree-oriented. Does their prevalence mean that our problems are mostly tree-structured? Or is our propensity to see problems as tree-structured a result of brainwashing by our tools? "A prisoner falls in love with his chains" as Dijkstra said.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: