I tried both options, and both options visibly* degraded quality while failing to remove my hidden message. Consider that good schemes are already designed to be resilient in the face of lossy image compression, which is a lot more disruptive than the things you suggested.
* the 7-bit quantization + 1-bit noise option not by much, but still, visible
Precisely. There is no need to wait for "the position" to be formulated since a) it won't be; b) it's mostly "AI is bad because, full stop" anyhow, not even a strawman.
> it's mostly "AI is bad because, full stop" anyhow
Ooh, the rare* double straw man. Since you look like you could use the exercise in intellectual honesty, I’ll pose the question directly: can you think of any reason that the ability for anyone to generate fake photographs indistinguishable from reality with no skill, time, or money required might make the world a worse place? Cause harm?
Actual title: “Vectorized and performance-portable Quicksort” (2022).
Actual sense in which it’s first:
> Happily, modern instruction sets (Arm SVE, RISC-V V, x86 AVX-512) include a special instruction suitable for partitioning. Given a separate input of yes/no values (whether an element is less than the pivot), this "compress-store" instruction stores to consecutive memory only the elements whose corresponding input is "yes". We can then logically negate the yes/no values and apply the instruction again to write the elements to the other partition. This strategy has been used in an AVX-512-specific Quicksort. But what about other instruction sets such as AVX2 that don't have compress-store? Previous work has shown how to emulate this instruction using permute instructions.
> We build on these techniques to achieve the first vectorized Quicksort that is portable to six instruction sets across three architectures, and in fact outperforms prior architecture-specific sorts.
I don’t even disagree that “AI can help experienced engineers write better code in less time”, but “It would be too annoying for a human to ever write code to standards this high” when the standards are “zero dependencies, no libc, no alloc, no std, and [correctness]” and the project is <1500 lines of Rust implementing 20 syscalls is a little much. All software ever written before 2023 was written by humans, remember?
Of course. The humans that could have written this -eventually- certainly exist but they could not have collaborated with me to get me these results on my exact schedule in a week for the few dollars of pay I spent on electricity.
If your input is LLM-generated code, it's like taking snippets from Stack Overflow. You understand it fully and then make it yours. As long as you're hand-crafting the result, you grasp how it works.
This is an aspect of LLMs that probably shouldn't be understated.
I'm working on a validation tool with a coworker right now. We are meat-proxying it into existence, using less than two exchanges per day of his LLM validator and my LLM authoring engine (we could consolidate, but he's got some context I don't have and it would take more than zero engineering effort to ship it to me when PR messages through GitHub are a good-enough channel).
If not for the LLM, the tool wouldn't exist at all because we can't justify dedicating much of any engineering time to building it. But LLMs drive the engineering cost very close to zero, enabling the authorship of code that would never find engineering cycles otherwise.
I haven’t looked into the history, but my understanding from the comments is that it exists to preserve `x == y -> hash(x) == hash(y)` for `x` and `y` with different numeric types (int, float, decimal) – which seems like it should be solvable, but isn’t a constraint I’d want to be working under, so I sympathize.
* the 7-bit quantization + 1-bit noise option not by much, but still, visible
reply