| 14 Jan 2025 |
 polylokh_39446 | Sort ← { ((26⥊0) {1⊸+⌾((𝕨-'a')⊸⊑) 𝕩}´ 𝕩)/'a'+↕26 }
instead of swapping elements, get a histogram and then reconstruct the string from the histogram. | 22:00:28 |
 ngn | not quite | 22:00:55 |
| ngn | * not quite but close | 22:01:00 |
 dzaima | right, need to conditionally negate | 22:01:28 |
 rubenverg | i'm not convinced that an alphavet is a reasonable assumption | 22:03:15 |
 silas | neat use of for - confused me looking back as semi-expected compilation error | 22:03:22 |
| rubenverg | * i'm not convinced that an alphabet is a reasonable assumption | 22:03:23 |
 Olivia | x^(x>>63>>>1) technically, where x is the bits and the shifts are arithmetic+logical | 22:03:56 |
 Kamila | i already do that but it didn't quite work on some inputs last time i checked. | 22:04:02 |
| dzaima | ↰ dzaima or, as kamila has done, just reverse the negative half afterward | 22:04:44 |
| Kamila | ASCII input is a reasonable assumption in 99.9% of the cases | 22:04:56 |
| polylokh_39446 | in general it wouldn't be, but I thought part of the efficiency of APL is that primitives can check things like this, even retain it as array metadata, and then pick advantageous algorithms | 22:05:05 |
| Kamila | if you try to overgeneralise algorithms you miss out on a lot of performance | 22:05:10 |
| Kamila | e.g. you could always use bellman ford over dijkstra because what if i have a negative cycle, but then you make your code slow for no reason in particular. | 22:06:08 |
| ngn | that break stability, though in this case (sort key is the whole item) you dont care | 22:06:29 |
| Kamila | and i'm not sure how far can you go with optimising general algorithms without specialising them in some way at some point | 22:06:54 |
| dzaima | right, grade needs the negation (and you get to not have to undo it at the end) | 22:06:59 |
| Olivia | this converts the bits of a float to 2s complement-ish | 22:07:52 |
| ngn | xor with 1ll<<63 solves that :) | 22:08:27 |
| ngn | (they become unsigned) | 22:08:54 |
| ngn | er.. 1<<31, sorry (if we're still talking about 32bit floats) | 22:09:38 |
| polylokh_39446 | heh ≡○Sort also beats ≡○∧ at 1e6 length strings, but fares the worst otherwise. | 22:12:19 |
| ngn | whatever those are, they are most likely implemented by the same person - dzaima | 22:13:09 |
| polylokh_39446 | no, Sort is the a-z-only histogram sorter just mentioned. | 22:14:14 |
| ngn | ah, ok | 22:14:27 |
| ngn | dzaima: can you give a link to your c code for radix sort? | 22:15:15 |
| ngn | i want to test performance against my two-line radix sort impl | 22:16:33 |
| Kamila | what's your two-line radix sort :-) | 22:20:41 |
| Kamila | i think that a more fair metric would be the amount of semicolons in the output of gcc -E. | 22:21:09 |
| Kamila | * i think that a more fair metric would be the amount of semicolons (and commas?) in the output of gcc -E. | 22:21:53 |
