3 ms·
I have been toying with J for the past few years, and I think you only appreciate it when you see it as equivalent to mathematical notation, alien at first, but
by eggy 12y ago
I have been toying with J for the past few years, and I think you only appreciate it when you see it as equivalent to mathematical notation, alien at first, but succinct and very useable when you know what the symbols mean. See Iverson's paper on 'Notation as a Tool of Thought' (http://www.jsoftware.com/papers/tot.htm http://www.jsoftware.com/papers/tot.htm). I am self-teaching mathematics, and even when trying Julia as a math tool, I find the basic unit of J, the array, as more amenable to my studies. It's interesting how there is all the talk about 'vectorization' and such in other languages, which J has been doing for decades. J is functional, and can have 'for' loops, but loopless programming is encouraged and easy. When dealing with images or large data sets that are memory mapped, the operations are succinct and powerful and eye-opening.
My latest epiphany from moving away from using J as just a sophisticated calculator came after watching the 4 videos by Martin Saurer (https://www.youtube.com/watch?v=VSJpJt3c11c https://www.youtube.com/watch?v=VSJpJt3c11c). Iverson's books on arithmetic and calculus using J are mind-blowing. You are engaged, not distracted by the language. J is fast too. From another talk (https://www.youtube.com/watch?v=IKfJRyoiBlY&feature=youtu.be https://www.youtube.com/watch?v=IKfJRyoiBlY&feature=youtu.be), creating a 1x10^6 element array and summing over columns or rows is fast, and the code is simply:
b=: ? 1000 1000 $ 10
+/+/b
These two lines create a 1x10^6 element array and then sums the columns, and then sums the single row total. Fast. These guys have really distilled the libraries and made them work well with J (lapacke c interface to lapack). You get c speeds from an interpreter. I guess this is why q with kdb+ is used so much by the finance community despite how expensive it is.
Anyway, I am currently staying with J, and I am writing my little tasks in J and julia to see how they fare against each other in speed and development efforts. Now that I have the knowledge to do Qt interfaces for J, I may just stick with J for the sheer joy.
- oddthink 12y agoIMHO, q's (and K's) big advantage over J is that they have tables and dictionaries as an available data type. This makes basic tasks like reading csv files and merging different data sources much easier in q. q also has a nicer syntax for anonymous functions. Of course, q is also very expensive, and it tries to be too clever at times: I remember running in to all sorts of weird corner cases, with things like NAs being skipped in float arrays, but not in int arrays, etc.
- papercrane 12y ago> q is also very expensive You're probably aware since it's not a big community, but the 32-bit version of kdb+ is available for free now for any purpose. The 64-bit version still cost an arm and a leg, and I'm sure they're relying on most use cases for the language requiring more then what you can fit into 32-bit address space.
- oddthink 12y agoI knew of it, yes, but thanks for mentioning it in this thread, since I don't know how well-known it is. For my purposes, kx got it entirely right: I can barely scratch my own nose with <2 GB of data. :)