Broadcasting is a great thing, but the author of this article missed the most important example of a language that handles higher order funcions, as well as broadcast and array operations as well.
That language is Julia.
The approach in the article layers an inefficient interpreter in a slow interpreted language. The result is going to be terse (and nearly unreadable) but glacially slow. Julia, otoh, is a high performance language.
An example of this performance with higher order functions is this implementation of cubic splines in 7 lines of readable code. The idea is to implement interpolation between points and functions and then define first, second and third order splines in that many lines of code. This isn't quite as terse as it would be in APL, but it has the virtue of compiling into code that runs as fast as a native C implementation.
I find such "X in Y lines of code" challenges not very interesting most of the time, because, as it is the case here, they usually just pack multiple lines into one instead of using clever tricks, from one of the lines in that file:
> right, left = lambda f: lambda x, y: list(map(lambda yi: f(x, yi), y)) if not atom(y) else f(x, y), lambda f: lambda x, y: list(map(lambda xi: f(xi, y), x)) if not atom(x) else f(x, y)
I think the challenge was actually to do something like Whitney style C in Python, doing it in under 100 lines was more a part of the metric than the goal. I am not sure I would call it a success but I don't know Python well enough to judge.
It's a fun article and this really doesn't matter much but `5{|+\x}\1,2` does not give the typical fibonacci sequence. Either `5{|+\x}\1,1` or `5{|+\x}\2,1` do, if the results from this random online interpreter can be believed (https://ngn.codeberg.page/k/#eJwzra7RjqmojTHUMQQAFyUDkw==).
Nice article. Some passages have LLM smells (short sentences. No em dash but smells of em dashes). I wonder whether this comes from having an LLM improve the English formulation/typos/etc. I don't like the way how LLMs typically write. One can steer it to certain degree with a longer prompt, that's my impression.
I still consider jax.vmap to be a little miracle: fn2 = vmap(fn, (1,2)), if i remember correctly, traverces the computation graph of fn and correctly broacasts all operations in a way that ensures that fn2 acts like fn applied in a loop across the second dimension of the first argument (but accelerated, has auto-gradients, etc).
Readit News
That language is Julia.
The approach in the article layers an inefficient interpreter in a slow interpreted language. The result is going to be terse (and nearly unreadable) but glacially slow. Julia, otoh, is a high performance language.
An example of this performance with higher order functions is this implementation of cubic splines in 7 lines of readable code. The idea is to implement interpolation between points and functions and then define first, second and third order splines in that many lines of code. This isn't quite as terse as it would be in APL, but it has the virtue of compiling into code that runs as fast as a native C implementation.
``` import Base.+, Base., Base./
+(f, g) = x -> f(x) + g(x)
(t::Number, g) = x -> t * g(x)interpolate(a, b) = t -> (1.0-t)a + tb b1(p1, p2) = interpolate(p1, p2) b2(p1, p2, p3) = interpolate(b1(p1, p2), b1(p2, p3)) b3(p1, p2, p3, p4) = interpolate(b2(p1, p2, p3), b2(p2, p3, p4)) ```
See https://discourse.julialang.org/t/seven-lines-of-julia-examp...
> right, left = lambda f: lambda x, y: list(map(lambda yi: f(x, yi), y)) if not atom(y) else f(x, y), lambda f: lambda x, y: list(map(lambda xi: f(xi, y), x)) if not atom(x) else f(x, y)
[1]: https://github.com/kparc/ksimple/tree/main/ref#ac
Deleted Comment