The Array Cast – A podcast about the array programming languages

Post by slver » Thu, May 20, 2021, 1:12 PM UTC

klibertp wrote: post #33

slver wrote: post #30

Earlier quoted context omitted.

It seems almost as if it'd be more useful to not explicitly expose operators as applicable to arrays, but implement SIMD optimization for operator expressions in .map(function) and something like .binaryMap(right, function) ex. [1, 2, 3].binaryMap([10, 10, 10], (a, b) => a * b) // Produces [10, 20, 30] This would be easier to optimize when compiled because the expressions can be simplified and mapped to the right SIM…

Unfortunately, I have no idea about the implementation and what optimizations are done in J or APL for which operations :( I know that there are hardcoded "fast path" expressions (particular combinations of operations) which have much better performance than more general expressions doing the same thing, so it might be that the optimization happens at that level. OTOH, your example is very verbose when compared to J'…

    [1, 2, 3].map(a => a * 10)
    

    [[0, 1, 2],
     [3, 4, 5],
     [6, 7, 8]].flatMap(a => a * 10)

Post by rscho » Thu, May 20, 2021, 1:17 PM UTC

klibertp wrote: post #40

slver wrote: post #37

Earlier quoted context omitted.

Most compilers can inline statically defined closures in these contexts. And tracing JITs do this even when the closure is not define statically (but is stable). It's more about allowing the SIMD goodness without the ambiguity and restrictions of "scalar operators work on arrays" implemented naively.

> without the ambiguity There's no ambiguity! In J, all (with some exceptions) operations work on arrays, period. `1 + 1` is not an addition of two scalars, but instead of two arrays of length 1. As I mentioned, you can have scalars, but a) they still live in arrays and b) you can't do anything with them without unboxing. So there's no ambiguity, as far as I can tell. Also, APL and J are implemented as intepreters, b…

Post by jiggawatts » Thu, May 20, 2021, 1:32 PM UTC

rscho wrote: post #42

jiggawatts wrote: post #38

Earlier quoted context omitted.

What the actual f? It's like someone threw up the noise that modems make during initial connection onto an electric typewriter from the 1960s, and then explained their intention using quotes from a Lovecraft novel.

it's extremely readable when used to it, though. I use J for exploratory data analysis. It's really, really good at that kind of thing.

Post by userbinator » Thu, May 20, 2021, 1:43 PM UTC

jiggawatts wrote: post #38

bidirectional wrote: post #24

Earlier quoted context omitted.

k (and the closely related q) is the main language used in industry, particularly at investment banks and hedge funds. It can be a bit of a shock to realise there are people in London earning in excess of £1000/day (pretty good for London) working in a language where well-written code looks like this[1]: us:{$[#i:&{(y~*K)&"*"~\*x}':x;@[x;i;:[;,"_"]];x]} It's like discovering a whole different world of software develo…

What the actual f? It's like someone threw up the noise that modems make during initial connection onto an electric typewriter from the 1960s, and then explained their intention using quotes from a Lovecraft novel.

Post by dzaima » Thu, May 20, 2021, 1:58 PM UTC

rscho wrote: post #43

klibertp wrote: post #40

Earlier quoted context omitted.

> without the ambiguity There's no ambiguity! In J, all (with some exceptions) operations work on arrays, period. `1 + 1` is not an addition of two scalars, but instead of two arrays of length 1. As I mentioned, you can have scalars, but a) they still live in arrays and b) you can't do anything with them without unboxing. So there's no ambiguity, as far as I can tell. Also, APL and J are implemented as intepreters, b…

> `1 + 1` is not an addition of two scalars, but instead of two arrays of length 1 I think that's true of (Dyalog) APL, but not of J [1]. APL follows the nested array model (that you describe), while J follows the flat array model that does have true scalars. [1] https://aplwiki.com/wiki/Array_model#Flat_array_theory