I think I have an observation that defies the info on that page. That page was written around the time that STEVE (an aurora related phenomenon) was first named. https://en.wikipedia.org/wiki/STEVE
I mention this because in the 1990s, while at uni in St Andrews, Scotland, I remember a trip to the astronomy observatory one evening. There was a peculiar cloud overhead - whitish purple, tube shaped and shimmering. I asked the astro professor what it was. He said, "Its a cloud" and showed no further interest. I took a photo. When I got the film developed and photos printed, you could see bright colours either side of the tube. I've always wondered a) what it was and b) why that astronomy professor was an astronomy professor when he had no interest in what the universe had to reveal to him.
I now believe it to have been a STEVE. I've still got no insight into the mind of the astro professor.
I suppose you get into astronomy because you're interested in outer space. Your question is like asking a soil scientist about something you found on a pavement.
I'd have no idea how to find him. But I think it'd be a fruitless task anyway. I'm sure they'd have no memory of what, to them, was a moment as mundane as any other that day. I've definitely had people recount a shared experience to me, reminiscing about how profound it was, and me having no idea what they're talking about.
> seems like x86 and the major 8bit cpu's had the same speed, pondering in this might be a remnant from the 4-bit ALU times.
I think that era of CPUs used a single circuit capable of doing add, sub, xor etc. They'd have 8 of them and the signals propagate through them in a row. I think this page explains the situation on the 6502: https://c74project.com/card-b-alu-cu/
For a few years I worked in the team that wrote software for an embedded audio DSP. The power draw to do something was normally more important than the speed. Eg when decoding MP3 or SBC you probably had enough MIPS to keep up with the stream rate, so the main thing the customers cared about was battery life. Mostly the techniques to optimize for speed were the same as those for power. But I remember being told that add/sub used less power than multiply even though both were single cycle. And that for loops with fewer than 16 instructions used less power because there was a simple 16 instruction program memory cache that saved the energy required to fetch instructions from RAM or ROM. (The RAM and ROM access was generally single cycle too).
Nowadays, I expect optimizations that minimize energy consumption are an important target for LLM hosts.
Sibling posted a good example. But I know of (without details) things where you have to insert nops to keep peak power down, so the system doesn't brown out (in my experience, the 68hc11 won't take conditional branches if the power supply voltage dips too far; but I didn't work around that, I just made sure to use fresh batteries when my code started acting up). Especially during early boot.
Apple got in a lot of trouble for reducing peak power without telling people, to avoid overloading dying batteries.
> A spec is an envelope that contains all programs that comply. Creating this spec is often going to be harder than writing a single compliant program.
This perfectly explains the feeling I had when, 20 years into my career, I had to start writing specs. I could never quite put my finger on why it was harder than coding. My greater familiarity with coding didn't seem a sufficient explanation.
When writing a line of spec, I had to consider how it might be interpreted in the context of different implementations of other lines of spec - combinatorial nightmare.
But code is just a spec as far as, say, a C compiler is concerned. The compiler is free to implement the assembly however it likes. Writing that spec is definitely easier than writing the assembly (Fred Brookes said this, so it must be true).
C has a simpler mapping to assembly than most languages, so you are doing most of the high level translation when writing C. But even C compilers have considerable scope for weirdness, hence projects like CompCert.
But much of the code we run today is JIT executed, and that leaves ample room for exploiting with weird machines. Eg the TOCTOU in the Corina exploit.
Even at this very low level, full coverage specs require years of careful formal methods work. We have no hope of doing it at for vibe coding, everything will be iterative, and if TDD helps then good, but specs are by no means easier than code.
> But code is just a spec as far as, say, a C compiler is concerned. The compiler is free to implement the assembly however it likes.
Not at all. Code is formal, and going from C to assembly os deterministic. While the rules may be complex, they are still rules, and the compiler can’t stray away from them.
Writing C code is easier than writing assembly because it’s an easier notation for thinking. It’s like when hammering a nail. Doing it with a rock is hard. But using a hammer is better. You’re still hitting the nail with a hard surface, but the handle, which is more suitable for a human hand, makes the process easier.
So programming languages are not about the machine performance, they are about easier reasoning. And good programmers can get you to a level above that with proper abstraction and architecture, and give you concepts that directly map to the problem space (Gui frameworks instead of directly rendering to a framebuffer, OS syscall instead of messing with hardware,…).
> Code is formal, and going from C to assembly is deterministic.
OK, this is the main thing. Going from C to assembly is not deterministic in a sense because different compilers can produce different output. But the behaviour of the generated assembly is always the same. This isn't true of a spec.
Why is this a weird definition of determinism? Could you please define what you mean when you say deterministic?
A C program does not identify a single assembly program. It identifies a set of assembly programs. This fits the pretty standard definition of non-determinism.
A difference between natural language and C code is that natural language does not have a formal semantics. Having no formal semantics is a very different problem from having a semantics that admits a well-defined set of interpretations.
Determinism implies that the same input will result in the same output.
I agree with you that for a single C program there’s a set of assembly code that satisfies it. But by choosing a compiler, an architecture and a set of flags,… you will always get the same assembly code. If you decide to randomize them, then you can no longer guarantee a specific result, but you can still guarantee sets of result. Which is the definition of non-determinism.
Formalism is orthogonal as its about having well defined sets and transformation. LLMs are formal because it’s a finite set of weights and tokens ad the operations are well defined. But the prompt -> tokens -> tokens -> code transformation is non- deterministic in most tools (claude, chatgpt). And the relation between the input and the output os a mathematical one, not a semantic one.
I see. Then we’re on the same page. My follow up question is: why do we care if the LLM is deterministic?
Hypothetically, if we could guarantee a semantic relationship between the input and output we wouldn’t care if the LLM was deterministic. For instance, if I give the LLM a lean theorem and it instantiates a program and a mechanical proof that the program conforms to the lean theorem, I just don’t care about determinism. Edit: this is equivalent to me not caring very much about which particular conformant C compiler I pick
And my understanding of LLMs is that they actually are functions and the observed randomness is an artifact of how we use them. If you had the weights and the hardware, you could run the frontier models deterministically. But I don’t think you’d be satisfied even if you could do that. Edit: this is maybe analogous to picking a particular C compiler that does not promise conformance
There are valid concerns with LLMs but I’m not convinced non-determinism is the thing we should care about.
Non-determinism is not what people really care about.
If you remove randomness (temperature) from an LLM, It's going to be deterministic. But the relation between inputs and outputs is inscrutable (too many parameters) and there's no practical way prove the relation between a certain prompt and the output unless you run it.
Then you add randomness on top of that and the whole thing is a chaotic mess. Due to being formal, I believe generated code has a high probability of being correct (syntax) and generic patterns can be replicated easily. But the higher level concerns (the domain) and the nebulous concepts like maintainability, security,... is harder to replicate. Also correctness (logic) is hard to prove as you're unfamiliar with the code.
So do you disagree with the parent that “code is just a spec as far as the C compiler is concerned”?
Maybe it’s important to agree on what a spec is. For instance, do you agree that a spec can be just as formal as code implementing the spec? For instance, if the spec is written in a machine parseable logic do you take that to be a spec? Or are you taking a spec to be written in natural language?
I suspect some of your disagreement with the parent is about this definition. I’m just trying to understand because for me it’s uncontroversial to claim C code is a spec for assembly code, but maybe the issue is that I am not thinking of specs in the colloquial way.
The abstract begins, "Growing evidence supports early eating to control appetite and energy balance". What does that mean? My unskilled reading of it is that there is recent evidence that eating breakfast helps with weight loss. But I'm confused because there was a 2019 meta-analysis that found that eating breakfast does NOT help with weight loss. https://www.bmj.com/content/364/bmj.l42
You might want to read the rest of the studies - or at least try to no misrepresent before commenting. There are elementary differences in the studies.
Study 1: "What to Eat", Specific Demographics, Primary Clinical Trial, Mechanistic/Physiological Outcome, Conclusion: High-Protein breakfast is superior for suppressing appetite and maintaining satiety, while a High-Fiber breakfast promotes better weight loss and a healthier gut microbiome,
Study 2: Whether to Eat, Broad Demographics, Systematic Review (meta analysis), Broad Clinical Outcomes, Conclusion: eating breakfast increases total daily energy intake compared to skipping it, and that skipping breakfast resulted in slightly greater weight loss.
I wasn't comparing the two studies. I was just asking what the first sentence of the abstract of study 1 meant when it appears to be a false statement given study 2's result. Usually this is because I don't understand something and someone around here explains what I'm missing.
Even on a specific STM microcontroller (STM32G031), the LLM tools invent non-existent registers and then apologize when I point it out. And conversely, they write code for an entire algorithm (CRC, for example) when hardware support already exists on the chip.
Think of "What opcode has the value 0x3c on the Intel 8048" as a PNG image but the LLM like a very compressed JPEG. It will only get a very approximate answer. But you can give it explicit tools to look up things.
In the UK the wholesale price was about £80/MWh in 2025. The retail price was about £270/MWh + a standing charge. If you factor in the standing charge, an average user paid about £344/MWh. So the cost of generation was only about 23% of the retail price. I believe the green levies + CfDs accounted for about another 15% of the retail price.
Does this mean that if generation was free, and there were no green policy costs, our electric would still be expensive?
edit: "Network and Distribution" appears to contribute about 23% of the retail price. I guess green energy increased that cost because wind/solar are more spread out and sometimes off-shore.
We're seeing this galaxy as it was 280 million years after the Big Bang. But the universe didn't become transparent to photons until 100 million years after that (https://en.wikipedia.org/wiki/Recombination_(cosmology)). So that's impossible. Who's wrong, Recombination theory or this paper?
Yep, I think it is. The point is there's almost no history of oral peptides, other than stomachs destroying them.
FTA: "So to summarize the state of the art in oral peptide delivery: there are exactly two FDA-approved products that use permeation enhancers to get peptides into your bloodstream through your GI tract. Both achieve sub-1% bioavailability. Both required over a decade of development, thousands of clinical trial participants, and hundreds of millions of dollars."
Would a sublingual dose be possible/more effective? Research in other (um, yeah, medicinal!) compounds shows that it can be an effective pathway to the bloodstream rather than trying to survive the digestive system.
Sublingual is even harder. The sublingual mucosa is thin but selective. It strongly favors molecules that are small, lipophilic and uncharged. Semaglutide is about 8-10x too big, highly polar and charged.
Injection is really the only method with any substantial bioavailability. BUT, low (<1%) bioavailability does not necessarily mean useless.
If the drug has a relatively low marginal cost of production, and the stomach just breaks down 99% of it without side effects, you can just manufacture 100x more, give it orally, and eat the cost of the 99% that gets lost along the way.
Injectable Semaglutide/Tirzepatide (>99.8% pure) are currently sold at a profit from China for around $2-3/weekly dose. Rybelsus (oral semaglutide) is sold at roughly the same cost per milligram, even though it's made in FDA-approved facilities (you just need to take >= 40x more milligrams per month, bringing it to $1000/month in the USA)
So manufacturing oral doses 100x higher than injectable seems to be economically viable.
Ancedotal but it's really hard for me to do insufflation because of the discomfort. Of course if my life depended on it I could probably do it but otherwise I'd rather not.
Thank you, your comment made me aware of this event I didn't know. [1] I have found at least one concrete evidence you assertion is correct [2]: The Dusseldorf Agreement of March 16, 1939.
> The British historian Martin Gilbert believes that "many non-Jews resented the round-up", his opinion being supported by German witness Dr. Arthur Flehinger who recalls seeing "people crying while watching from behind their curtains". Rolf Dessauer recalls how a neighbor came forward and restored a portrait of Paul Ehrlich that had been "slashed to ribbons" by the Sturmabteilung. "He wanted it to be known that not all Germans supported Kristallnacht."
This passage is particulary eerie IMHO, since I've been reading "I don't condone this" of current world events over and over.
> In 1938, just after Kristallnacht, the psychologist Michael Müller-Claudius interviewed 41 randomly selected Nazi Party members on their attitudes towards racial persecution. Of the interviewed party members, 63% expressed extreme indignation against it, 5% expressed approval, and the remaining 32% were noncommittal.
Also particurlarly eerie to me. Yet the regime went on.
I mention this because in the 1990s, while at uni in St Andrews, Scotland, I remember a trip to the astronomy observatory one evening. There was a peculiar cloud overhead - whitish purple, tube shaped and shimmering. I asked the astro professor what it was. He said, "Its a cloud" and showed no further interest. I took a photo. When I got the film developed and photos printed, you could see bright colours either side of the tube. I've always wondered a) what it was and b) why that astronomy professor was an astronomy professor when he had no interest in what the universe had to reveal to him.
I now believe it to have been a STEVE. I've still got no insight into the mind of the astro professor.