>The submitted article is about how they've achieved results
"They" meaning just Wisconsinites. The only political point I can find with a quick skim of the article is
>“There are well-documented concerns about how this company operates and uses its technology to violate people’s Fourth Amendment rights [against unreasonable searches],”
which is not what I would call a progressive political stance. If anything, it's conservative in the literal sense, of maintaining existing political institutions in their present state. It'd be more progressive (again, in the literal sense) to want to embrace more unrestricted surveillance.
What do you mean by "hotbed", then? Do you just mean, "there exists a party with that alignment?" What state is not a "hotbed of progressive politics" by this interpretation?
On a similar note in terms of frustration, my bank ended up getting me to memorize my randomly-generated passwords twice because it blocked pasting. I guess it's to discourage writing them down in plaintext files, but I bet it just makes most people choose meaningful (and therefore weak and guessable) passwords.
With CD-Rs it was already possible in the mid '90s, if we're talking mass production. CD-Rs are a little more expensive to produce, but not much more so. A slight concern is that readers of the time might not have been able to read the discs, because CD-Rs are not quite as reflective as CD-ROMs.
A reminder that CD-ROMs are pressed from glass masters, not burned like CD-Rs. I wonder if anyone has tried something like this with burned discs, though.
I'm reminded of that paradox from sci-fi that says that starting an interstellar journey as soon as the technology is capable of it is uneconomical, because the trip will take so long that newer technology will arrive at the destination first, despite departing at a later date.
It's not silly. If you're satisfied with seeing ads in a paid product then that's fine, but the other person clearly is not. Cancelling a service because it doesn't meet your expectations is perfectly reasonable. It doesn't matter how "it's always been".
I didn't mean it as a criticism, just a statement of fact. I can't do it either. It's difficult to say what about a writing style is bad beyond vague descriptions.
>Perhaps between model version releases, frontier labs can harvest the web and ask "What Claudisms do people mention negatively?" but I don't think they do that yet.
That won't happen. People can't phrase their objections in a succinct-enough way. When they do, the objection is superficial ("too many em dashes") and doesn't strike at the core of what makes LLM output bad.
It depends on what you need. For example a while ago I scanned and OCR'ed a bunch of receipts to get a timeline of my salary. I only cared about the gross and net figures, and nothing else mattered. Tesseract's output had a bunch of errors and misdetections, but the main figures always came out OK, and a local LLM was able to pick them out from the noise every time.
There's a big gulf between "it's as if a human being had transcribed it and reconstructed the original document" and "so completely broken it can't be used for anything".
>the fact that it's automatically collected makes it more troubling, not less
I don't think so. You can inflate raw data arbitrarily. They could have laid out on a page the decimal byte values of a one minute video clip of you waiting in line or something. Something redacted by a human would be much more dense in terms of relevant information, and much more digested. If it's just a data dump then at least it's information that not necessarily anyone knows, in the sense of residing in someone's brain.
Information collection is also not necessarily malicious. You can never know what you might need in the future. I was kind of on board with Recall, if the data could live in storage in my control and can I could turn it on and off at will.
It's funny that the only failure condition is running out of money, not "this whole branch of research is a deadend", nor "the model began unknowingly ingesting its own output as training data and imploded".
It's equally likely that the unit was implied by other content around the input field and the model didn't make the connection (like "scale: [___] mm"), or perhaps the file format was just wrong and a human placing the order would have resulted in the same outcome.
>The point is that the compiler has to deal with it and has to check if the function is exported or its address is taken.
Like I said in a different comment below, these are not obstacles for TCO. The compiler can simply emit a second copy of the function that doesn't need to honor a calling convention.
>So it’s a problem when implementing the compiler and adjacent tooling
Yeah, implementing a compiler is difficult work. Who ever said otherwise? I originally responded to a comment talking about TCO being incompatible with certain calling conventions. I.e. if your platform uses a certain calling convention then TCO is impossible. That's what it means for two things to be incompatible: you can have either one or the other, but not both at the same time.
No, I meant the former. Even if those conditions are not met, TCO is not off the table. The compiler can simply generate a second copy of the function specifically for the recursive call.
Do you often find yourself doing mutual recursion between functions crossing compilation units/modules? I'm not going to say it can't happen, I just don't see it as much of a problem.
That was in response to a specific point that TCO needed callee-cleanup. But nobody cares about TCO in non-recursive call stacks, and nobody does cross-module recursion. Hence my question: if the only situation where anyone would care whether TCO is being performed is one in which the compiler can see both sides of the call, what does it matter what the calling convention is? The compiler is not bound to use any calling convention to generate the code for the call, it can just generate the caller and callee to be compatible with other and with no one else.
Consider what was being discussed originally, though. If h() has fewer arguments than g() and is in a different module (e.g. a static library) from h() such that the calling convention was necessary, how would h() recurse back to g()?