Live data from Hacker News

KlongPy: High-Performance Array Programming in Python

github.com

41–50 of 90 posts

Re: KlongPy: High-Performance Array Programming in Python

#42
post #33

Earlier 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.

...and Leibniz's "windowless monads" (all three concepts are pairwise distinct, related solely by the greek prefix for 'single') predates APL and Haskell by centuries.

Re: KlongPy: High-Performance Array Programming in Python

#43
post #31

KlongPy 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?

KlongPy has a lot of other features beyond pure NumPy operations (such as IPC and web server), which you could see as a kind of making use of array operations in some application. You could look at the core Klong language as what you suggest.

Re: KlongPy: High-Performance Array Programming in Python

#44
post #30

I 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.

Have you tried following (working through) Iverson's Turing Award lecture?

https://dl.acm.org/ft_gateway.cfm?id=1283935&type=pdf

Re: KlongPy: High-Performance Array Programming in Python

#46

I’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…

There was a step-change improvement for me when I tried expressing some JS patterns via `underscore.js` instead of procedurally: eg: http://underscorejs.org/#each

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

#47
Related. Others?

KlongPy: 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

#48

I’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…

[deleted]

Re: KlongPy: High-Performance Array Programming in Python

#49

Earlier 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.

L3 cache bandwidth is often more than main memory; most systems at https://old.chipsandcheese.com/memory-bandwidth-data/ give at least a ~2x difference from whatever sample I clicked.

Re: KlongPy: High-Performance Array Programming in Python

#50

I’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…

The biggest advantage of the terse symbolic style for me comes when you wish to rapidly compare different ways (algorithms) to compute the same function. For instance, Kadane's Algorithm usually takes a dozen+ lines in an algoly language, which would normally be presented in some kind of syntax-coloured code block external to descriptive paragraphs; it takes a dozen- characters in an array language, and therefore variations can be included inline to text describing the alternatives.
Post reply on HN