fluoridation

You can still sell snake oil that's purported to improve ECGs.

Yes, you can hurl insults at inanimate objects.

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.

Nitpick: The word you meant to use is "offend", not "insult". Just because you can't cause offense to a toaster doesn't mean you can't insult it.

>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.

I have a button on my mouse set with a macro to autoclick as fast as possible, from my time with Cookie Clicker.

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".

What I mean is that the file was specified in one unit/resolution and the site expected a different one. Like, "draw a circle of radius 2 at (3, 3)".

I see I'm not the only one who was severely disappointed this has nothing to do with simulating repetitive strain injuries.

What does that have to do with how much detail the sensor cells are able to resolve?

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.

It's still impossible in the general case, where not all arguments are passable by registers.

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.

Extremely specific example is uncompelling.

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()?

>But if you said that, and [...] I'd be likely to believe you.

That wasn't what I asked. I was very deliberate, I asked if it would be more likely to be true. What's under discussion is not your standard of evidence, but whether non-contradiction by itself is sufficient to conclude that a claim is true.

>Alas, a quick look at the periodic table raises a red flag

That's not self-consistency anymore, that's cross-corroboration. Which, yeah, good on you if you do that, but it's not the process being proposed either by the OP or by fy20.

>Physicists aren't routinely replicating every core result empirically for themselves.

OK, but that wasn't what I said. A physicist can't test every result, sure, but he can test those that are most relevant to his work. I'm not going to get into the philosophy of empiricism because it's not relevant here. My point was that an expert reading a peer's paper is not the least bit comparable to a layman reading an LLM's summary of a field of study. They're just not similar situations. One has the context and the capability to detect bullshit, while the other does not.

>In a callee cleanup convention, a tail caller could adjust the stack and jump to an unaware tail callee.

You can still do that with a caller-cleanup convention. Suppose you have a convention like

* Set up stack

* Call

* Clean up stack

and you have functions f(), g(), and h(), where g() and h() use this convention and f() calls into g(), and g() into h(). The sequence of instructions from f() to h() without TCO would be

* f: Set up stack for g()

* f: Call g()

* g: Do work

* g: Set up stack for h()

* g: Call h()

* h: Do work

* h: Return

* g: Clean up stack

* g: Return

* f: Clean up stack

And with TCO:

* f: Set up stack for g()

* f: Call g()

* g: Do work

* g: Move things around on the stack so that h()'s arguments are written where g()'s were. This may require a temporary stack allocation that's released before the next step.

* g: Jump to h()

(At this point it looks as if f() called h() directly.)

* h: Do work

* h: Return

* f: Clean up stack

This is always possible as long as h()'s caller-managed stack allocation is no bigger than g()'s.

Yyyyes... But like I said, TCO cannot make use of the calling convention, because it doesn't involve calling. That means you can't have TCO loops crossing module boundaries (or function pointers for that matter). So we're back to my original question: what does it matter what the calling convention is if the compiler has the liberty to compile both functions however it pleases?

Functional languages may be designed to support TCO from the ground up, up to supporting it across module boundaries. C is not like that, and calling into an external module necessarily grows the stack.

If it doesn't control both then TCO is impossible, because the stack will grow with each recursive step, as it's just performing a normal call.

But the compiler controls both the caller and callee. It doesn't need to respect any calling convention during a TCO. In fact it won't; it'll jump instead of calling.

You don't seem to be disagreeing with GP, you're just saying that correctness may be practically impossible.

I can't see why the calling convention could matter. Can you give an example?

You can look it up, it's in online dictionaries.

gochisou: "feast"

sama: honorific

deshita: past conjugation of "desu", meaning "is"; thus, "was"

In other words, "[that] was a feast".

Why not just measure it by weight then? That's what we do here.