| 23 Mar 2025 |
 dzaima | (on slow Under stuff, I'm reminded that CBQNs F⌾(m⊸/) isn't particularly fast either, and is almost never faster than F⌾((/m)⊸⊏)) | 00:06:38 |
| dzaima | * (unrelatedly, on slow Under stuff, I'm reminded that CBQNs F⌾(m⊸/) isn't particularly fast either, and is almost never faster than F⌾((/m)⊸⊏)) | 00:07:02 |
 Marshall | Branchless index generation's hard to beat. When is F⌾(m⊸/) faster, other than for constant functions? | 00:10:00 |
| dzaima | for, like, an all-ones mask, or close to that, or something, iirc; looked at it some while back | 00:11:01 |
| dzaima | also makes less passes through memory | 00:11:14 |
| dzaima | * also generally requires less memory bandwidth | 00:11:39 |
| dzaima | of course breaking into blocks fixes that | 00:11:59 |
| dzaima | more unrelatedly: have thought about moving * in BQN386 upwards (presumably top-aligned to modifiers?), so it's not exactly the same as ⋆ (which'd stay center-height) | 00:13:50 |
| Marshall | If we can detect scalar F, a version that used blend for denser m would be neat. Which I guess decomposes into ⊣⌾(m⊸/) after applying F. So like a+⌾(m⊸/)b is (a+b)⊣⌾(m⊸/)b. Monadic cases would probably have bound arguments, a little more effort to detect. | 00:13:57 |
| Marshall | If we're ignoring suitability for APL I'd give the asterisk six points, but moving upwards makes sense too. | 00:15:18 |
| dzaima | APL386 has gotten ~all of BQN386 copied into it iirc so APL's got a BQN-compatible-but-primarily-APL font already | 00:16:42 |
 Madeline Vergani | I think new apl386 has all the glyphs | 00:23:36 |
| Madeline Vergani | including weird doublestruck | 00:23:43 |
|  @juuso:matrix.ponkila.com removed their profile picture. | 00:25:34 |
| @juuso:matrix.ponkila.com removed their display name juuso. | 00:26:17 |
| @juuso:matrix.ponkila.com left the room. | 00:27:05 |
| dzaima | 
Download Screenshot from 2025-03-23 02-43-02.png | 00:43:19 |
| dzaima | aligning with modifiers is stupid and ugly; here's top-aligned with numbers | 00:43:35 |
 twobular | now add a star sitting on the baseline | 00:45:25 |
 rubenverg | also a star rotated 36 degrees | 00:46:17 |
| twobular | overstrike the baseline star with an asterisk and devise an operation that could bear the resulting glyph | 00:47:43 |
| rubenverg | ⁑? | 00:48:38 |
| dzaima | 
Download Screenshot from 2025-03-23 02-59-36.png | 00:59:47 |
| dzaima | and that's properly-symmetrical rotations (managed to do it in graphite.dev nodes despite some glitchiness), unlike BQN386's ◌ :) | 01:02:07 |
| dzaima | * and that's properly-symmetrical rotations (managed to do it in graphite.rs nodes despite some glitchiness), unlike BQN386's ◌ :) | 01:02:54 |
 discodoug | Those stars look happy at least.. | 03:14:36 |
| rubenverg | oh didn't realize how asymmetric it was | 07:21:15 |
|  @ge24z009:matrix.org left the room. | 11:00:55 |
| Marshall | ↰ ae7tb99 Tried a few more tweaks to this, only really good thing I found was that MPr ← MPl⌾⍉˜ is simpler and faster (but the fastest I have is MPr ← {MP⟜𝕩⌾(((↕⊸×´≢𝕨)+⌜i)⊏⥊)𝕨}). Finding the pivot is asymptotically expensive, and saving the maximum index in each row helps with that, but the criterion for when to update it is complicated and it's not that much faster: I get 35% at side length 100. | 16:43:21 |
| Marshall | The parallel Jacobi that groups n/2 independent rotations seems really promising, both because it drops the pivot search and because you can stick to row-wise operations. That is, do all the left multiplications, then transpose and do all the right multiplications. So all the arithmetic is vectorized and it doesn't have to pick out individual columns. | 16:45:24 |
