Contemplating the AI delivering Number Theoretic Transforms

It's been a long time since last post, 2 years.
2 years ago, the LLM were just beginning to be interesting, but really far behind the human with all hallucinations and obvious mistakes.
Now, I have the clear feeling that I am far behind, as most humans probably are.

I just tested Claude Sonnet 5.5, the free version thru browser chat interface.
Not even the more powerful agentic harness (I haven't setup an MCP in my images yet).

I asked it to devise a large integer multiplication with number theoretic transform in Squeak Smalltalk.

It's been a matter of minutes to deliver

- a correct Squeak Smalltalk version working out of the box
- with quite compact code
- with a prime tuned for efficiently avoiding LargeInteger arithmetic in tight loops,
  at least in a 64 bits image (but wait, NTT in 32 bits is just too challenging)

Claude did choose a prime of 30 bits for obtaining that efficiency without me even asking with a 2-adicity of 2ˆ23, meaning that it can theoretically work with a decomposition of integers in up to 8 million limbs.

Claude did not hallucinate on that subject, and its sole mistake was using conform: in place of allSatisfy: when it provided a utility snippet for finding more good primes on my request (those leading to efficient implementation).
Not a real problem, if I had used an agent, it would have discovered by itself.
Claude could not point me to the source of confusion, except vaguely relating some squeak-dev threads from the early 2000. 
I later asked google (Gemini) which dialect implements conform: and it had the same hallucination about Squeak. When I objected to this it gave me a source of the mistake https://squeak.org/documentation/terse_guide/ a presumably trustable reference, so obviously the mistake has human origin. We should correct that for humans, if not for future AI training. Unless of course we seek for a sabotage strategy.

Claude was not aware of the existence of reciprocalModulo: and a few other Squeak methods, but it's easy to amend by prompting, otherwise it had a good sense of Squeak dialect.

I had the idea of playing with Chinese remainders in the back of my head, but Claude suggested this by itself even before I could do so.
So a few more prompts were enough to bring the Chinese Remainders versions for handling larger integers, and to push the limits imposed by SmallInteger arithmetic more explicitly.

After a few refactorings, I got a NTT multiplication beating Squeak 3-way Toom-Cooke multiplication around 2ˆ18 bytes, and 4-way Toom-Cooke squaring around 2^17 bytes, so near 1 Mega bit, that's not bad at all.

I consumed one more prompt for exploring the solution based on goldilocks prime 2ˆ64 - 2^32 + 1, on Claude's suggestion, which I did essentially for learning, because as predicted by Claude  this variant did not meet any interesting efficiency with Squeak available arithmetic.

I found most explanations given by Claude about the code quite clear, except maybe a few usage of jargon.
If not clear enough, it was just a matter of asking, and I got a satisfying answer.
For example, I had to ask details about the choice of primes, because the early comments were too synthetic.
The answers give an experience very close to literate programming, the chat just make it more interactive and that's enjoyable.

It's also pleasant to interact for suggesting a few enhancements, like using centered modulo, so as to use primes with one more bit while remaining in SmallInteger arithmetic, and get the updated version rapidly.
This little trick more than double the length of large integer that NTT can handle with SmallInteger arithmetic, and tough it knew this technique for saving a bit in Float FFT multiplication, Claude did not feature that by itself this time, probably because it's too much Smalltalk specific - C would use unsigned integer arithmetic.
Human added value is not exactly zero if you occupy a sufficiently narrow niche !

A single prompt was then enough for setting up an efficient FFT-based multiplication based on Float arithmetic for a comparison.

I was curious because last year I played with FFT-based multiplication all by myself, and it took me a few days for setting it up, testing, correcting my mistakes, tuning...
And my version is somehow inferior to Claude's one :

- less general (I split Integer in limbs with byte boundaries, Claude uses bit boundaries)
- less compact (I produced more code while searching for optimization)
- and finally less finely tuned (essentially due to the choice of limb width)

Indeed, I had to go thru stages that Claude did not even explore, because it was already aware of the state of the art and went straight toward such solution.

No secret, Claude did gather this knowledge from existing code and from scientific publications, which would have been my duty without an AI, but certainly not a matter of minutes.
From that, it was able to restitute a solution which must not be very far from the state of the art, much faster than me, and now, at least as good quality-wise.
So AI really shines in this part of the job in scientific area that consists in redoing just what has already been done, with a few variations, and it also shines for picking the right horse.

In a way, I find that interesting, because I can use it to learn about a specific subject.
It's more than just an assistant, but also somehow an interactive teacher.
We can still dream of being augmented by AI rather than replaced by AI.

It took me a few hours, not a few minutes to refactor, play some tests, measure efficiency.
As a human, I am the bottleneck, an agent could have done that more efficiently of course.
But that is my will and my pleasure, and anyway, I need to exercise and try by myself for learning, that's the burden of humanity.

Otherwise, what's the point of Smalltalk, if not for learning?
If I don't want to read or understand the code, I can as well ask AI to generate assembler, that would make more sense if speed of large integer multiplications was really the matter. But I known myself, even in assembler, my bias would make me curious about the implementation tricks.

Of course, this is just a toy example, a small part of a pet project I can come up with the limited token quota of free version.
It's not enough nowadays for challenging the AI.
It's just enough for having a more accurate feel of the revolution incoming.

Whatever we may think about the direction AI is taking and all implications it has on the future of younger people, insane consumption of energy, or captation of common goods by a few, it really has reached a point that will change our jobs forever. Exciting and frightening.

Sorry for not telling more about the Number Theoretic Transform itself, I will publish the code, and an AI will be able to tell more about the theory and comment the code better than I can. An other side effect of AI on humans: it encourages laziness.
A principle of economy of my own resources that AI is balancing by a massive expense of energy.