| 15 Jan 2025 |
 dzaima | build CBQN with make o3n, search for si_scan_pluswrap in build/obj2/; gtg sleep | 01:04:28 |
 ngn | thanks | 01:05:57 |
| dzaima | it's not that much faster for u32 iirc, and there isn't even a u64 case | 01:06:36 |
| ngn | oh :( | 01:06:45 |
 discodoug | I was planning to try this: https://en.algorithmica.org/hpc/algorithms/prefix/ | 01:22:49 |
|  en.de.lis changed their profile picture. | 03:48:39 |
 Marshall | ↰ ngn Radix sort moves the elements, counting sort reconstructs them. For small sizes, radix doesn't do as many passes over the counts so it's faster. | 04:42:29 |
| ngn | got it | 04:43:21 |
| discodoug | @Marshall - For clarity the “elements” here are indices right? I tend to think of “sort” as including the indexing. | 05:37:48 |
| discodoug | Maybe it was taken for granted that we’re after a grade here but I was a little thrown by elements not moving with a sort. | 05:41:14 |
| ngn | i believe this is about "sort" as the full {x@<x} not just "grade" | 05:49:44 |
| ngn | if you're sorting bytes, you can count how many have values 0,1,2..255 and instead of moving them around, just construct the result from the counts | 05:50:57 |
| ngn | it would be the equivalent of c:&256; c[x]+:1; &c in k | 05:51:37 |
| ngn | note how &c generates the correct result without any swapping or indexing or amending | 05:52:34 |
| ngn | shorter: &@[&256;;+;1] | 05:53:58 |
 .casenc | No | 08:17:01 |
| .casenc | Not at all | 08:19:11 |
 rubenverg | especially in... you know... a language that uses glyphs that aren't ascii? | 08:24:11 |
 Kamila | if you store code in strings and want to check for it being palindromic, i guess | 08:31:05 |
| rubenverg | though i guess at worst you're gonna be using a codepage anyways | 08:31:30 |
| rubenverg | which for the purposes of the problem is equivalent to just ascii | 08:31:39 |
| .casenc | Or essentially any human language | 08:35:17 |
| Kamila | dyalog has optimised codepaths that dispatch on 4 different element types for a character-type pocket | 08:36:45 |
| Kamila | horrible to look at on some occasions | 08:36:59 |
| Kamila | i haven't ran any statistics, but i wish that i did, because my suspicion is that 8-bit wide and 16-bit wide pockets would've been the most popular. | 08:37:55 |
| Kamila | * i haven't ran any statistics, but i wish that i did, because my suspicion is that 8-bit wide and maybe 16-bit wide pockets would've been the most popular. | 08:38:00 |
| .casenc | Whar | 08:38:07 |
| .casenc | I'm only saying that "strings can be presumed ascii" is plain incorrect | 08:41:07 |
| Kamila | ok :). if you assume strings to be unicode and want to write a proper is_anagram function, then you need to keep in mind that... Soeren has 5 alphanumeric characters, on the other hand there are only 6 letters in Aalborg, the word Æterna has either six or seven letters depending on the current locale and α is either a letter or number, where in the latter case it can stand in for an one. to my knowledge no array runtime handles these correctly (just tried Dyalog) and neither of the methods work. | 08:51:13 |
| Kamila | * ok :). if you assume strings to be unicode and want to write a proper is_anagram function, then you need to keep in mind that... Soeren has 5 alphanumeric characters, on the other hand there are only 6 letters in Aalborg, the word Æterna has either six or seven letters depending on the current locale and α is either a letter or number (ancient greek locale), where in the latter case it can stand in for an one. to my knowledge no array runtime handles these correctly (just tried Dyalog) and neither of the methods work. | 08:51:58 |
