The study is supposed to measure how clearing up pollution in London improved children's lung function. The decrease in London was meaningful — NO2 fell about 22%. But particulates fell faster in Luton and NO2 in London is still roughly double Luton's. The gap is larger than the decrease.

By 2022 both cohorts get the same results on blow tests. But how does this happen if we believe that the study's dose-response model is true?

Put another way, if the change in London NO2 is so crucial, how come it doesn't matter that the absolute value is still double Luton's?

For an EPYC with a 5090 (no layers on CPU) vs an M3 max 128GB, qwen 3.6 27B at 128k context / 7k generation:

                Cold: prefill + decode    Hot (KV cached)
  5090          40s  + 2-3m  = 3-4 min    2-3 min
  M3 Max 128GB  14m  + 8-10m = 22-25 min  8-10 min

They're both good value (or crazy expensive) depending on how you look at it.

It depends how you price the ability to run a particular model at all, vs run the model quickly and serve several parallel streams.

From my perspective what I always loved about "the profession" was a relative LACK of gatekeeping. I loved offensive security for the same reason, there was a long run where you really just needed to be able to hack, and if you could demonstrate that there was a job for you somewhere (for better or worse).

Keeping the industry in its current form frozen in amber would be as weird as, I don't know, keeping horses & carriages in business by regulating scarcity of motor vehicle licenses. Not a great analogy but hopefully you see what I mean.

Apparently I can pay for partial solutions to the Riemann hypothesis but if my question involves a crackme or something that is an existential risk somehow.

For this genre of task execution can run with limited horizon and is independent but would be too expensive to do with "us frontier tokens", I think for these, there is value in availability of cheaper tokens.

I'm not sure from your description if you control the geometry of the sensor part (i.e, can the clamp be integral to the sensor housing or does it need to be a separate part) also ignores the internals, etc etc.

One thing I noticed is that off the bat, it did think about the assembly in general terms but would need guidance to think harder about FDM limitations and layer orientation etc. These are not good designs for printing. A good dev loop and git history help with these kinds of revisions.

The general principle is that if your domain is verifiable at all, give the model tools and a workflow that constrain and check its output. You want the LLM arguing with the geometry kernel instead of you.

To fully close the loop you print parts as fast and possible and concretely see where they suck.

Recommend doing this in a coding harness not a chat box.

The reason I think you might have more success with this is that the model is mostly thinking about the part in words, which it can convert to a part design in CAD in code. LLMs are really good at coding. Also means it can use relative positioning and relationships.

You will be able to iterate more easily, compare things, compute properties, commit to git etc. The process is more reproducible and steerable than generative production of images.

When the LLM can look at renders of the geometry it generated, it’s easier for it to discriminate when it’s producing nonsense like misaligned parts, things that don’t fit, etc. It’s still going to kind of suck, but it will be better. The whole process of code -> render -> inspect forces the model to put up or shut up and provides grounding. Meshes > bloviating.

As far as I know today's LLMs don't have a "visual imagination" but a process like this could be a slow approximation of one. They clearly do have SOME spatial understanding (pelican tests show us that!) but it feels really non-human.

One thing missing from this is kinesthetics. Personally I am mostly not thinking in accurate visuals in mechanical design. I am imagining how the parts feel and kind of how they move and what slips first and what bends and what feels heavy. Imagining what my hands would feel. But I don't think I trust LLMs to evaluate that stuff by writing simulation code yet.

The others suffered "ecosystem collapse". With Oxide you won't be stuck on a "burning platform", your main risk is that the value prop for the hardware & management experience doesn't play out.

This is the same idea as switching power supplies but planes had to solve that before power semiconductors were cheap enough.

The power frequency also has an impact on the size of all the induction motors.

I guess if you were designing it from scratch today you would let the generator produce power at whatever frequency the mechanical engineers tell you they want to and the power electronics could convert it without problems. You would do the same thing the other way around on the motors.

The "halting problem is unsolvable" argument relies on the oracle not being able to output "not sure". But adding that option admits trivial oracles, like ones which output "not sure" for everything, so some are better than others.

The "real world" use most people have for halting oracles is as part of software safety, where if the checker outputs "not sure" you modify the software until the checker can decide if it halts.

All we need now is some sort of program to evaluate halting problem oracles...

There is some difference; when you install WordPress or Ghost, your problems are shared. There's a community that goes along with the software and a "shared understanding in the world" of how it works and where the rough edges and limitations are. A lot of the time, LLMs will actually be better at modifying WordPress or Ghost to do what you want than they will be at fixing the CMS you built last Tuesday.

When you custom build, you can get an exact fit for your needs but your misery is yours alone.

If you don't have a useful mental model of the architecture that's a communication / review / documentation problem, not a problem with the entire idea of codegen.