KlongPy author here: AMA
KlongPy: High-Performance Array Programming in Python
41–50 of 90 posts
Re: KlongPy: High-Performance Array Programming in Python
#42Earlier quoted context omitted.
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
#43KlongPy author here: AMA
Would it make sense to think of this as a compact syntax for numpy? When it comes to array operations, are there differences that go deeper than the syntax?
Re: KlongPy: High-Performance Array Programming in Python
#44I 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.
Re: KlongPy: High-Performance Array Programming in Python
#45Re: KlongPy: High-Performance Array Programming in Python
#46I’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…
Thinking of something as `each | map | filter | sum` is waaay less buggy than writing bespoke procedural code to do the same thing. No doubt there is a "cost" to it as well, but the _abstraction_ is valuable.
Now, if there were a "compiler" which could optimize that whole pipeline down and squeeze out the inefficiencies between steps because it could "see" the whole program at the same time. (oh, I don't know, something like `SELECT * FROM foo WHERE a > 100 AND b ...perhaps you could get both an expressivity gain (by using higher level concepts than "for" and "while"), a reduction in bugs (because you're not re-implementing basic work-a-day procedures), and an improvement in efficiency (because the "compiler" can let you express things "verbosely", while it sorts out the details of efficiency gains that would be tenuous to express and keep up to date by hand).
Re: KlongPy: High-Performance Array Programming in Python
#47KlongPy: Vectorized port of Klong array language - https://news.ycombinator.com/item?id=35400742 - April 2023 (8 comments)
Klong: a Simple Array Language - https://news.ycombinator.com/item?id=21854793 - Dec 2019 (73 comments)
Statistics with the array language Klong - https://news.ycombinator.com/item?id=15579024 - Oct 2017 (12 comments)
Klong – a simple array language - https://news.ycombinator.com/item?id=10586872 - Nov 2015 (21 comments)
Re: KlongPy: High-Performance Array Programming in Python
#48I’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…
Re: KlongPy: High-Performance Array Programming in Python
#49Earlier quoted context omitted.
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.
Re: KlongPy: High-Performance Array Programming in Python
#50I’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…