3 ms·

> 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:

by 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.
  - dnautics 9y ago
    >Why would you do code reviews in a language you don't understand Happens all the time. I've done it three times now at my startup. One coworker had to do cross-language code reviews at Google.
    - geocar 9y ago
      > I've done it three times now at my startup. One coworker had to do cross-language code reviews at Google [in a language they don't know]. That sounds absolutely bonkers. > I've done it three times now at my startup. How can you possibly have something to contribute? Do you also review the Chinese-localised version of your website? Seems like crazy levels of bikeshedding, but I suppose if you don't have anything else to do...
  - geocar 9y ago
    > Why isn't [matrix multiply] * [instead of something else] I think you added this question after I responded, or maybe I missed it. It's a good question. Because inner product (apl: +.×) is row-wise multiplication then column-wise summation. You can do a row-wise = then a column-wise > to see if the bottoms of a column end in a value (2>.=M). There's also an outer-product (apl: ∘.×) which is the left-argument currying times the right row-wise. * usually means power in APL. Not multiply. APL uses the standard × character for multiplication. APL is designed to be read, but it's still describing numerical methods and operations as opposed to a mathematical notation which frequently hides complexity. > 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. That sounds great, but I don't understand any of that or why it's valuable. Maybe that's because I don't typically read mathematical journals and type in the algorithm presented. However you gave me an idea. Take a trie as a simple data structure with a great deal of literature about it. Some googling leads me here: http://users.monash.edu/~lloyd/tildeAlgDS/Tree/Trie/ http://users.monash.edu/~lloyd/tildeAlgDS/Tree/Trie/ Now I can write "find" in k/q as @/ if I implement a 256-trie. Maybe the author doesn't know APLish languages and that's why they chose a poor notation. Maybe not. But having to decode some paper like this occurs much more frequently than even wanting to implement a bunch of type code that the compiler can optimise so I can copy and paste mathematical notation.

by geocar 9y ago

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.
- dnautics 9y ago
  >Why would you do code reviews in a language you don't understand Happens all the time. I've done it three times now at my startup. One coworker had to do cross-language code reviews at Google.
  - geocar 9y ago
    > I've done it three times now at my startup. One coworker had to do cross-language code reviews at Google [in a language they don't know]. That sounds absolutely bonkers. > I've done it three times now at my startup. How can you possibly have something to contribute? Do you also review the Chinese-localised version of your website? Seems like crazy levels of bikeshedding, but I suppose if you don't have anything else to do...
- geocar 9y ago
  > Why isn't [matrix multiply] * [instead of something else] I think you added this question after I responded, or maybe I missed it. It's a good question. Because inner product (apl: +.×) is row-wise multiplication then column-wise summation. You can do a row-wise = then a column-wise > to see if the bottoms of a column end in a value (2>.=M). There's also an outer-product (apl: ∘.×) which is the left-argument currying times the right row-wise. * usually means power in APL. Not multiply. APL uses the standard × character for multiplication. APL is designed to be read, but it's still describing numerical methods and operations as opposed to a mathematical notation which frequently hides complexity. > 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. That sounds great, but I don't understand any of that or why it's valuable. Maybe that's because I don't typically read mathematical journals and type in the algorithm presented. However you gave me an idea. Take a trie as a simple data structure with a great deal of literature about it. Some googling leads me here: http://users.monash.edu/~lloyd/tildeAlgDS/Tree/Trie/ http://users.monash.edu/~lloyd/tildeAlgDS/Tree/Trie/ Now I can write "find" in k/q as @/ if I implement a 256-trie. Maybe the author doesn't know APLish languages and that's why they chose a poor notation. Maybe not. But having to decode some paper like this occurs much more frequently than even wanting to implement a bunch of type code that the compiler can optimise so I can copy and paste mathematical notation.