‘hi’

@Selisine 'Hello'

(I don’t know if string concatenation works like that in this language lol)

@Selisine x,y should work!

Cool. Hope you're enjoying the foray into APL.

You can usually get help really quickly here, so don't hesitate to ask questions.

I appreciate it!

I find it funny that this lang is taking all of what I’ve learned from programming and throwing it away–like PEMDAS and verbose variables

@Selisine Well, nothing is preventing you from using long variable names in APL. Anyway, welcome to the club. Let me know if you need any help and/or pointers to resources, communty stuff etc.

Thanks! I’ll consider it.

is there a particular reason why the wiki doesn't have pages for every glyph, and if not would it be a welcome change for me to add those?

I think it'd be useful to paste ⊆ into the search bar and be redirected to a page that lists Partition and Nest

kinda like ⊃ already has one

@RubenVerg Right shoe has a page because its meaning varies, and there's an explanation for its multiple uses. Similarly, there are pages about other glyphs that are unusual. When I enter ⊆ in the seach bar, I do get a page that lists Partition and Nest as the first results. What more would you write on a dedicated "Left shoe underbar" page?

This is oddly similar to 2021-9

0⌈(⌈/≢¨⍤⊆⍨⍥,)

⌈/0,2(>/-⍥⍸</)0,,∘0

I had {⌈/0,{(⍸2>/⍵)-⍸2</⍵}0,⍵,0}.

Which seems to be the same as @rabbitgrowth

Yes, that's the explicit equivalent.

I personally dislike using a nested dfn to avoid a temporary variable, but that inner function really lends itself to tacit.

Btw, APLcart has 0~⍨¯1-2-/∘⍸1,1,⍨~ to which you just need to prepend ⌈/0,

But instead, you can remove the 0~⍨ and just prepend ⌈/

I.e. ⌈/¯1-2-/∘⍸1,1,⍨~

@Richard Wouldn't ⍤ make more sense than ⍥ here?

@rabbitgrowth @Finn Richard's 0⌈⌈/ is more efficient than your ⌈/0, because inserting an element at the front requires re-writing the entire array in memory.

@Adám searching for … gives an unhelpful "Depth (operator)" first result, and I'm sure I had the issue before where the correct results weren't the first

@Adám because it is not about preprocessing the arguments?

@RubenVerg Ah, I see, because the Depth page uses many ellipses.

@Richard Right, only about preprocessing a single argument.

@Adám How about ⌈/0,⍨ then?

the two solutions are quite different. Any benefits using the one or the other?

@RubenVerg There are multiple APL glyphs that are not valid MediaWiki titles.

@Adám I never thought about that, good to know! Thank you!

@rabbitgrowth Better, but might still need a rewrite if there's no space to add another element (and in other contexts, there might be other vairables using the pocket).

@Richard Yours is easy to follow, but performance will suffer. Let's compare!

I see. I'll remember to use 0⌈⌈/ in the future. Thanks for the tip!

      RS←0⌈(⌈/≢¨⍤⊆⍨⍥,)
      RG←⌈/0,2(>/-⍥⍸</)0,,∘0
      RG2←0⌈2(⌈/>/-⍥⍸</)0,,∘0
      FF←{⌈/0,{(⍸2>/⍵)-⍸2</⍵}0,⍵,0}
      FF2←{0⌈⌈/{(⍸2>/⍵)-⍸2</⍵}0,⍵,0}
      AB←⌈/¯1-2-/∘⍸1,1,⍨~
      'cmpx'⎕CY'dfns'
      b←1=?1e7⍴2
      cmpx'RS b' 'RG b' 'RG2 b' 'FF b' 'FF2 b' 'AB b'
  RS b  → 2.3E¯1 |   0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  RG b  → 1.3E¯2 | -95% ⎕⎕
  RG2 b → 1.2E¯2 | -95% ⎕⎕
  FF b  → 1.4E¯2 | -95% ⎕⎕
  FF2 b → 1.2E¯2 | -95% ⎕⎕
  AB b  → 1.4E¯2 | -94% ⎕⎕⎕

:) :) :)

RS is obscuring the details.

      cmpx'RG b' 'RG2 b' 'FF b' 'FF2 b' 'AB b'
  RG b  → 1.3E¯2 |   0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  RG2 b → 1.2E¯2 |  -7% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF b  → 1.3E¯2 |   0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF2 b → 1.2E¯2 |  -7% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  AB b  → 1.5E¯2 | +12% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

So we can definitely see the benefit of 0⌈⌈/ over ⌈/0,

Let's try 0,⍨…

      cmpx'RG b' 'RG2 b' 'RG3 b' 'FF b' 'FF2 b' 'FF3 b'
  RG b  → 1.3E¯2 |  0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  RG2 b → 1.2E¯2 | -6% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  RG3 b → 1.3E¯2 | -6% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF b  → 1.3E¯2 | -1% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF2 b → 1.3E¯2 | -6% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF3 b → 1.3E¯2 | -5% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

So yes, 0,⍨ gave equal speedup here. But what happens if we break up FF3 into multiple statements?

      FF3←{⌈/0,⍨{(⍸2>/⍵)-⍸2</⍵}0,⍵,0}
      FF4←{t←{(⍸2>/⍵)-⍸2</⍵}0,⍵,0 ⋄ ⌈/t,0}
      cmpx'FF3 b' 'FF4 b'
  FF3 b → 1.2E¯2 |  0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF4 b → 1.3E¯2 | +6% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

Can you get more precise time on the result? Imagine the slight speed change from overhead locating t in symbol table

No, the need to keep the value of t while computing t,0 requires t,0 to get its own pocket (i.e. a copy) rather than updating the value in-place.

@Silas This has the exact same amount of overhead from locating a symbol:

      FF3b←{r←⌈/0,⍨{(⍸2>/⍵)-⍸2</⍵}0,⍵,0 ⋄ r}
      cmpx'FF3 b' 'FF4 b' 'FF3b b'
  FF3 b  → 1.2E¯2 |  0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF4 b  → 1.3E¯2 | +7% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF3b b → 1.2E¯2 |  0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

ah, true - was thinking the ⍵ would have multiple references for some reason.

Can someone explain why AB is significantly slower?

Oh, wait, I think I can speed it up.

which one is AB?

AB←⌈/¯1-2-/∘⍸1,1,⍨~

Nah, my idea just made it worse :-(

no, no clue.

because of the confused face? ⍨

They all seem to do the same more or less

I believe it is ~ that's slow.

AB is faster on my machine.

Ooh:

      RG←⌈/0,2(>/-⍥⍸</)0,,∘0
      AB←⌈/¯1-2-/∘⍸1,1,⍨~
      b←1=?1e7⍴2
      cmpx'RG b' 'AB b'
  RG b → 1.4E¯2 |   0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  AB b → 8.4E¯3 | -39% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

      AB2←{¯1-⌊/2-/⍸1,1,⍨~⍵}
      cmpx'AB b' 'AB2 b'
  AB b  → 1.5E¯2 |   0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  AB2 b → 1.2E¯2 | -15% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

maybe because of the test data which is different every time

OK, now I got the same performance as @rabbitgrowth and @Finn:

      cmpx'RG b' 'RG2 b' 'FF b' 'FF2 b' 'AB b' 'AB2 b'
  RG b  → 1.3E¯2 |   0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  RG2 b → 1.3E¯2 |  -6% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF b  → 1.4E¯2 |  +1% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  FF2 b → 1.3E¯2 |  -6% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  AB b  → 1.5E¯2 | +12% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  AB2 b → 1.3E¯2 |  -6% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

@Adám could you explain the change between AB and AB2 ?

It looks like AB should be faster because it's doing half the amount of windowed-reducing and ⍸-ing.

@Silas Yes, AB does a ¯1- on all the values, before reducing, while AB2 does that after the reduction.

@rabbitgrowth Right, that's what I thought.

ah, so scalar vs vector operation - thanks

      RG←⌈/0,2(>/-⍥⍸</)0,,∘0
      AB←⌈/¯1-2-/∘⍸1,1,⍨~
      b←1=?1e7⍴2
      cmpx'RG b' 'AB b'
  RG b → 1.3E¯2 |   0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  AB b → 8.3E¯3 | -39% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
      b←1=?1e7⍴2
      cmpx'RG b' 'AB b'
  RG b → 1.4E¯2 |  0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  AB b → 1.4E¯2 | +5% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕

That's weird

Yeah, the fewer runs of 1s there are, the better AB will perform.

Anyway, I think we can take home the lessons of measuring performance, and keeping in mind to reduce first — before adjustments like 0, (which becomes 0⌈) or ¯1-.

Will keep that in mind!

@Richard Ooh, good point!

See you next week for 2022-5: Stairway to Heaven.

Btw, I think 0⌈⌈/(⊢×+)\ would work if scan used left-to-right folds.

thanks all!

@rabbitgrowth You need double backticks to avoid \ escaping the closing backtick.

Fixed, thanks!

Thanks all, that was very interesting!

@Adám Nice presentation from John D! Is the demo version being shared again like previous year?

and a nice proposal for ⌸ :)