hansvm

> unfalsifiable

If we're trying to piece together how the past actually happened based on the shadow it left on the present, yes, falsifiability is hard, sometimes possible to achieve. Most of the speculations I provided could be reasonably well tested though.

Take (5) as an example. If you find other important byproducts from the associated genes, those strengthen (5)'s argument. If you find significant negative effects from the new "miracle" proteins, those strengthen (5)'s argument. If you find an organism with an energetically intensive mechanism for removing these new "miracle" proteins, those strengthen (5)'s argument. If you apply a medicinal intervention to allow the gene to be enabled but those particular "miracle" proteins to be disabled in a wild population and observe the gene frequency dwindle, that strengthens (5)'s argument.

None of it's perfect, but there are a variety of experiments and observations you can do to strengthen or weaken your belief in specific causal mechanisms.

> used to justify unjustifiable positions

I go back and forth on this one. Should you hide information (in this case, not even very good information, just plausible mechanisms, provided because somebody was a bit curious and I thought scratching that itch might help them on whatever journey they're currently undertaking) just because it's possible to misunderstand it? Because it's prone to misuse?

Like, obviously if people are concluding from a list of guesses appropriately described as such that osteocytes evolved to extend life as a poorly calibrated part of the exercise process, that's not justified. What happens when people extend similar wild speculation to gender or racial differences? You're right, it's a touchy subject.

On the other hand, that's an argument against:

- Data-driven organizations -- a common cognitive bias is the spotlight effect, and applied to "data-driven" organizations it often leads to abandoning intuition and reason when the best proxy measurements you're able to perform incorrectly suggest a different course of action to be optimal.

- Giving correct estimates to your PM -- you know the organization will run more smoothly if you start unraveling the spaghetti sitting in fromt of you, but (in many orgs) it'll take longer to argue that point than it will to just do your job correctly, so you fudge ticket descriptions and estimates to make sure critical maintenance happens.

I try to evaluate that sort of thing on a case-by-case basis. I think it's fine here. I don't have a good justification for why I think that.

TFA explicitly calls out exercise as something which would generate those compounds. Exercise has many other impacts though, so if you're trying to isolate osteocytes as a causal factor you want an experiment which avoids interacting with those other systems as much as possible.

Pure speculation on a few possible explanations (noting that TFA describes ordinary exercise as generating enough squishing force, any other actions the researchers did being to isolate the causal factor):

1. Mammals don't naturally exist in environments where exercise isn't mandatory. _Some_ system had to generate those compounds, and there was never any pressure to keep it from being tied to the other stress-related changes bones undergo (like density changes). Once it evolved once somewhere in some critter once via that machinery, the advantage was large enough that it was locked in.

2. Exercise directly contributes inflammatory factors. Tying the cure to those to a measure of exercise intensity (bone squishing) helps calibrate the dosage. Even if an imperfect measure, the proxy of bone loading might confer some advantage in, e.g., not wasting energy on unnecessary proteins.

3. Exercise indirectly suggests a resource-poor environment, leading to lower chance of offspring succeeding and needing longer lives to produce enough viable offspring. The compounds in question aren't free to produce, so there's an advantage in only providing them to organisms who will meaningfully benefit. Mind you, resource-poor environments often promote shorter lifespans and faster growth cycles as an evolutionary trait, _but_ without a mechanism to force your offspring to mature more quickly the osteocyte-mediated lifespan could allow for resource-dependent lifetime offspring counts.

4. The mechanism could have evolved for unrelated reasons, perhaps directly contributing to the bone density calibration osteocytes already mediate. Any impact on lifespan is incidental or otherwise produces less evolutionary pressure for or against the feature than the direct purpose of the compounds.

5. More than having evolved for unrelated reasons, the fact that the compounds have any effect at all might not be evolutionarily selected for. We produce plenty of unimportant metabolic byproducts that we don't particularly care about, and it could be that some more important osteocyte function incidentally produces these "waste" proteins.

Sure? All of that seems post-2010ish. I think we're agreeing with each other, but placing that comment in response to mine instead of a different one gives off a different impression.

IIRC that changed when the company changed hands in 2010ish.

I was sorely tempted to fully bypass the kernel for networking before, and this isn't exactly giving me warm fuzzies for staying.

IME SMT is approximately useless if your code is any good and you have one obvious source of load (the foreground game, a trading engine, etc). I just reduce thread count to at most the number of physical cores if my software is the dominant workload. How did developers typically work around that xbox deficiency?

Absolutely. That's why I stopped validating passwords and emails. Nobody votes with their wallets anyway, so I don't have to worry about losing customers, and regulations only go after the evil hacker testing whether 1234 might work as a password, not me for choosing not to check its hash against my database. Law-abiding citizens would never try to impersonate one another, so I'm sure fraud on my platform is low.

They have a HN history going back nearly a decade (pre-LLM) with comments mostly not looking like trolling to me. My first guess would be that they've just been exposed to a bad implementation of Pair Programming and TDD (or even a "good" implementation in an environment where it's not a good fit), and that's where they developed those opinions.

TDD especially has a lot of critics. Some of that's justified. Some of it is just a difference in thought methodologies (e.g., a fraction of developers "think" through a problem by writing code, and the "tests" mandated by TDD physically can't meaningfully appear till after some implementation has happened). If a rando developer thinks negatively of it, that's not news to me. If they haven't tried it much and misattribute the exact cause of those negative opinions to be able to form a nice story-centric through-line, that's also not surprising. I'd be much more inclined to believe they're a developer who you disagree with than a deliberate troll. Who knows.

Maybe. That hometown I referenced has 3k people in the city (not farmers) and 12k people in the county outside the city (mostly farmers in varying capacities). It's the only place I've lived where it's common for people to cut, mill, and dry their own lumber for economic reasons, or (ignoring parts of Alaska I've lived in) for hunting to be an economically rational thing to do. There are literally zero vehicle fires. A home or business per year or two burns down, but at the 1/100 vehicle fire rate we expect 3 fires per week, and there are zero in the last decade. It's a hot, dry climate made up of mostly farmers with extremely shoddy equipment.

Anecdotes aren't everything. If there are 1/1k fires annually then those have to come from somewhere, so your "location dependent" idea makes a lot of sense. I'm passionately curious now as to where those fires actually happen though. It's not just farmers with bad equipment in bad scenarios.

What's your method for implementing rigorous testing while using AI?

I'm interested in that rant (at $WORK we adopted hash() for almost everything, and I'm curious to hear other perspectives).

- Their own privacy policy [0] says as much. "We may share your information [for] ... marketing"

- Their own list of third-party cookies [1] has a laundry list of those associated with personalized advertising across a variety of providers.

- ConsumerReports and Northeastern [2] found the car directly connecting to 34 advertising domains (with similar results from many other such investigations from other parties), not even bothering to filter it through Tesla servers.

And so on. This isn't a grand conspiracy. Privacy invasions are a big part of nearly every modern, large company. I'm not singling out Tesla in this instance. Repeating my claim, if the ToS bothers to say that your information is neither sold nor rented and the lawyer who drafted it didn't bother to include "sharing" in that promise, that omission was intentional approximately 100% of the time.

Good? Bad? You decide. It's happening though.

[0] https://www.tesla.com/legal/privacy#how-we-may-use-your-info...

[1] https://www.tesla.com/legal/cookies

[2] https://www.consumerreports.org/electronics/personal-informa...

That's the normal legalese loophole. They don't sell or rent your data, but they share it free-of-charge with 10k of their favourite corporate friends who, in a completely unrelated transaction, have sent Tesla money for some reason or another.

I see, we can solve the problem of excess verbosity by duplicating our API surface ;)

Jokes aside, that's not the worst idea (you often see the stdlib do something in a similar vein with managed vs unmanaged data structures), but I bet it doesn't survive contact with real-world programmers well enough to actually provide the portability that normal Zig code has. For transitive "style" impositions, it only takes a low rate of non-compliance for the perceived benefit to disappear.

If that's a goal you have (and IME most code is lightning fast to write, with all the heavy lifting going to impedence mismatches like the one being described, so I tend to be happy to write a bit of extra boilerplate (I like Zig, but it's an absurdly verbose language) if it means the hairier integration points will go more smoothly, and I therefore do have that goal) then the allocator API empirically works, the other solutions I've seen work much less, and I'd want to have a pretty good idea of why a contender would sate my needs instead.

If that's not a goal you have, you do you man. I can shovel out sealed Scala classes or unmaintainable numpy with the best of them as the situation demands. Nobody's created "the best" language yet. We're just casually discussing tradeoffs.

The fires/mile ratio seems like a good idea (skewed a bit by relative driving habits of professional vs typical drivers). It turns out those numbers are all pretty readily available. All miles from all sources (including semis) tally to 3.3T/yr. All car fires from all sources (including crashes, so in the context of semis spontaneously combusting these numbers will make the 1/100 rate look even better than it should be, though separate sources indicate that most car fires aren't from collisions, so that's perhaps a small effect) total to 210k/yr. You then find that, smoothing out all underlying subgroups and data, there's a fire every 15.5M miles.

Applied to residential apartments, there's an average miles per year of 14k or so (should be less here than average based on anecdata, high fuel prices discouraging driving, and everything being close even if you do drive and usually close enough to be walkable, but let's assume 14k/yr is a reasonable baseline), giving us a fire every 1100 vehicles, not every 100.

1/1k is more plausible to me (still "feels" high, but it doesn't trigger the baseline absurdity checks I have in the back of my mind). 1/100 suggests that every year in uni one of my classmates should've had their car burn down. 1/100 suggests that every year my hometown newspaper should report 30 cars burning down -- one every week or two (and given that the newspaper covers the entire county it should actually be 3/week). It's a pretty high rate. The typical person knows hundreds of people well enough that a car fire would often crop up in conversation eventually, and I don't think the typical person knows anyone whose car caught fire. Elaborating on that, I don't think the typical person doesn't know somebody whose car caught fire _ever_, much less in the last year.

That gets into an idea I've been pretty adamant about. People say that capitalism is the worst system except for all the others, but its actual property is that it's inevitable. Money (power) can be used to gain more power. If even a few people choose to do so, if not countered intentionally by some outside force, wealth and power will accumulate.

Whether you see that as good or bad or something which needs to be checked and controlled is a separate discussion, but it's an obvious and expected result.

For some other unscientific findings, that'd suggest 5 vehicle fires per year just from residents of my apartment complex. I've seen 1 in 8 years, and that was arson.

They're orthogonal concepts. Zig hasn't done this, but you could absolutely combine injected allocators and automatic destructors in the same language if you wanted.

The bigger design point is who's responsible for knowing where the object lives. Zig has a balance of power more in favour of the caller than the callee, a point I tend to agree with since it's quite easy for a caller to know exactly what they want done and quite hard for a callee to know what all possible callers might want done. That principle is applied pretty liberally through the rest of the language.

Allocators help solve the problem of "this code I want to use is almost good enough; how do I actually use it?"

I distinctly remember one of my first "real" jobs, somebody had written a C# library for GraphQL. It had some sort of bug or lack of functionality I had to fix. The author had fallen hook, line, and sinker for sealed classes and all that nonsense, so the shortest path to using the rest of their code was to fork the library and re-write the thousand offending lines and all references thereto. Luckily it wasn't a deep dependency.

Contrast that with similar issues in typical Python. The library likely accepts my favourite duck-typed solution, if it doesn't then I can likely work around it with an appropriate choice of dunder methods in the code I have interacting with the library, and if it still doesn't yield then I can just rewrite (monkey-patch) the offending code at runtime.

Not that either of those scenarios are objectively optimal, but they illustrate one of the principles people have in mind when they use an interface like allocators (not the only one, I'm sure other commentors will talk your ear off), that when push comes to shove you'd prefer to be able to use your existing code to solve your new problems. And that does empirically mostly work here; you can use nearly the entire Zig stdlib (especially when ignoring things like the posix namespace) and most of the rest of the ecosystem as well on embedded devices, in WASM, in bounded-memory applications, in generic application code, in fast-running CLI apps not even bothering to free, etc.

I agree with much of your discussion about arenas by the way. They're a moderately poor fit for the current interface in Zig, largely because the free functionality is questionable at best. IME, most uses of arenas actually know they need such a thing. Functions taking allocator arguments and expecting the allocator to be an arena should take an arena argument. When using arenas for lifetime management, something should probably own that arena rather than implicitly assuming whatever gets passed through the stack is correct. Passing arenas to arbitrary functions expecting general-purpose allocators is prone to leaks, and you'd be better off using the arena (or a buffer created therefrom) as a backing allocator for a data structure capable of actually freeing if you can't trust the implementation you're calling into (and if you can trust it, they should expose a better API allowing you to detect that trustability at the callsite).

That doesn't sound right. Previous results proved that with bounded values you couldn't beat O(nlogn), among other things. The OpenAI result explicitly used arbitrary-precision complex arithmetic. Yes, it's galactic [0], but either it's wrong or the previous results were wrong, no?

[0] Very much not something I care much about in these sorts of conversations. Even if it weren't galactic, a random logn factor here and there usually loses to cache efficiency and whatnot. Their speedups were less than that, and I'd already assumed we were in the realm of applied math rather than real engineering.

Double-checking, is this more like the recent DFT improvement where even the word-RAM model of computation doesn't justify the fraction of a log factor they eliminated because of an assumption of arbitrary-precision arithmetic, or has ETH actually fallen with the Lean proof being formulated appropriately? Do we know yet?

Zinc would've worked too, I might have clipped the corner off some pennies or something. Magnesium works too though, and I definitely had access to magnesium. It was awhile ago though, so I'm not sure what I did.

I would've loved that as a kid. For that matter, I did actually fill some balloons with hydrogen using vinegar and something (might've cut some magnesium off one of those primitive fire starters, or I might've used a weaker metal, can't quite remember). I think I used the glass tube Costco used to use as a vanilla bean container to strap the balloon onto.

These are trained on a heavily doctored version of the public internet. The public internet has plenty of undocumented, uncommented data exfiltration mechanisms hiding in the middle of otherwise normal text or code. I don't think this is that surprising?

> why?

>> 50x faster switching

It's hard to say which applications will benefit the most, but orders of magnitude improvement tend to enable qualitative shifts downstream.

Not to mention, 1000x is just the cost right now while the tech is new.

Come now, Windows Terminal can execute your commands in less than a weekend ;)

Ah, I see. IMO the other response [0] I gave is probably the closest to what I had in mind. Interestingly, retry very well might not be better, especially when measured on a pareto frontier including cost.

I have a reasonably strong prior that it should be better though. That comes from my observations that whenever I notice the difference in distribution the retry method is better (obvious sampling bias, but what kind of person ignores their own experiences). As a stronger piece of evidence and intuition, the entire goal of these systems is to reproduce a certain distribution. If that distribution says that you should use ripgrep 10x as often as you should use grep then that's a signal you probably don't want to throw away. Constrained decoding might very well do so and place them on even footing or skew 10x the other direction. Retry faithfully captures that original distribution. I'm skeptical of solutions which want to shy too far away from it (similarly with most applications of changing the model's temperature).

The more important point is just that they're different, so we should probably measure the impact.

[0] https://news.ycombinator.com/item?id=50245714

Schema-constrained is equivalent to token-level retry. It's not equivalent to retry of longer sequences.

The way it works is to disallow invalid next states, and getting backed into a corner is one way to think about one possible failure mode.

For a concrete example (happens less nowadays with bigger models, but it still happens, especially later into a context window), models hate long json strings. It's very easy to get a json output like

{"name": "Bob", "biography": "Bob is a fantastic builder, having ...

Critically, the ellipses terminate the JSON. With schema-constrained decoding, you _must_ eventually terminate that broken string, and it'll typically terminate it right after the ellipses. Basically, by the point you got to the first period the output was borked. You were backed into a corner. Retry as a strategy fixes that.

As another example failure mode that's a bit more subtle, you might have a set of "correct" tokens early on in the output which get the KV cache into a bit of a wonky state, causing it to have worse outputs toward the end of your output. Disallowing invalid next states forces you to generate tokens in that worse-output state. Retry lets you fail more often and then hopefully not have those wonky-state early tokens. It's not really that you were backed into a bad state as a hard rule, but that you were backed into a bad state as a probabilistic statement.

For a toy model to think about, suppose the entire grammar is [ab, ba], and the LLM's universe of training data is [ab, ab, ba, bb]. The "right" distribution (retry on failure) is {ab: 67%, ba: 33%}. The schema-constrained distribution is {ab: 50%, ba: 50%}.