Is there a way to get the identity of a function? say the identity of + is 0 and for × it is 0

@LdBeth You mean 1 for ×, no?

1 for ×

f/⍬ ― I'll add it to APLcart.

ah, so ⌈/⍬is -inf

thanks

Yes, or rather the smallest representable number.

maybe also add {¯1↓⍺⍺\(⍺⍺/⍬),⍵} as "traditional scan"

Ah, so that's like shifted one step; begin with the identity element and never quite reach f/

Exclusive scan

It's the scan operation defined by FFP Machine

Heh, hardly "traditional" when it came decades after APL…

ah, so I alway forget APL was the language of 60's

@LdBeth OK, added both. Thanks!

Meh, is it just me or has tryapl.org gotten very slow

Feels like it randomly just stops responding and requires a refresh

Seems fine to me.

It's erratic

@goof it can get slower if you have some large variables in the workspace, since it's sending those forward & back on every evaluated expression

Well I just cleared my workspace to see if that helps. After recreating the stuff I was working on, it again froze on ⍴a with a workspace size under 60 kB

(That's my largest array, 504 504)

Maybe my internet is just crap

in my little bits of testing, with a←⍳¯600+512000÷4 around it still works (each evaluation takes ~1s, but always finishes)

@Adám will scripting support be in 18.1?

Not giving me much hope here! 'important components that are glaringly missing' not sure how you could miss things if they are really important

I'm just trying to manage expectations.

Fair enough...

@Adám i mean, all you need is a way to execute a file from the commandline, or from a shebang. (and the file should of course allow tradfns and multiline dfns, and not implicitly output the result of everything evaluated)

@dzaima But you also want access command line args, files in the dir the script was run from, running other scripts from this script, …

@Adám all of which seem like pretty basic features...

@Adám right, was about to mention executing other files from a script file. Commandline flags are quite less important, but of course still should be there

side note: ⎕ARGV would be much nicer than 2⎕NQ#'GetCommandLineArgs'

(fwiw, BQN provides •args, •path, and •name with the obvious values, and •Import/•FChars/•FBytes/•FLines read/write/execute relative to the file location (•Import can take a left argument as the args to pass to the executed file); dzaima/BQN's --help)

makes sense, for IO I think ⎕ and ⍞ are mostly fine

oh, that's one thing, they shouldn't output a prompt imo

⍞ has no prompt (if you don't set one), and you really shouldn't use ⎕.

fair enough, reading in ints with ⎕ is a lot more convenient than ⊃⌽⎕VFI⍞ though

If you're willing to risk ⎕, then what's wrong with ⍎⍞?

@rak1507 for a proper commandline thing you wouldn't want it breaking everything if one accidentally enters a single character that happens to be a variable

not exactly sure why that should be the case

@dzaima true

@Adám I thought you were saying you shouldn't use ⎕ for the same reasons that ⍎ would be bad too

@rak1507 Yes, that has always bothered me. I think I understand why, for historical reasons, but it is really inconvenient, and I don't know of a good workaround in Dyalog APL. APL*PLUS did have a workaround, albeit awkward.

I assume it can't be changed then

guess prompt ← {⍞←⍵ ⋄ (≢⍵)↓⍞} isn't too bad

Probably not "just", but some form of workaround could be added. IIRC, in APL*PLUS, if you did ⎕ARBOUT⍬ then that would "reset" things so the prompt wouldn't be included.

@rak1507 That fails if the user backspaces over the prompt (something I think shouldn't be allowed).

@Adám ugh, they can do that?

At least in the REPL. It may be different in a runtime terminal app.

But hey, that may be something we can change. I highly doubt anyone uses that as a feature.

I'd hope not

and yeah I suppose things can probably be different running from a terminal than from the repl

Well, I guess you could use it to supply a default answer.

@Adám it'd take a ton of effort to allow deleting in a terminal without just building your own custom IO with curses or manual escape code spam or whatever (which i kind of hope you're not?)

@dzaima Hence why I think it isn't so in the terminal.

I hope scripting support means it'll be doable to have APL on code.golf

I should install the latest 18.1 build.

potentially some other sites too but I doubt they'd add it

@rak1507 Yeah, basic stuff like just running a script, the way TIO needs it, that will work.

@rak1507 I'm meeting with Kattis tomorrow.

@Adám oh wow, really? cool

CMC fastest-code: Given a list of numbers, for each number, determine how many other numbers in the list are less than or equal to that number. E.g. 8 1 2 2 3 → 5 1 3 3 4

@Adám might as well start off with the obvious +⌿∘.≤⍨

Sort ascending + scan with something maybe?

@rak1507 Yes. And then beat that with +/∘.≥⍨

@Adám oh, that's faster? huh, ok

For good reason too.

something memory layout something?

Yes, the rows are consecutive in memory.

@Adám i have this though the ⍳ is a bit too much for this

+.≥⍤0 1⍨ is nice but it is also slow :(

@dzaima I don't think that's quite right.

@Adám how so?

      a
9 3 7 7 7 4 6 3 5 1
      +/∘.≥⍨a
10 3 9 9 9 4 6 3 5 1
      {(≢⍵)-⍵⍳⍨{⍵[⍒⍵]}⍵}a
9 2 8 8 8 3 5 2 4 0

⎕IO←0

D'oh.

@dzaima That's very good. You beat my solution.

Mine was {⍵[⍋⍵]}⍸⊢

ah interval index

dzaima's is nicer as a train ≢-{⍵[⍒⍵]}⍳⊢

shame sort is a whole 7 bytes

@Adám right, that's what i was thinking about, but, as i was writing it originally in BQN (hence ⎕IO←0) and couldn't remember what was ⍸ (it's dyadic ⍋ and ⍒), had to resort to something else

@rak1507 Yes. I'm lobbying for monadic ∧ and ∨ but it isn't looking very hopeful at this point.

:(

@dzaima actually, even {g←⍒⍵ ⋄ ⍵[g]} alone is slower than that, and dyadic ⍳ is hella fast anyway

I can see why not bc it's so easy to construct manually

@rak1507 Uh, no it isn't.

{⍵[⍋⍵]}?

probably some edge case

Fails on matrices.

boring

{(⊂⍋⍵)⌷⍵}

Yeah, that's the idiom, but annoying that {⍵⌷⍨⊂⍋⍵} and ⊢⍤⍋⌷⊢ are slow.

Another thing I'd like to see is bracket indexing extended to work on leading axes. But it is so hated that people are loath to extend it.

{⍵⌷⍨⊂⍋⍵} is slow and {(⊂⍋⍵)⌷⍵} isn't? :(

@rak1507 Correct.

probably an easy thing to sneak in to 18.1

But where is the limit? There are so many ways to express sorting.

{⍵[⍋⍵]}/{⍵⌷⍨⊂⍋⍵}/{(⊂⍋⍵)⌷⍵} are probably the main three

having an optimised ∨∧ would be nice though

so you don't have to do things like {...{⍵[⍋⍵]}⍵} to get speed because {...⍵[⍋⍵]} is slow

⊂⍤⍋⌷⊢ ⊂∘⍋⌷⊢ ⊢⍥⍋⌷⊢ ⍋⌷⍤0 99⊢ ⍋⊃¨⊂ …

what are the main arguments against it? just that it's unnecessary?

Every idiom takes a token id, and we're quickly running out of single-byte tokens.

Plus, thunks are really the right way to do this.

@rak1507 Wait, were you asking about arguments against optimising all of them or against ∧/∨?

@Adám against ∨/∧

Oh, that it is less general than a sort-by function, I.e. ⌷⍨∘⊂∘⍋

ah

So some want to re-purpose dyadic grade for sort-by.

so sort would just be ⍋⍨? not too bad I guess

Right, that's what it is in J (well, /:~).

yep

My counter-argument is that even sort-by is too specific.

I'd agree if it didn't make getting good sort performance all of the time much easier

What we really need is a permute function (⊇), that takes any permutation vector as left argument and an array as right argument.

@Adám :D

Then you could e.g. use grade to permute with ⍋⊇⊢

still doesn't solve the problem of needing idioms for performance

It kind of does, because then ⍋⊇⊢ would be the obvious choice, every time.

Even better if we had reverse-compose/before (⍛) so you could write ⍋⍛⊇⍨.

Four characters, like sort

would ⍵⊇⍨⍋⍵ be as fast as (⍋⊇⊢)⍵?

@Adám i feel like sort-by, outside of with ⍨ directly after it, would be used more rarely than both ⍋/⍒ and sort. Doesn't even solve the problem of sorting multiple vectors by the same permutation!

@rak1507 Not without thunks, no.

so in my mind that's still a problem

because it means you have to learn idioms rather than using primitives naturally as part of an expression

and like dzaima says, you can't do ⍵⊇⍨g←⍋⍵

@dzaima Exactly.

@Adám (i was about to say just ⍋⍛⊇, but that's only with BQN's ⊸ :/)

@dzaima There's no particular reason monadic f⍛g couldn't be that. It'd be J's "hook".

What else could f⍛g Y mean?

@Adám but it would be quite unsymmetrical to monadic ∘

Yeah, but they are not mirror images of each other anyway, and ∘ is also used for bind…

@rak1507 Hence my continued argument for ∧/∨. I think the all-important users would appreciate those much more than the nervousness of changing the meaning of (half of) two primitives.

I see ∧Y to ⍋Y much as ∪Y to ≠Y

if it is possible to make things like ⍵⊇⍨⍋⍵ fast through other methods, I think that would be preferable because then you can reuse ⍋⍵, which you couldn't through ∨/∧

∧Y is Y[⍋Y] and ∪Y is (≠Y)⌿Y

but if it's between having ∨∧ and not having them, having them is clearly better with no other changes

@rak1507 Thunks.

are they actively being implemented or is that a longer term plan

IANACP, but as I understood it, Marshall was going to implement thunks.

ah...

@rak1507 I don't think you'd want to be doing that - if you're already computing and using ⍋, sorting with a sort algorithm would be slower than just ⍵[gradeResult]

We have recently hired two new C programmers, but they are not experienced array programmers. Yet.

@dzaima oh right, good point

@dzaima (in fact, thunks might just do exactly that and lose performance for free!)

@Adám so marshall was so good he needed two people to replace him?

I don't think Marshall would want me to judge him in public.

@rak1507 No one replaced Jay when he left, and Geoff is incrementally retiring as well.

ah

Or Scholes for that matter, but he had been a long way from a full-time C programmer.