@AviFS from IBM?

@AviFS with that you're just timing Go's bigint impl

@dzaima Yeah, I figured the bigint bit wasn't the interesting part, though I didn't realize it was just a stdlib. But I was still impressed with the speed, and just curious how well a, presumably relatively naive, implementation in Go stacks up against Dyalog's meticulous optimizations.

@LdBeth Possible! Do you know the paper?

It has little drawings, that's probably the key identifier.

@rak1507 seems that takes about the same time as */1+i. 10000x (both taking ~190ms), so noone's bothered optimizing factorial specifically. dzaima/APL takes ~30ms for both, but a simple recursive solution goes down to 3.6ms

@AviFS could look through this

It was "APL - A Glimpse of Heaven." I finally found it by remember that it was Bernard Legrand. (Same guy who wrote the Mastering Dyalog APL book.)

@dzaima Interestingly, it's not there.

yeah, it's not particularly complete

@dzaima I know. That's where I come in :p

APL - A Glimpse of Heaven, by Bernard Legrand

Does anyone else think it's well-written? It was hard to find! It's the paper that got me into APL.

I don't even know if I'd like it now, but I clearly liked it then.

@dzaima I actually tried the same thing with the Go implementation! Also seems to be the same amount of time, though I didn't time it precisely. I didn't think there was an optimization for factorial, is there?

@AviFS it seems to just invoke the stdlib

..and that seems to do what my dzaima/APL recursive solution does - split into halves recursively

Interesting, there actually are clever factorial algorithms, but I got no results for "factorial algorithm" on the first page of Google, except for two CS.StackExchange threads. Here's one, with a nice answer.

I think that's the most complex complexity I've ever seen in the wild.

Tons of factorial algorithms

@dzaima Ah yeah, funny that I didn't get any top hits for that on Google. It comes up in the Stack Exchange answers, but it looks like the best algorithms are more efficient still.

@dzaima Do these... methods work for reducing any array, though? Or do they make use of the fact that they're 1-n.

the recursive splitting should work for any associative function on any array

I mean like that particular technique should just be an improvement over any reduction. I wonder if there are any algorithms that actually take advantage of the properties of a factorial.

@dzaima Good point on the associativity!

any insight?

ah, it's probably because the results aren't boxed, J doesn't support nested iirc

yeah, fixed it: <"1 'chsd' ,"0/ 'A23456'

some things i managed to write with my very little j knowledge

Interesting

I didn't know there was an each keyword

   <"1 'chsd' ,"0/ 'A23456'
┌──┬──┬──┬──┬──┬──┐
│cA│c2│c3│c4│c5│c6│
├──┼──┼──┼──┼──┼──┤
│hA│h2│h3│h4│h5│h6│
├──┼──┼──┼──┼──┼──┤
│sA│s2│s3│s4│s5│s6│
├──┼──┼──┼──┼──┼──┤
│dA│d2│d3│d4│d5│d6│
└──┴──┴──┴──┴──┴──┘

that produced the desired effect however ^

@ElectricCoffee Indeed. 'chsd' ,each/ 'A23456' does the trick.

what is the difference between ⊆ and ⊂ used monadically?

⋄ ⊆ 'this' 'that'

@Richard
┌────┬────┐
│this│that│
└────┴────┘

nvm, basic thing is that ⊆ doesn't increase depth if its argument is already nested whereas ⊂ does.

thanks @Rich

⋄ ⊂ 'this' 'that'

@Richard
┌───────────┐
│┌────┬────┐│
││this│that││
│└────┴────┘│
└───────────┘

how keen are people for an emacs major mode that is as feature complete as RIDE? On one hand, I'd bet that you can do all the stuff you'd need to do by using org-babel + the jupyter kernel; debugging can be done printf style methinks, just put stuff like {##.debug,←f ⍵} for suitable f. OTOH, interactive debugging is a lot more fun once you get used to it I'd imagine.

@M4X_ ≢counts sub-arrays along the first axis, so the mean should count elements along that axis. To give a concrete example in 2D consider: ⋄M←3 4⍴⍳12

@11Kilobytes Response looks like a 0-by-0 matrix.

hmm, let's try that again:

⊢M←3 4⍴⍳12

⋄⊢M←3 4⍴⍳12

@11Kilobytes
1  2  3  4
5  6  7  8
9 10 11 12

Now: ⎕←≢M

@11Kilobytes
VALUE ERROR: Undefined name: M
      ⎕←≢M
       ∧

Now observe that ≢the number of rowsb.c. that's the first axis; so that you get 3 instead of 4 in: ⎕←≢3 4⍴⍳12.

@11Kilobytes 3

Observe that in aligment with this +⌿ takes the sum along each column: ⎕←+⌿3 4⍴⍳12

@11Kilobytes 15 18 21 24

Never mind, it seems I made a mistake. Perhaps it is better to say avg←+/÷≢. :D

okay

so its suppossed to be avg←{(+/⍵)÷≢⍵} not avg←{(+⌿⍵)÷≢⍵}

not exactly sure though, like i'm thinking about the n dimensional case @M4X_

Am new to APL

@M4X_ nah. Actually the standard avg←{(+⌿⍵)÷≢⍵ is correct because you have to divide by the number of elements that you add up - not something like "the number of averages you are calculating."

Consider again our example ⎕←3 4⍴⍳12.

@11Kilobytes
1  2  3  4
5  6  7  8
9 10 11 12

Notice that ≢counts the number of rows. ⎕←≢3 4⍴⍳12.

@11Kilobytes 3

That means that it is the thing you divide by when you want to calculate the average of each column not each row. So let's look at e.g. ⎕←{(+⌿⍵)÷≢⍵}3 4⍴⍳12.

@11Kilobytes 5 6 7 8

thanks for the clarification

This is a four element array (same as the number of columns), and you can see that e.g. the first element is (+⌿1 5 9)÷3 ←→15÷3 ←→ 5.

@M4X_ welcome, sorry if I was too confused at first. Have a poor diet and drank too much coffee. Anyway have you heard of trains, they allow you to be even more concise in such cases and write avg←+⌿÷≢ for example. Click through on that link if you are curious.

@11Kilobytes If you edit your message, the bot will also edit its response.

@Adám thanks for the info.