Modern LLMs, just like everyone reading this, will instead reach for a calculator to perform such tasks. I can't do that in my head either, but a python script can so that's what any tool-using LLM will (and should) do.
Long multiplication is a trivial form of reasoning that is taught at elementary level. Furthermore, the LLM isn't doing things "in its head" - the headline feature of GPT LLMs is attention across all previous tokens, all of its "thoughts" are on paper. That was Opus with extended reasoning, it had all the opportunity to get it right, but didn't. There are people who can quickly multiply such numbers in their head (I am not one of them).
I tried this with Claude - it has to be explicitly instructed to not make an external tool call, and it can get the right answer if asked to show its work long-form.
Mathematics is not the only kind of reasoning, so your conclusion is false. The human brain also has compartments for different types of activities. Why shouldn't an AI be able to use tools to augment its intelligence?
There are many examples of current limitations, but do you see a reason to think they are fundamental limitations? (I'm not saying they aren't, I'm curious what the evidence is for that.)
It's because of how transformers work, especially the fact that the output layer is a bunch of weights which we quite literally do a weighted random choice from. My hunch is that diffusion models would have a higher chance of doing real reasoning - or something like a latent space for reasoning.
Thinking that LLMs are intelligent arises from an incomplete understanding of how they work or, alternatively, having shareholders to keep happy.
Furthermore, the LLM isn't doing things "in its head" - the headline feature of GPT LLMs is attention across all previous tokens, all of its "thoughts" are on paper
LOL, talk about special pleading. Whatever it takes to reshape the argument into one you can win, I guess...
LLMs don't reason.
Let's see you do that multiplication in your head. Then, when you fail, we'll conclude you don't reason. Sound fair?
I can do it with a scratch pad. And I can also tell you when the calculation exceeds what I can do in my head and when I need a scratch pad. I can also check a long multiplication answer in my head (casting 9s, last digit etc.) and tell if there’s a mistake.
The LLMs also have access to a scratch pad. And importantly don’t know when they need to use it (as in, they will sometimes get long multiplication right if you ask them to show their work but if you don’t ask them to they will almost certainly get it wrong).
The context is the scratch pad. LLMs have perfect recall (ignoring "lost in the middle") across the entire context, unlike humans. LLMs "think on paper."
Plenty of humans can't do arithmetic. Can they also not reason.
Reasoning isn't a binary switch. It's a multidimensional continuum. AI can clearly reason to some extent even if it also clearly doesn't reason in the same way that a human would.
> Plenty of humans can't do arithmetic. Can they also not reason.
I just pointed out that this isn't valid reasoning ... it's a fallacy of denial of the antecedent. No one is arguing that because LLMs can't do arithmetic, therefore they can't reason. After all, zamalek said that he can't quickly multiply large numbers in his head, but he isn't saying that therefore he can't reason.
> Reasoning isn't a binary switch. It's a multidimensional continuum.
Indeed, and a lot of humans are very bad at it, as is clear from the comments I'm responding to.
> AI can clearly reason to some extent
The claim was about LLMs, not AI. This is like if someone said that chihuahuas are little and someone responded by saying that dogs are tall to some extent.
LLMs do not reason ... they do syntactic pattern matching. The appearance of reasoning is because of all the reasoning by humans that is implicit in the training data.
I've had this argument too many times ... it never goes anywhere. So I won't respond again ... over and out.
Indeed, and a lot of humans are very bad at it, as is clear from the comments I'm responding to.
This is your idea of "conversing curiously" and "editing out swipes," I suppose.
I've had this argument too many times ... it never goes anywhere. So I won't respond again ... over and out.
A real reasoning entity might pause for self-examination here. Maybe run its chain of thought for a few more iterations, or spend some tokens calling research tools. Just to probe the apparent mismatch between its own priors and those of "a lot of humans," most of whom are not, in fact, morons.
you’re just abstracting it away into this new “systems” definition
when someone says LLMs today they obviously mean software that does more than just text, if you want to be extra pedantic you can even say LLMs by themselves can’t even geenrate text since they are just model files if you don’t add them to a “system” that makes use of that model files, doh
I thought it might do better if I asked it to do long-form multiplication specifically rather than trying to vomit out an answer without any intermediate tokens. But surprisingly, I found it doesn't do much better.
Other comments indicate that asking it to do long multiplication does work, but the varying results makes sense: LLMs are probabilistic, you probably rolled an unlikely result.
Specifically, you need to use a reasoning model. Applying more test time compute is analogous to Kahneman's System 2 thinking, while directly taking the first output of an LLM is analogous to System 1.
This is true for solving difficult novel problems as well, with the addition of tools that an agent can use to research the problem autonomously.
I asked Gemini 3 Thinking to compute the multiplication "by hand." It showed its work and checked its answer by casting out nines and then by asking Python.
Sonnet 4.6 with Extended Thinking on also computed it correctly with the same prompt.
I can completely understand how you were driven away. If you ever want to give it a go again:
> there's "Flakes" which I never quite understood
Nix never clicked for me until I started using flakes. There's a lot of internal drama surrounding them that honestly childish; that's why they are marked as experimental and not the official recommendation. You are going to have a worse time with Nix if you go with the official recommendation, flakes are significantly more intuitive. The Determinate Systems installer enables them by default, and whatever documentation they have is on the happier path (except for FlakeHub, I haven't figured that one out yet).
On the most fundamental level, flakes allow you to take /etc/nixos/nixos.nix (or whatever, it has been forever) out of /etc and into a git repository. Old-style nix may be able to do that, but I discovered flakes before trying. I did previously attempt to use git on /etc/nix, but git was falling to pieces with bizarre ownership problems.
What this means is that I could install and completely configure a machine, once booted into a nix iso, by running: nixos-install --flake https://github.com/.../repo.git. I manage all of my system config out of /home/$user/$clone
As for /home there is home-manager and, again, you are not steered towards it (the tutorial pushes you towards nix profiles/nix-env instead). Home-manager will do for your home directory what the system config does for your system, and has many program modules. You can even declare home-level systemd units and whatnot.
> manually edited /etc files.
You can use environment.etc for these files[1]. systemd.tmpfiles can be used for things outside of etc. Home-manager has the equivalent for .config, .local, .cache. [2].
Yep, i am doing the same. I have a central remote flake repo where all my machines, services, etc are defined and they all run tweaked autoupdaters to periodically do full updates. I push commits and wait and forget. It feels like maintaining your distro everywhere, no matter where you ssh in. And soon, i will migrate that repo off a central platform (github) into radicle or something and turn some of my machines into seeders. Then, with offsite data backups, my house could burn down and github go dark, i could still recover, maybe in the future even bootstrap from my smartphone. A big step towards digital sovereignity.
the law is there because parents are fucking clueless unprincipled whining crybabies, who need a lot of support, and sometimes that includes a bit of pushing ...
or who knows what problem is this supposed to fix. orphans buying phones? kids buying secret phones behind their parents back?
> [Article] What works in GNOME might not work in KDE. What works in both might not work in Sway.
If you subtract GNOME from the set then things become a lot more sane. "Compositor-specific extensions" are really "everyone besides GNOME extensions." The system tray extension isn't KDE-specific. Sure, window positions might not be available at all (because they don't make sense for a TWM), or a user might not have a system tray bar (or you might be on GNOME). However, if they did have a system tray it would be the StatusNotifierItem protocol. Ideally, these should be handled like other platform features like accelerometers etc.. That may not be possible, either way a lot of them can safely noop.
> [Article] For Avalonia, this means "Wayland support" isn't one implementation, it's potentially dozens. We're not just writing a Wayland backend; we're writing a GNOME-Wayland backend, a KDE-Wayland backend, a Sway-Wayland backend,
If you're making per-WM backends then you've fundamentally misunderstood how extensions are supposed to work. Other Wayland client libraries do not have a independent backends for KDE, Sway, and GNOME. Maybe quirks would be needed because you're attempting to support an existing UI library - but those should be few and far between.
IIRC Avalonia supports Vulkan as a rendering backend? Wayland protocols are the same line of thinking as Vulkan extensions.
wlroot and smithay are good examples of what extensions are used in the real world.
My experience was the same while helping to adapt a Steam Deck game for wider Linux support. The issue wasn't Waylandisms, most of those have already by figured out. It was GNOME. Their preferred resolution to issues seems to be dropping support rather than bug fixes, and they go out of their way to adopt implementations that are against the momentum of the wider community. I can get why they make some of their decisions, but things like killing the tray indicator or server side decorations are insane. To be an outlier in name of a greater or grander goal is one thing, then there is whatever GNOME is doing.
Fwiw on Vulkan or GL it also often makes sense to implement entirely different code paths for different *sets* of supported extensions, instead of handling all possible extension combinations in a single code path (which leads to messy code and a combinatorial explosion of test cases, since each unique extension might theoretically be supported or unsupported independently from all other extensions - but you need to test each combination).
The whole idea of granular and independent extensions is pretty stupid across GL, Vulkan and Wayland. It makes more sense to have a handful "tiers" or "profiles" which guarantee a specific set of features (eg how all other 3D APIs do it) - e.g. Wayland should have a "desktop profile" instead of dozens of optional extensions needed for desktop scenarios, other profiles could be "mobile" and "kiosk".
Despite how much they would have you believe it, human rights are not a political issue. Politics are used to expand practiced rights (or abused to reduce them), just like politics are involved with providing you access to water.
This is just structured logging. Slog in go, tracing in rust, serilog in C#, etc. You should be combining this with the likes of otel or datadog, which will keep those fields structured and filterable.
> Let me calculate that. 729,278,429 × 2,969,842,939 = 2,165,878,555,365,498,631
Real answer is: https://www.wolframalpha.com/input?i=729278429*2969842939
> 2 165 842 392 930 662 831
Your example seems short enough to not pose a problem.
reply