SimonD

To answer this question, I thought I'd put it to Claude, using Sonnet 5 and this is the explanation 😁: Good instinct to probe deeper — the "logic vs pattern matching" framing is close, but it's worth untangling because there's actually a common conflation happening in how people talk about this. The big one: "reasoning models" (like OpenAI's o-series, DeepSeek R1, or Claude with extended thinking) are still generative models. They're the same transformer architecture, doing the same thing under the hood — predicting the next token based on learned statistical patterns. There's no logic engine, symbolic rule-checker, or formal proof system bolted on. So it's not really "reasoning vs. generative" as two separate categories — reasoning models are a subset of generative models, trained and used differently. Where the real differences live: 1. Training objective. Standard generative/instruct models are trained mostly via next-token prediction on huge text corpora, then fine-tuned to be helpful and follow instructions. Reasoning models add another stage: reinforcement learning on tasks with verifiable answers — math problems, code that either passes tests or doesn't, logic puzzles. Because the reward signal is "did you get the right answer," the model gets pushed toward generating long chains of intermediate steps that make correct answers more likely — things like trying an approach, checking it, backtracking, trying another approach. 2. Inference-time behavior. A standard generative model maps input to output in roughly fixed compute — one pass, token by token, no deliberation step. A reasoning model spends variable extra compute before answering, generating a chain of thought that's often much longer than the final answer. This is often called "test-time compute" — you're trading latency and cost for accuracy on hard problems. 3. What's actually emerging is learned deliberation, not logic. The self-correction and step-by-step structure you see in a reasoning model's output are patterns the model learned statistically pay off on verifiable tasks — not the result of a discrete symbolic reasoning process. It's still fundamentally pattern completion; it's just learned to imitate and refine the pattern of "working through a problem carefully," because that pattern correlates with getting rewarded. 4. Where each shines. Reasoning models pull ahead specifically on tasks where there's a checkable ground truth — math, code, formal logic, some kinds of planning — because that's where the RL signal exists. On open-ended, subjective, or creative tasks (write me a poem, what's a good gift for my friend), the extra deliberation buys little, since there's no "correct answer" to verify against. 5. What genuinely didn't change. Neither type has guaranteed soundness. Both can hallucinate, make arithmetic slips, or confidently reason to a wrong conclusion — because underneath, it's still probability, not proof. If you want actual logical guarantees, you need to pair a model with an external tool: a code interpreter, a calculator, a formal theorem prover. That's a genuinely different paradigm — classical symbolic AI (expert systems, SAT solvers, planners) — which really does manipulate symbols with explicit rules and can guarantee correctness within its formal system. That's probably the sharper "fundamental" divide you're sensing: not reasoning-LLM vs. generative-LLM, but learned-statistical-generation (even when it looks like reasoning) vs. rule-based-symbolic-computation. If it's useful, I could sketch a quick diagram contrasting the training/inference pipelines of the two approaches — let me know. Both paths share the same foundation — the same pretraining, learning the statistics of language from huge amounts of text. They only diverge afterward. The left branch is the familiar path: instruction tuning to make the model helpful and well-behaved, then inference in one fixed-length pass — you send a prompt, tokens come out, done. The right branch adds a stage: reinforcement learning where the model is rewarded specifically for landing on verifiable correct answers (math, code, logic). That training pressure is what produces the "reasoning" behavior — and it shows up at inference time as a different mode entirely: the model generates a long chain of thought, checking and revising itself, spending variable compute depending on how hard the problem seems, before committing to an answer. The thing worth sitting with: nothing in that right branch is a different kind of computation. It's the same token-by-token generation, just shaped by training to produce a "let me work through this" pattern because that pattern got rewarded. That's why reasoning models can still confidently reason their way to a wrong answer — there's no proof-checker in the loop, just a learned habit of deliberating that usually, but not always, tracks truth. Q. What is it that makes one model better at something like coding versus problem solving complex questions A few genuinely separate factors are stacked together here — it's not one lever, it's several: 1. How verifiable the reward signal is during training. This is probably the biggest one. Code has a built-in ground truth: does it compile, do the tests pass, does the output match. That's a clean, dense, automatic reward signal you can run at scale — write code, execute it, get a binary pass/fail, no human needed. Complex problem-solving (say, an ambiguous business strategy question, or a multi-step logic puzzle without a single "correct" answer) often doesn't have that. Even math and formal logic, which do have checkable final answers, don't verify the intermediate steps — a model can get the right answer via a flawed argument and still get rewarded. So coding ability tends to improve faster and more reliably under RL because the feedback loop is tighter and harder to game. 2. Data availability and density. GitHub alone provides enormous volumes of code paired with tests, comments, commit messages, and bug fixes — a rich signal for "this code was wrong, here's the fix." There's no equivalent firehose of "here's a flawed argument, here's the corrected reasoning" at that scale for general problem-solving. 3. Structure vs ambiguity. Code has strict syntax and (mostly) unambiguous semantics — a function either does what the spec says or it doesn't. Complex reasoning questions are often underdetermined — multiple defensible answers, judgment calls, incomplete information. Models trained hard on code get very good at satisfying a tight spec; that skill doesn't transfer cleanly to open-ended judgment. 4. Tool access changes the game. For coding, a model can be hooked up to an actual interpreter or execution sandbox, run its own code, see the error, and fix it — an external, ground-truth feedback loop at inference time, not just training time. For most "complex problem solving," there's no equivalent oracle to consult mid-answer, so the model is stuck relying on its own internal check, which is much less reliable. 5. What gets optimized gets improved. Labs benchmark heavily on things like coding benchmarks (SWE-bench, HumanEval) because they're measurable and commercially important. Effort follows measurability — so coding has had disproportionate optimization attention relative to fuzzier reasoning domains that are harder to even define "correct" for. The upshot: it's less "this model is smarter" and more "this domain gave the training process a cleaner signal to learn from." A model can be excellent at code and mediocre at ambiguous judgment calls precisely because one of those had a built-in answer key and the other didn't. There you go, hope that helps 😁

Nothing massively exciting really. It's all down to the reasoning side. As you know I've built Open Heat Loss which has morphed into a full blown project management tool and even materials & quote system now and actually now that the calcs in the tool have been largely completed it's run of the mill development. But, I do some fairly tricky heat pump retrofit designs and installations so I've been building a suite of dynamic modelling tools to understand how the systems will work over time - so I use it to reason through the questions and put together a brief for the tool I want to build and usually build the first iteration to play with it. For example, I recently completed the design for a system for an older house that's on a hill so one side has massively thick stone walls adjacent to ground with no insulation, but the other side is a complete wall of glass facing south and there's ufh throughout. I wanted to model the control strategy for shoulder months to prevent over heating while taking into account the buffering capability of the walls, and then I wanted to model the most effective way to manage defrosts together with system open volume as the system has a pretty large heat pump. With the heat pump I'm using it can use the dhw cylinder by default for defrost, but because I'm plate loading the cylinder that's another control headache and because it's a system with rads and ufh, I can't reliably use the ufh as volume due to the behaviour of the mixing valve so a pure open-loop system isn't a viable strategy. Some of the control questions I'm asking fall on deaf ears in the manufacturer's tech department. The task was to arrive at a simple and effective design that uses both the passive and active components of the system to their best effect opposed to the industry fall backs which are either run fully open-loop or just put in a buffer. And out of this process I arrive at ideas for simple software tools all heating engineers ask frequent questions about and go from there. And like with all these AI models, whether reasoning or generative, when they touch real-world scenarios even using relatively basic physics, they get themselves into a proper bind. I've only used Fable a little bit as the other models can cope with most stuff as although Opus has improved massively, I used to find that it could get hung up on a random constant or variable, or some other context based issue. And sometimes it just couldn't understand how to get from a to b, so I ended up with an output that didn't fit. I've also had a few instances where it's come back and said that what we're looking at is beyond its training cutoff - honest but slightly frustrating.

Ah, yes okay. I think the odds are that's the way it'll go probably and it could be a good thing.

I'm sure it is and I bet it also depends on the tasks, but I think Claude is pretty good. Today I've use 6% of my weekly total and 8% of my Fable - and that's dealt with some fairly complex reasoning rather than coding itself. I can keep tabs - but maybe that was different with chat? TBH I think what I get for my subscription is pretty good - I've hit my paywall only a couple of times but then in fairness I'm usually due a break anyway so I consider it a health check 😊. I doubt they'll offer it for free, even if it would be amazing if they did.

Interesting, I was looking at my usage stats and despite doing some fairly heavy work - I've only used about 25% of my weekly limit. What I did notice though is that I was using Sonnet 5 for the thinking and generating promps but in VSCode I was still on Opus, so I wonder whether that has got anything to do with it? What's interesting is that on Claude website about choosing model it says that Opus uses more of your rate limit but in VSCode Claude Code model selection, it says that Opus gets 2 x Sonnet usage. A bit confusing really. I'm going to give all of the models a little try but I don't think I've got anything complex enough to really test Fable right now. But maybe I'll think of something for my free Fable trial expires.

You're not feeling lonely are you? I've been away and then just too busy with other distractions! I think I might have hinted at this one a while ago, but you were single track on ChatGPT plus a few other local models to listen at the time. Where have you been? 😉 All looks (expletive deleted)ing awesome I have to say. I've just been sorting the workflow with Claude Sonnet 5 and then Claude Code and now I'm genuinely not having to look at code any more either, just copy & paste the prompts and off we go. Did 2 days of coding and not a single bug from the new code - it just highlighted bugs in the existing code, but solved so easily, even if Claude did tie itself in knots because it forgot to read and obey my dev principles instructions - but it realised and apologised for this.. It continuously blows me away. I'm beginning to create a list of ideas for things to build, but Claude code then tells me off for not staying focused on what we're doing. I get it. I've spent my life doing what others thought were stupid projects just because I thought they'd be interesting and fun and I wanted to see where they'd take me. No need for any other reason IMHO.

I didn't say that it didn't. It's just that science has to recognise when the lense through which it is looking is inadequate - which is part of the philosophy of science. Saying that reductionism always yields the truth ignores the fact that a single component can be quite different when it is viewed in isolation as a constituent part compared to when it is in dynamic relation to many other, different, dynamic constituent parts. Therefore, what you claim to be truth or even real, from one perspective isn't from the other.

But the existence of Cargo Cult Science doesn't prove anything about environmental change, nor whether the science is right, or going in the right or wrong direction. Here's another physicist's perspective, which doesn't question the underlying science (but she does regularly question a lot about the current world of physics and science):

No, it isn't. It's based in complexity, which physics seriously struggles with and the reductionist approach it has long held so dear really doesn't cope. This typical reductionism is exactly mirrored by your claim that it's based on basic physics and fundamental components - but the behaviours of the systems are based on their complex and dynamic relations. But, you've also kind of proved my point - you're making a statement that one small fraction of science is true science which indicates to me a misunderstanding of the scientific method and the philosophy of science itself. Science is actually about continually questioning whether what we think as true is really true and so moving forwards and that by definition this also involves questioning the basis upon which we think we know something. That is the scientific method.

I think you're flying a bit close to the wind here. You said you studied the philosophy of science? This includes epistemology and ontology - there is not just one narrow fixed definition of these, which is what you seem to be suggesting. But also the philosophy of science is about exploring the relationship between science and what we consider to be truth, and certainly not anything like that certain sciences are real - which implies they have exclusivity over what is true, which of course they don't, it would be pretty naive and ignorant to suggest they did. 😉 I'd also suggest that being fixed about what is real, is pretty non-scientific to begin with and ignores the very important metaphysical component inherent the philosophy of science. 😉

It depends on whether you're looking to rely on them or not. The problem with temp gauges at the manifold is that the return one will show a combined return temp from all loops so you don't know if your individual loops are running at the correct dT. The flow one is okay, but personally I have a mixture of clip on k-type used with a digital thermometer and some bluetooth ones that provide datalogging back to a specific app - at least for commissioning and maintenance use - so each loop can be properly balanced.

TBH, I think the article by Evan Davis was pretty fairly balanced, and the BBC the other BBC one is slightly cheaky as it doesn't properly go into why the ECO4 grant was amended. The reality is that if the heat pump is going in as a retrofit, the overall costs of the system are very high - and no, unlike many incorrect claims here on this forum, this is not purely down to grant harvesting. But figures like Dale Vince aren't helping by saying things like heat pumps don't work like they say they do, as he did in an interview yesterday, doesn't help at all. These are the kinds of statements that need clarifying, but just like the whole Net Zero thing, the general and popular coverage is fairly toxic and I have to say the industry isn't helping itself greatly right now.

I was driving through France twice last week and on one of the journeys the exterior temperature was shown as 41C - the a/c in the van couldn't cope and it was just getting hotter and hotter inside but it was a shock to the system to get out on a quick break.

Keeps on coming back to this doesn't it? Domain knowledge is first key, second is then how to translate that into useful prompts. I was playing with DeepSeek this morning and pretty blown away by how far it's come in a few months. It was fascinating that after inputing some questions, I explained I had domain knowledge and it they said that totally changed the situation and provided a much more complex and deep answer that someone without the knowledge or experience wouldn't understand. It's crazy this. I now want to go explore the smaller, more efficient models that are designed for particular tasks as that really seems like the way to go.

Loads of installs still use an s-plan setup and manufacturers still provide schematics for this with a bypass for over-run with both valves closed. 🤷‍♂️