KlongPy author here: AMA
KlongPy: High-Performance Array Programming in Python
31–40 of 90 posts
Re: KlongPy: High-Performance Array Programming in Python
#32I'm gonna be the one who asks the dumb question, but someone has to do it: why are expressions evaluated from right to left?
Because that's what APL does: https://www.jsoftware.com/papers/EvalOrder.htm
It also simplifies things as no need to implement BIDMAS
Re: KlongPy: High-Performance Array Programming in Python
#33Earlier quoted context omitted.
No. In APL deriverd array programming languages, verbs (or functions) are monadic or dyadic : they accept only one or two arguments : In '1 + 1', + is a dyadic operator, while in 'exp 5', exp is monadic. In J, and in APL I guess, left arg is usually understood as 'control data', while right arg is the data upon which calculation is done. Left argument is usually left unchanged after calculations. In this way, is it p…
It sounds unrelated to the monads popularized by Haskell tutorials. Naming coincidence or am I missing something?
APL's use of 'monad' predates Haskell's existence by decades.
Re: KlongPy: High-Performance Array Programming in Python
#34What are some real-world practical applications of array programming? Because as far as I know, APL did not catch on, and its subsequent versions like J and K and BNQ also did not become useful in industry. Maybe there's something I'm missing. Why would you want to do array programming in Python? What are the advantages over regular Python programming?
Array programming databases (eg: KDB+, Shakti) are (per their own metrics) way faster than the competition. Licensing fees are in the 6 digits, so I'm not comparing them personally, but people pay that exorbitant amount, and I assume they do so for a reason.
Re: KlongPy: High-Performance Array Programming in Python
#35What are some real-world practical applications of array programming? Because as far as I know, APL did not catch on, and its subsequent versions like J and K and BNQ also did not become useful in industry. Maybe there's something I'm missing. Why would you want to do array programming in Python? What are the advantages over regular Python programming?
The array languages aren't super popular because of the sharp learning curve. They're a lot different than most other languages, and they have a lot of operators that simply don't exist in something like C++.
A few years ago there was an article about K's use in high-frequency trading. I'm not sure about usage of APL and J, though. BQN is still fairly new, so it will take a while to see much production usage.
If you've ever written code using NumPy, Tensorflow, or PyTorch, you're doing array programming. Those libraries are heavily influenced by the array languages, including taking a lot of terminology (rank, etc.). I've personally found that playing with J and BQN helped me understand Tensorflow, and vice versa.
Re: KlongPy: High-Performance Array Programming in Python
#36I would love something like duolingo, but for an array language. Not a steady series of challenging puzzles like leetcode sites, Rather, a series of questions with high repetition, somewhat like flash cards, easy to drop into for a few minutes.
[deleted]
Re: KlongPy: High-Performance Array Programming in Python
#37I gather where it says `:monad` it is referring to an operation that had an effect on the interpreter state?
No. In APL deriverd array programming languages, verbs (or functions) are monadic or dyadic : they accept only one or two arguments : In '1 + 1', + is a dyadic operator, while in 'exp 5', exp is monadic. In J, and in APL I guess, left arg is usually understood as 'control data', while right arg is the data upon which calculation is done. Left argument is usually left unchanged after calculations. In this way, is it p…
Thanks kindly.
Re: KlongPy: High-Performance Array Programming in Python
#38Earlier quoted context omitted.
No. In APL deriverd array programming languages, verbs (or functions) are monadic or dyadic : they accept only one or two arguments : In '1 + 1', + is a dyadic operator, while in 'exp 5', exp is monadic. In J, and in APL I guess, left arg is usually understood as 'control data', while right arg is the data upon which calculation is done. Left argument is usually left unchanged after calculations. In this way, is it p…
It sounds unrelated to the monads popularized by Haskell tutorials. Naming coincidence or am I missing something?
A `monad` in Category Theory (which is where Haskell gets them from, ultimately) is a single-argument functor and two natural transformations, so there probably is a through-line here in terms of one-argument function-likes.
Re: KlongPy: High-Performance Array Programming in Python
#39I’ve tried several times to give J/k/Q/kdb a chance but I haven’t really found a convincing example why this approach is better than say SQL or say numpy/jax etc.
The syntax has the same problem as perl in that you have to learn too many symbols that are hard to look up. And this combined with the tacit style makes it difficult to parse what the code is doing.
I think ruby went in the radically opposite direction in that it provides a similar feature set to perl with similar functional features but everything is human readable text. I feel like there’s room for a human readable version of J that relies less on syntactical sugar.
I do think the direction Klong has gone with the syntax is an improvement: https://t3x.org/klong/ambiguity.html
I’m curious if anyone has a go-to article/example of why an array language would be a good choice for a particular problem over other languages?
I know the second chapter of J for C programmers is kinda like that but I didn’t really find it convincing: https://www.jsoftware.com/help/jforc/culture_shock.htm#_Toc1...
Re: KlongPy: High-Performance Array Programming in Python
#40Earlier quoted context omitted.
You are absolutely right, naive array programming might be much faster than raw python but it will never be high performance because you can't use caches and memory bandwidth effectively.
The unstated major premise here is that you're working with data that's big enough that this becomes your major bottleneck. There's also a subset - possibly even a silent majority - of problems where you're doing fairly intensive calculation on data that fairly comfortably fits into a modern CPU cache. For those, I'd still expect SIMD to be a great choice from a performance perspective.
I'm not exactly sure what this means, but the bandwidth to the level 3 cache isn't actually more than memory. If you only have a few megabytes to work with, it's a lot less likely performance is going to matter anyway, and if it does you would still want to do multiple operations on each array item if possible, because if you put a few more lines in a loop you're talking about registers at that point, not cache.