The Notation: Ken Iverson Centenary
1–10 of 32 posts
Re: The Notation: Ken Iverson Centenary
#2Very interesting article.
Re: The Notation: Ken Iverson Centenary
#3> "Iverson was more interested in how quickly a person could understand an algorithm"
Has there been any study of whether J is quicker or slower than APL for this? Subjectively, APL is pretty and enticing in a way that J isn't.
It's very strange to me that someone who promoted Iverson Notation as a better math notation, and wrote Notation as a Tool of Thought, could apparently completely switch notation from 30 years of established APL symbols to pairs of ASCII symbols, effectively overnight, and carry on as if nothing was any different.
How much of J's success is because J was free and the big APLs were a lot of money, so J has been "the free way to get an array language experience" for years?
Re: The Notation: Ken Iverson Centenary
#4> ”K programs routinely outperform hand-coded C. This is theoretically impossible. K compiles into C. Every k program has a C equivalent that runs exactly as fast. Yet it is true in practice. Why? Because it is easier to see your error in four lines of code than in four hundred lines of C.”
How true is this? I hear this claim a lot but haven't seen any real benchmarks. E.g, https://benchmarksgame-team.pages.debian.net/benchmarksgame/... doesn't have K or any related languages.
I'm guessing K is fast due to autovectorization for certain cases, but are there benchmarks that provide hard numbers? The existence of a benchmark prohibition clause in the kdb license makes me skeptical of its performance claims.
https://tech.marksblogg.com/benchmarks.html has a kdb benchmark, but due to the use of Xeon Phis, it can't be compared with other benchmarks there.
Re: The Notation: Ken Iverson Centenary
#5> ”K programs routinely outperform hand-coded C. This is theoretically impossible. K compiles into C. Every k program has a C equivalent that runs exactly as fast. Yet it is true in practice. Why? Because it is easier to see your error in four lines of code than in four hundred lines of C.” How true is this? I hear this claim a lot but haven't seen any real benchmarks. E.g, https://benchmarksgame-team.pages.debian.ne…
There are lies, there are damn lies, and there are benchmarks.
Also, consider how few comments there are in this thread. What does that usually mean on HN?
Re: The Notation: Ken Iverson Centenary
#6> ”K programs routinely outperform hand-coded C. This is theoretically impossible. K compiles into C. Every k program has a C equivalent that runs exactly as fast. Yet it is true in practice. Why? Because it is easier to see your error in four lines of code than in four hundred lines of C.” How true is this? I hear this claim a lot but haven't seen any real benchmarks. E.g, https://benchmarksgame-team.pages.debian.ne…
Arthur's new company, Shakti, has some of the benchmarks they've talked about[1][2].
[2] https://shakti.sh/benchmark/about?eula=shakti.com/license
Re: The Notation: Ken Iverson Centenary
#7> ”K programs routinely outperform hand-coded C. This is theoretically impossible. K compiles into C. Every k program has a C equivalent that runs exactly as fast. Yet it is true in practice. Why? Because it is easier to see your error in four lines of code than in four hundred lines of C.” How true is this? I hear this claim a lot but haven't seen any real benchmarks. E.g, https://benchmarksgame-team.pages.debian.ne…
My guess is that K is faster in some situations because the nature of the language requires programmers to use the most direct solution to a problem, getting all the code and data in the cache. C being a verbose language makes this harder to achieve, unless you spend some time to optimize the memory layout of your data.
Re: The Notation: Ken Iverson Centenary
#8> ”K programs routinely outperform hand-coded C. This is theoretically impossible. K compiles into C. Every k program has a C equivalent that runs exactly as fast. Yet it is true in practice. Why? Because it is easier to see your error in four lines of code than in four hundred lines of C.” How true is this? I hear this claim a lot but haven't seen any real benchmarks. E.g, https://benchmarksgame-team.pages.debian.ne…
He wrote solutions for Shootout (predecessor to that Debian page) problems a few years ago; a lack of k in benchmarks is not due to a lack of k being volunteered: http://www.kparc.com/z/comp.k
k is really fast. Half of the things on the Shakti mailing list are just Arthur getting really excited about how significantly he's beating x or y or z in performance and giving numbers for it. `grep`ping it now I see 40 in half a year that explicitly contain the word "benchmark," though not all of these are comparing to other things (some are just comparing to different k releases), and there are more comparisons without that word.
Arthur doesn't work at Kx anymore, by the way. He's at Shakti now. Shakti has a different (but still draconian/non-(A)GPL) license. It probably doesn't have the benchmark clause, but I don't care enough to check (I prefer J to k and don't have a proprietary k on my system).
Re: The Notation: Ken Iverson Centenary
#9> ”K programs routinely outperform hand-coded C. This is theoretically impossible. K compiles into C. Every k program has a C equivalent that runs exactly as fast. Yet it is true in practice. Why? Because it is easier to see your error in four lines of code than in four hundred lines of C.” How true is this? I hear this claim a lot but haven't seen any real benchmarks. E.g, https://benchmarksgame-team.pages.debian.ne…
What would be interesting, and perhaps informative, if is we could share our some of our favorite k programs and then people could try to write faster implementations in C.
I like benchmarks that I can easily run on any computer myself.
For me, a major part of k's appeal is the (original) author's appreciation for small interpeter size and language terseness. Generally, I think k will always beat C, and probably any scripting language you can think of, in that department.
The issue of verbosity is so polarising amongst the vocal programmers who comment online that even if k were faster than whatever language (and free, open source, etc.), I would bet many of them still would reject the idea of using it.
Re: The Notation: Ken Iverson Centenary
#10> " Iverson was more interested in how quickly a person could understand an algorithm " Has there been any study of whether J is quicker or slower than APL for this? Subjectively, APL is pretty and enticing in a way that J isn't. It's very strange to me that someone who promoted Iverson Notation as a better math notation, and wrote Notation as a Tool of Thought, could apparently completely switch notation from 30 yea…
I think the notation is not the only difference in J. I believe that tacit programming is one of the improvements proposed by J, but I might be wrong.