Iverson bracket notation is named after him: https://en.wikipedia.org/wiki/Iverson_bracket
The Notation: Ken Iverson Centenary
21–30 of 32 posts
Re: The Notation: Ken Iverson Centenary
#22How does using APL/J/K compare to using Julia, Numpy or Matlab? The fact that in the latter you still have the safety blanket of procedural programming makes it seem easier to learn and more productive.
Re: The Notation: Ken Iverson Centenary
#23How does using APL/J/K compare to using Julia, Numpy or Matlab? The fact that in the latter you still have the safety blanket of procedural programming makes it seem easier to learn and more productive.
Control flow in APLs is mostly imperative, and with explicit code, /i.e./ code that mentions variables, you're effectively writing procedural code. I'd say that APLs are harder to get started with, but easier to use right. With things such as Numpy, you need to know lots of things about the API that might change without warning. With APL, you learn the primitives and you're off to the races. The downside is that less popularity means far fewer library efforts.
Re: The Notation: Ken Iverson Centenary
#24Earlier quoted context omitted.
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 hal…
How has your experience been with J for on disk time series DBs.
Not developer, just a lone data wrangler but FWIW Jd has made me much faster at exploring data. I now use Jd to create my datasets and use R just for the models. IMO, it's far better than using R to tidy things.
Re: The Notation: Ken Iverson Centenary
#25> " 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…
It's also easier to do scripting with J since you can just use files. The (Dyalog) APL workspace infrastructure is very powerful but a bit heavy to use when all you want is a simple script. Of course, large banks and Fortune 500 companies seldom use just simple scripts, so that makes sense I guess.
Re: The Notation: Ken Iverson Centenary
#26> Glory days. Long before spreadsheets, IBM managers wrote their budgets in APL, and lucrative timesharing services supported users around the world.
Imagine a world where spreadsheets grew from being a living, easily accessible version of everything APL offered (which has been true for about two decades) into everything Q (and kdb+) supports including serving web content and cross-platform database queries.
Re: The Notation: Ken Iverson Centenary
#27> ”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…
I think you're missing the point. K certainly isn't faster than C. If you have a C guru, they should always be able to write faster code than K. The difference is it should be a lot easier for someone like me (not a C guru) to write a K program that does something useful. I'll also be able to see the whole program as it will likely be a few lines long. If I wrote some C code, it would take me forever and take forever…
Absolutely. The advantage is terseness of expression.
Less code means fewer bugs.
Re: The Notation: Ken Iverson Centenary
#28I found J in 2011 or early 2012. I fell in love with it due to the terse, expressive notation set against pages of typical programming code from other languages. I have since moved to Dyalog APL. Roger Hui of APL/J fame, now contributes to Dyalog APL, so a lot of the novel ideas in J have made their way back into APL (Dyalog and NARS).
I read my first book on neural networks in 1988, and I got the matrix math and the implementation of them, but this year I was able to really grasp them in a more basic way with an implementation of Convolutional Neural Network in APL in only 10 functions/lines of code [1]. Amazing! What's even more surprising is that they manually translated it to SAC (Single Assignment C), and it is faster than TensorFlow. The interpreter is not bad either - 20x less time to init than TF, but 20x and 5x slower to train and test respectively. Compilers for APL are being worked on to make it work without the manual translation. To me the similarity to the math formulas, being able to view and work through the code in front of me in one view, is priceless. I also enjoy it, and I believe (no evidence here) that it is exercising my mind on the problem more directly than winding my mind around pages of Python/C or other PLs. Certainly a lot of the original ideas of APL and current successes of things like Pandas and NumPy owe a lot to the array languages in the APL family.
There's an example of an Extreme Learning Machine in J, but I don't have the link at the moment. I go back and forth with J and APL, and I am currently learning Rust. Somebody coded APL in Rust, but it has not been fleshed out. I find myself attacking problems in J/APL on my desktop, and sometimes that's it, I don't require another solution, or if I do I recreate it in C/Python or now Rust.
Aaron Hsu does amazing work in APL. He is/was a former Schemer [2].
A taste of J or APL with an average function implementation:
J: avg=: +/%#
APL: avg←+/÷≢
They both map/apply the '+' operator over a vector/array, then divide the sum by the tally or count of terms given.
Great tribute to Ken Iverson!
10 line CNN implemented in APL (the stencil operator ⌺is great! It allows you to move a window over your array):
blog←{⍺×⍵×1-⍵}
backbias←{+/,⍵}
logistic←{÷1+-⍵}
maxpos←{(,⍵)⍳⌈/,⍵}
backavgpool←{2⌿2/⍵÷4}⍤2
meansqerr←{÷∘2+/,(⍺-⍵)2}
avgpool←{÷∘4{+/,⍵}⌺(22⍴2)⍤2⊢⍵}
conv←{s←1+(⍴⍵)-⍴⍺⋄⊃+/,⍺×(⍳⍴⍺){s↑⍺↓⍵} ̈⊂⍵}
backin←{(dwin)←⍵⋄⊃+/,w{(⍴in)↑(-⍵+⍴d)↑⍺×d} ̈⍳⍴w}
multiconv←{(awsbs)←⍵⋄bs{⍺+⍵conva}⍤(0,(⍴⍴a))⊢ws}
[1] https://dl.acm.org/doi/10.1145/3315454.3329960 (PDF link is on page)
Re: The Notation: Ken Iverson Centenary
#29How does using APL/J/K compare to using Julia, Numpy or Matlab? The fact that in the latter you still have the safety blanket of procedural programming makes it seem easier to learn and more productive.
Dyalog APL has a safety blanket of procedural programming[1], it's another strange aspect of APL and the internet that it seems almost completely overlooked - unremarked upon and never discussed. e.g. this is roughly a prompt-for-username and validate-username code:
∇result←verifyUserName userName
isValid←1
message←''
:If (userName≡'')∨(8It has an OOP/Class system as well, but that doesn't save you from having to know APL either.
[1] I don't think NARS2000 does, and I'm not sure about the bigger IBM / Sharp APLs. I don't think J or K have.
Re: The Notation: Ken Iverson Centenary
#30> ”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 hal…
> 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
That's 6 of the programs, there were at-least 4 others ;-)
I lacked and still lack the knowledge to figure out if those snippets are doing what they should.
For example, do those scripts set arg n from the command line and read from stdin? Do those scripts write correctly formatted output to stdout?
What a pity that page does not show measurements for those scripts, and a comparison with some of the C programs written for the benchmarks game.