[klibertp]

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's version:

       1 2 3 * 10
    10 20 30

Plus, in J it generalizes to higher dimensional arrays:

       i. 3 3
    0 1 2
    3 4 5
    6 7 8
       (1 + i. 3 3) * 10
    10 20 30
    40 50 60
    70 80 90

[slver]

My example is verbose in order to clearly communicate the principle. I can trivially shorten it to

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

if I wanted to literally carry out that task alone.

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

[klibertp]

I think this is pseudo-code? `flatMap` and `=>` for lambdas look like Scala, but there are no array literals using `[]` there. Assuming you mean Scala-like semantics, your second example wouldn't work at all:

    scala> Array(Array(1,2),
                 Array(4,5)).flatMap(a => a * 10)
                                                       ^
           error: value * is not a member of Array[Int]

You would need to write it like this:

    scala> Array(Array(1,2),
                 Array(4,5)).flatMap(a => a.map(x => x * 10))

But then you'd get a flattened array of ints, not array of arrays of ints:

    res6: Array[Int] = Array(10, 20, 40, 50)

So to get the same result as

    (i. 2 2) * 10

You'd need to write:

    scala> Array(Array(1,2),
                 Array(4,5)).map(a => a.map(x => x * 10))
    res7: Array[Array[Int]] = Array(Array(10, 20), Array(40, 50))

...which is more verbose, no? :) EDIT: obviously, I mean "map in map" part, not the Array initialization!

The problem with list comprehensions and `map`, `filter` and friends is that they work very well for flat lists, or lists of lists in some specific circumstances (ie. when you can use `flatMap`). 2D arrays in the general case, and arrays with higher dimensions are really hard to work with using these primitives, unless you have some clever overloads, like what Clojure does. I think Haskell also has a solution for this, but I don't know it enough to comment further, unfortunately :)

[slver]

What I can't understand is what would J do if I tell it to sum these two arrays:

    1 2 3 4 5
    6 7 8 

I.e. 5 elements and 3 elements

[rklmno]

Like was mentioned, the simplest behavior is treat this as an error case.

Other possibilities include:

(*) extending the length of the short array to match the length of the long array -- padding with zeros on the right -- before adding.

(*) finding all possible sums between pairs with one number from one array and the other number from the other array.

(*) cyclically extending the shorter array (probably not useful in this example, but since the example didn't come with a use case that's difficult to know for sure).

(*) Treating each array as a decimal number (or a number in some other base)

(*) combining the two array as a single list of numbers and summing everything to a single value

and... so on...

One point being that programming languages support arbitrarily complex operations.

Another point being that "sum" in this context carries some understandable ambiguity -- the sort of thing which we usually try to constrain with use cases or examples or similar elaboration.

[klibertp]

       1 2 3 + 4 5 6 7
    |length error
    |   1 2 3    +4 5 6 7

In general - depends on the operation. Sometimes the verb checks that both operands have the same rank and dimensions, sometimes the shorter/smaller side gets applied column-wise (or cell-wise/page-wise):

       (2 2 $ 1 2 3 4)  NB. $ means "reshape"
    1 2
    3 4
       (2 2 $ 1 2 3 4) + 1 2
    2 3
    5 6

Sometimes the shorter side is repeated as much as needed to get the correct length, and sometimes the shorter side gets extended with 0s, and sometimes the longer side gets truncated:

       (2 2 $ 1 2 3 4 5 6)
    1 2
    3 4
       (2 4 $ 1 2 3 4 5 6)
    1 2 3 4
    5 6 1 2
 

To be perfectly honest: it's very unintuitive to me and I have to check the docs pretty often to see how the given verb behaves outside of the simplest case (ie. when the rank and dimensions match). But, I learned J as a hobby and never invested enough time into it to really learn all the built-ins, nor did I try using J outside of toy examples, so maybe this behavior becomes convenient once you internalized it?

EDIT: forgot to mention, you can also control the effective rank of the verb, like this:

       <"0 (2 2 $ 1 2 3 4)
    ┌─┬─┐
    │1│2│
    ├─┼─┤
    │3│4│
    └─┴─┘
       <"1 (2 2 $ 1 2 3 4)
    ┌───┬───┐
    │1 2│3 4│
    └───┴───┘
       <"2 (2 2 $ 1 2 3 4)
    ┌───┐
    │1 2│
    │3 4│
    └───┘

the `<` verb means "box", without the `"n` part you'd get the last value, which is a 1-dimensional array of boxes of length 1 (with 2x2 array inside the box). By selecting rank of the verb, you can decide on which level the verb should be applied: with `"0` it's applied to the smallest possible chunks of the array (cells - you get 2x2 array of boxes), with `"1` you apply the verb to bigger chunks (rows), and so on, for input arrays of any dimensions (so if you have a 3x2x2 array, `"2` will apply the verb to the 3 2x2 arrays).

[dzaima]

I don't think $ is of worthy note here. It's literally a builtin for cycling data, that's what it does.

All simple arithmetic follows leading axis agreement[1] (so erroring on mismatched length, and mapping over cells for high rank). Don't know much about other builtins, but, unless J does some weird stuff I don't know about (I don't know much of J), it shouldn't be too illogical.

[1] https://aplwiki.com/wiki/Leading_axis_agreement

[klibertp]

> I don't think $

You're right, although cycling instead of erroring out was surprising to me. Another verb I had trouble with is roll/deal: https://code.jsoftware.com/wiki/Vocabulary/query

> it shouldn't be too illogical.

I'm not saying it's illogical. I'm pretty sure there are good reasons behind the design of each word, especially since there are so few. As I mentioned, I suspect it's just a matter of me not getting enough exposure to the various use-cases of many standard words.

[slver]

Gotta say, "depends on the operation" was the most unfortunate possible answer to my question, alas :-) Maybe one day we'll figure out how to make a consistent array language ;-)

[thrwaeasddsaf]

Why is it unfortunate? It's entirely plausible that they've managed to pick the behavior that makes most sense for each operator. Different operators being different, it doesn't make sense to expect all to behave the same. And it would be unfortunate if the common use cases were complicated by having to code out the sensible behavior if the defaults were wrong.

[klibertp]

Well, for what it's worth - and as mentioned by a sibling poster - most verbs, and certainly all arithmetic operators, obey a few simple rules for determining which behavior you'll get. I should have noted this, before I started whining about all the other verbs, which don't :D

[ithkuil]

Give this a try: https://t3x.org/klong/klong-ref.txt.html

[rscho]

even less verbose:

(>: i. 3 3) * 10

[rscho]

...or

10 * >: i. 3 3

FWIW