CMC: Given a Boolean matrix, move all 1s to a random Moore neighbour. Distribution isn't important as along as all possible outcomes can happen.

@Adám is it valid for two 1s to go to the same square?

@dzaima No, that'd be trivial.

what should happen at the edges?

@dzaima Edges are hard walls.

@Adám then i don't see a simple/fast APLy solution, given that ⍉⍪1 9⌿0 1 is a valid input and the only output it could make is ⍉⍪9 1⌿1 0

@dzaima Right.

aw f⍢⍸ doesn't work in Extended (and in dzaima/APL i don't have padding ↑)

@dzaima (≢↑f⌾/) in BQN it is

@dzaima Wait, it should, cause ⍸ is invertible. What is f?

@Adám not done with that yet, but even ⊢ doesn't work

That's so odd.

@dzaima Oh, it is because ⍸ has a cover too. Works with `⍸

@Adám oh so even ⊢⍢-1 2 fails

@dzaima Yeah, because I've not bothered to define all the primitives using obverse.

@dzaima though random is a long •Rand and no simple way to pad edges with 0s

@dzaima back to dzaima/APL, ⍸⍣¯1⊢⍬ errors :|

@dzaima Odd, that should just be ⍬

@Adám yeah, it's a bug

73rd line on my dzaima/APL todo list ¯\_(ツ)_/¯

@AndriyMakukha Welcome back. Getting ready to present?

@dzaima actually that's not the only valid output - e.g. ⍉⍪1 0 1 1 is also valid - swapping the last 2

@Adám got a 70-byte dzaima/APL solution, and a 52-byte one that has a very high chance of stack-overflowing

was stuck on wondering why a 2-byte golf wasn't working when i realized that f⍣g A will always execute f once :|

how do I prevent text wrap again?

@Razetime aplcart.info/?q=wrap%20output#

kewl

@Razetime I've added some synonyms so it should be easier to find next time (e.g. with "prevent text wrap")

thanks a lot

I created this function for checking similarity of polygons: {w←↑2(2*∘÷⍨1⊥2*⍨-)/¨(⊢,⊂∘⊃)¨⍵ ⋄ {⍵(⌽@1)w}¨⍳1⌷⍴w}

@Adám , yes, I am. I just wanted to ask you guys what "6::" is. By I figured it's an error-guard in dfns. Is this feature only supported by Dyalog APL?

@AndriyMakukha Yes.

I want to present some elegant solutions by other contestants which I liked very much, so I am trying to understand them first 😂

Happy to assist ― if I understand them…

@dzaima golfed a byte off both, and made a Dyalog port at 54 chars

@dzaima Might be more interesting to label the 1s (i.e. ⊢×+\⍢,) so one can see where they move to.

@Adám brings the dyalog solution up to 62 chars - replacing 1@ with (1+⍳∘≢)@ and a 0≠ later

what's your best?

This might be a good challenge for Main.

@dzaima Didn't try, it was just an idea I got while walking kids to school.

(I spend 1.5 hours a day on that, of which half is by myself, so I get a lot of thinking time.)

Pushed my array formatting (including: •Out for direct output, only accepting certain atoms and char vectors/matrices, and making ⍕ use those same rules; •Pretty for getting a prettified form, with a left argument of 1/2 for formatted/single-line, potentially adding number formatting rules later; )ln to toggle single-line mode or )ln expr to use it once), that drawing system thing, and •Comp optionally taking 2 extra args of indices & source

@dzaima ⍕∞ now gives "Infinity". That's a bug, I hope?

@Marshall yeah. my number formatting there was done pretty lazily

@dzaima It also gives more digits for many floats, such as 0.01831563888873418, in case you weren't aware. I don't know if that's good or bad.

@Marshall it's using java's built-in formatting, though it should output the exact value imo. the default pretty-print formatting has •pp←14, which discards the last couple digits otherwise

though now i'm reminded that •pp has no effect now. But I planned to remove it anyways & replace it with )pp or similar, as it's a Sys-wide setting rather than scope-wise, and should only be used by the REPL

(another question is how NaN is treated, since currently it mostly exists)

@dzaima Maybe whether NaN is allowed should be configurable? I'm inclined to say the default should be not to allow it.

Also worth noting that NaN-boxing is a good strategy for implementing BQN.

@Marshall would erroring on NaN result in some performance penalty?

(it certainly would have plenty in java, wondering more about a proper impl using fancy vector instructions)

@dzaima For array operations on any current architecture you can check exception flags, so usually not.

BQN's REPL page now has an expression explainer! The "Explain" button activates it.

This tool uses the compiled source to show the flow of evaluation through an expression. It doesn't yet handle lists or multiple expressions, but these should be fairly easy to add. Also no support for blocks, which will be harder.

I could also do something to illustrate the type of operation being applied, perhaps with colored lines or hovertext.

@Marshall Do you have a nice larger example?

@Adám Here's one from the Group tutorial. It works but the background text doesn't line up right (I designed it for single-character tokens).

CMC: Given a vector of vectors, mesh them, skipping vectors when they run out of elements. E.g. 'abc'⎕D'ABCDEF' → 'a0Ab1Bc2C3D4E5F6789'

(There's not any way to automatically run the explainer now because it currently has script injection vulnerabilities.)

@Marshall Nice, but is it just me, or is it very slow (about 4 seconds)?

@Adám It's pretty slow. The runtime isn't very good for text manipulation, and the output isn't constructed in a very performant way.

Oh, it's also formatting the SVG positions using BQN code that actually constructs the digits. That might be the main cost.

•Comp can now optionally take token end positions (using this for testing)

@dzaima Every instruction should have a start and end position fairly soon, so you won't have to worry about tokens. Then function and operator application could have carets covering all parts of the application like dzaima/BQN does.

e.bqn uses the tokenizer output mainly so it has access to token roles.

(also i'm thinking about making a •Decomp/•Comp⁼ to allow programmatically changing code/DSL, now that •Comp can now do pretty much everything)

•Comp⁼. Nice.

@dzaima Did you see the join extension proposal (three messages, plus a response to Adam)?

@Marshall I saw it, but my thoughts about it fluctuated too much for me to decide on anything

{c←⊃(⎕A,⎕D)~⊃,/⍵ ⋄ m←⌈/≢¨⍵ ⋄ c~⍨,⍉↑{⍵,c⍴⍨m-≢⍵}¨⍵} @Adám beautiful code right here

@dzaima (is this really how i left ⊇?)

@rak1507 ?

That does the CMC (and the code is horrible)

@dzaima ah, seems it's more non-broken with non-character arrays

@rak1507 Huh, I'm not sure I understand what's going on here. Why remove from alphanumerics?

@rak1507 If the input contains all of ⎕A,⎕D it will probably start stripping spaces though.

it will yeah, could always replace with ⎕UCS¨⍳1000

Or something

@Adám c is the first alphanumeric character not in the input, which is then used as a fill character, and then removed

Ah, you're finding a suitable padding element. Ugh.

Haha

You could also use a number that doesn't appear.

@rak1507 May want to look at this perfect shuffle implementation instead.

Oh yeah, perfect shuffles, that reminds me of your talk about transposing boolean arrays

Or relatedly you could use a separate boolean array to keep track of which elements to drop.

@Adám dzaima/APL, 17

My best so far is 14 in vanilla 18.0

Wow

@Marshall Yup, that's my method.

@Marshall Comes out slightly longer, but works for higher-rank too.

@Adám Uh, 10 in BQN.

@dzaima got 10 in dzaima/APL (ah, it's the same as Marshalls BQN), and the "slightly longer" 15 in Dyalog

@Marshall Yup, that's pretty much a direct translation, but lack of join and sane indexing blows it up.

@dzaima Wait, doesn't your 10-byter fail on non-simple vectors?

@Adám ah, it does. 13 it is

Yup, I got 13 in Extended too.

@dzaima That fails on numbers that are not non-negative integers.

@Adám ah, the input isn't guaranteed to be only character vectors

I never promised that.

@Marshall > doesn't seem to pad. How does one do that then?

@Adám {>(⌈´⥊≢¨𝕩)⊸↑¨𝕩} if they all have the same rank.

Judging by the fact that none of the APL answers actually work the length of that expression is entirely warranted.

@Marshall What do you mean by "none of the APL answers actually work"?

@Marshall Maybe an idea for ≥?

@Adám but why?

@Adám All the shortest mix-based solutions have problems when the fill element is present in the data.

BQN shouldn't be guiding the user towards that sort of bug.

@Marshall That's not true.

@Adám which solution here using ↑ works?

@dzaima (also that)

My vanilla 18.0 14-byter is ↑-based and works.

OK, I've even got a ↑-based 13-byter in Extended.

@Adám and i got a ↑-based 10-byter in dzaima/APL. still a "stupid" solution imo

@dzaima Oh, I only have a (theoretical ― not tested) 11-byter.

@Adám got that 14 too

@dzaima and with the above golf, got 9 in dzaima/APL

@dzaima OK, now I want to see.

@Adám would it work with namespaces as elements?

@dzaima Ah, good point. That'd fail. OK, the ⍋-based approach it is. Good thing I didn't commit mine to APLcart.

(I just wish namespaces had a usable prototype. Anything would do.)

@Adám i wish quite the opposite - prototypes would be erased when it's the most sensible thing to do

So, best I've got in vanilla, and working for high-rang arrays, is 17.

@dzaima Problem is determining when it is sensible to do.

@Adám when it doesn't harm at all to keep the prototypes, only then keep them imo

Ouch, now I need sane indexing again. Or at least Marshall's proposal for omitting trailing ;s.

Oh, but still 17. OK.

@dzaima (i'd rather have no prototypes ever, and maybe have an operator form of ↑ & similar, properly taking the wanted fill element)

@Adám (that was 1¨¨⌿⍥⍉⍥↑⊢)

@dzaima It'd be annoying to always have to supply an operand for so many common functions: ⊃ \ ⍀ / ⌿ ⍴ ↑

@dzaima Ah, I forgot that ⌿ auto-ravels in dzaima, even though I thought about that extension today.

@Adám /⌿ don't need fills unless you have negative numbers in the left argument (which are awful anyway), and ⍴ needs them very rarely.

@Adám i'd guess that the ratio of filling in those being a bug rather than a feature is quite high (except slashes where it kind of has to be intentional)

(and if ↑ took an argument of a fill element, a working solution would be to use the argument array itself as the prototype, and then remove itself from the ↑ed array :D)

@Adám yeah, I've found it to be quite useful. (as a side-note, I encounter (+/,) quite often too, but having a flattened reduction operator would feel kind of useless)

@dzaima Do you flatten all the way, or do you only merge leading two axes of both arguments until the left argument is a vector?

@Adám i just handle the case of ≡⍥(≢⍴) and nothing else in my ⌿

@dzaima I see. I think gradually merging would be useful, as that allows treating high-rank arrays as collections of cells.

@Adám it probably would, but i still haven't seen this cell business being too useful

@Adám I'd describe it more as leaving out trailing axes of the right argument from the computation, or mapping over them.

@Marshall Right, that's the intention. I was just describing the implementation.

@dzaima (reminded me of {⍺⍀⍵~0}⍢(,⍉) in this)

@Adám I don't think I'd describe the implementation that way either: it treats the right argument's leading axes as one virtual axis. Sure, you have to find the length of that axis by multiplying numbers one-by-one, but I think it's weird to describe that as a series of merges.

I am weird ¯\_(⍨)_/¯

It actually would be the normal academic/recursive way to formalize it though.

<moon-child> theplatform.technology k-inspired language/database

<moon-child> (reddit.com/r/kdb/comments/gyezw1/… gives a somewhat higher-level overview)