3 ms·

> since BEAM intentionally does not support arrays. I think tuples count: They're O(1) element access and fixed length. Binaries probably work better for ints

by geocar 9y ago

> since BEAM intentionally does not support arrays. I think tuples count: They're O(1) element access and fixed length. Binaries probably work better for ints though, since a NIF can do heavy work if you solve all the other problems. > Elixir would be a nice platform since both have lisp-y macros and 1st class AST support, so each language could pass ASTs to each other for execution. Julia could be used for heavy computational loads (which it excels at), and BEAM could handle IO, reliability, supervision, and process management (which it excels at). An Unfortunately, neither have what APL has: Good notation.

dnautics 9y ago
Tuples don't really count. For performance computing you really want arrays to have mutable contents. Julia's notation is incredibly math-oriented. f(x) = x+1 f(3) #==> 4 M = [2 0 0 2] v = [1,2] M * v #==> [2, 4] v' * v #==> 5 v' * M * v #==> 10 Note some subtleties: m = reshape([1,2],(2,1)) #==> 2x1 matrix m' * m #==> [5] m' * M * m #==> [10]
- geocar 9y ago
  > Tuples don't really count. For performance computing you really want arrays to have mutable contents. I don't think performance is the biggest win here, but: q/kdb+ doesn't have mutable arrays -- everything is copy-on-write, and it's a lot faster than Julia. If this hypothetical APLish language is otherwise useful, pulling a similar trick would benefit the rest of the Erlang ecosystem. > Julia's notation is incredibly math-oriented. APLs almost universally have better notation though. k/q follows: f:{1+x} /or even just f:1+ // apl is: {1+⍵} M:2 2#2 0 0 2f // apl is 2 2⍴2 0 0 2 v:1 2f M mmu v // k can be M$v; apl is M+.×v v mmu v // v+.×v v mmu M mmu v q is less good with your "subtleties" since it doesn't have rank (unlike other APLish languages), but I'm including it for completeness. m:enlist 2 1f m mmu' m m mmu' M mmu/: m Another APL would probably be better at those.
  - dnautics 9y ago
    How can you be "a lot faster" than Julia? Julia is regularly 1.2x C and sometimes faster than c when leveraging builtin fortran libraries. What's mmu? Is it matrix multiply? Why isn't it * What is the +.* operator? Can you show me where this operator is described in a non-apl math paper? Im sorry, but when i see apl, I just see a lot of symbols I can't bother to look up to understand. Code reviews would be a nightmare. in Julia, if I were to write a numerical type for galois fields (and I have), I could write compile-time optimized code for performing reed-solomon erasure coding using the builtin matrix operators - the code would be exactly the notation you see in the papers describing erasure coding. You can't do that in apl.
    - geocar 9y ago
      > Julia is regularly 1.2x C and sometimes faster than c when leveraging builtin libraries. It is very difficult to say a language is faster than another, and only slightly easier to say an implementation is faster. http://tech.marksblogg.com/benchmarks.html http://tech.marksblogg.com/benchmarks.html describes a number of benchmarks for an interesting data problem. kdb+ is the third fastest performer and the fastest CPU performer. kdb+ is 1000x faster than another database written in C (kdb+ is written in k); but only about 100x faster than other C-based databases. The next closest looks like Yandex Clickhouse which is written in C++ and still less than half the speed of kdb+. How much work is spent getting C++ to approach half the speed of an interpreted language? > How can you be "a lot faster" than Julia? That is an incredibly loaded question, but a big part of "how" is because of the notation: Because it's written in a language that is very dense, and puts parts of the solution near eachother, it is very easy to be correct, and to find repetitive parts of the program that can be coalesced and merged. > What's mmu? http://code.kx.com/q/ref/matrixes/#mmu http://code.kx.com/q/ref/matrixes/#mmu > Im sorry, but when i see apl, I just see a lot of symbols I can't bother to look up to understand. It never ceases to amaze me when a programmer thinks that just because they can't do something, that somehow that follows that nobody else should either. I mean, seriously! > Code reviews would be a nightmare. Why would you do code reviews in a language you don't understand? The dense and carefully chosen symbols and meanings in an APLish language is its value. Not that it's fast (although it is), but specifically that it's easy to understand. Heck, the article we're commenting about mentions several algorithms that are so much easier to understand in an array language than anything else.

by geocar 9y ago

dnautics 9y ago

Tuples don't really count. For performance computing you really want arrays to have mutable contents. Julia's notation is incredibly math-oriented. f(x) = x+1 f(3) #==> 4 M = [2 0 0 2] v = [1,2] M * v #==> [2, 4] v' * v #==> 5 v' * M * v #==> 10 Note some subtleties: m = reshape([1,2],(2,1)) #==> 2x1 matrix m' * m #==> [5] m' * M * m #==> [10]

geocar 9y ago
> Tuples don't really count. For performance computing you really want arrays to have mutable contents. I don't think performance is the biggest win here, but: q/kdb+ doesn't have mutable arrays -- everything is copy-on-write, and it's a lot faster than Julia. If this hypothetical APLish language is otherwise useful, pulling a similar trick would benefit the rest of the Erlang ecosystem. > Julia's notation is incredibly math-oriented. APLs almost universally have better notation though. k/q follows: f:{1+x} /or even just f:1+ // apl is: {1+⍵} M:2 2#2 0 0 2f // apl is 2 2⍴2 0 0 2 v:1 2f M mmu v // k can be M$v; apl is M+.×v v mmu v // v+.×v v mmu M mmu v q is less good with your "subtleties" since it doesn't have rank (unlike other APLish languages), but I'm including it for completeness. m:enlist 2 1f m mmu' m m mmu' M mmu/: m Another APL would probably be better at those.
- dnautics 9y ago
  How can you be "a lot faster" than Julia? Julia is regularly 1.2x C and sometimes faster than c when leveraging builtin fortran libraries. What's mmu? Is it matrix multiply? Why isn't it * What is the +.* operator? Can you show me where this operator is described in a non-apl math paper? Im sorry, but when i see apl, I just see a lot of symbols I can't bother to look up to understand. Code reviews would be a nightmare. in Julia, if I were to write a numerical type for galois fields (and I have), I could write compile-time optimized code for performing reed-solomon erasure coding using the builtin matrix operators - the code would be exactly the notation you see in the papers describing erasure coding. You can't do that in apl.
  - geocar 9y ago
    > Julia is regularly 1.2x C and sometimes faster than c when leveraging builtin libraries. It is very difficult to say a language is faster than another, and only slightly easier to say an implementation is faster. http://tech.marksblogg.com/benchmarks.html http://tech.marksblogg.com/benchmarks.html describes a number of benchmarks for an interesting data problem. kdb+ is the third fastest performer and the fastest CPU performer. kdb+ is 1000x faster than another database written in C (kdb+ is written in k); but only about 100x faster than other C-based databases. The next closest looks like Yandex Clickhouse which is written in C++ and still less than half the speed of kdb+. How much work is spent getting C++ to approach half the speed of an interpreted language? > How can you be "a lot faster" than Julia? That is an incredibly loaded question, but a big part of "how" is because of the notation: Because it's written in a language that is very dense, and puts parts of the solution near eachother, it is very easy to be correct, and to find repetitive parts of the program that can be coalesced and merged. > What's mmu? http://code.kx.com/q/ref/matrixes/#mmu http://code.kx.com/q/ref/matrixes/#mmu > Im sorry, but when i see apl, I just see a lot of symbols I can't bother to look up to understand. It never ceases to amaze me when a programmer thinks that just because they can't do something, that somehow that follows that nobody else should either. I mean, seriously! > Code reviews would be a nightmare. Why would you do code reviews in a language you don't understand? The dense and carefully chosen symbols and meanings in an APLish language is its value. Not that it's fast (although it is), but specifically that it's easy to understand. Heck, the article we're commenting about mentions several algorithms that are so much easier to understand in an array language than anything else.