101–105 of 105 posts
Earlier quoted context omitted.
Yes joke is: [A B] times [1] [1] is [A+B]
From context then, I infer that a transformer is not comprised of matrix multiplications, because it would simply be one that adds two 10-digit numbers.
So, what happens when you test it on 11 digit numbers? I don’t mean that as a gotcha or “LOL dumb transformer” snark. More like, does the accuracy start to drop as you add digits? Or instead, maybe it’s the transformer equivalent of a stack overflow and it outputs a picture of a burning spoon or something? And for that matter, what’s it do with 9 digit numbers? Like, is it more accurate with them, or are these little…
Depends on how the transformer has been trained. If it has seen 11 digit examples while training it might work, else the input will be out of distribution and it will respond with a nonsensical number. For instance the current high score model (311 params [0]), when given 12345678900 + 1, responds with 96913456789. An interesting experiment would be: what's the minimum number of parameters required to handle unbounde…
A recurrent neural network implementing binary addition with carry could do this, and one can derive the correct weights with pen and paper without too much effort.
Whether gradient descent will find them too is another matter entirely
Very cool, but can I suggest the `add` CPU instruction instead? Supports 64-bit numbers, and it's encoded in hardware, and no need to cross a PCIe interface into a beefy, power-hungry GPU and back again. And chances are it's cross-platform, because basically every ISA since the very first has had `add`.
No. You cannot. It's the wrong tool for the problem. That little "add" of yours has the overhead of: having an LLM emit it as a tool call, having to pause the LLM inference while waiting for it to resolve, then having to encode the result as a token to feed it back. At the same time, a "transformer-native" addition circuit? Can be executed within a single forward pass at a trivial cost, generate transformer-native re…
I get that this is technically interesting, for certain, but the sheer amount of energy and associated global warming risk needed to do something with >=99% accuracy that we've been able to do easily for decades with a guaranteed 100% accuracy seems to me to be wasteful to the extreme.
Wait until you see the quantum computer that it takes to factor the integer 15.
It didn't even run the full algorithm, but a compiled version that requires knowledge of the result beforehand. They've also factored 21... it also has a factor of 3.
Earlier quoted context omitted.
+1 I’ve always had the feeling that training from randomly initialized weights without seeding some substructure is unnecessarily slowing LLM training. Similarly I’m always surprised that we don’t start by training a small set of layers, stack them and then continue.
Better-than-random initialization is underexplored, but there are some works in that direction. One of the main issues is: we don't know how to generate useful computational structure for LLMs - or how to transfer existing structure neatly across architectural variations. What you describe sounds more like a "progressive growing" approach, which isn't the same, but draws from some similar ideas.
In terms of sub structure - in the old days of Core Wars randomly scattering bits of code that did things could pay off. I’m imagining similar things for LLMs - just set 10% of weights as specific known structures and watch to see which are retained / utilized by models and which get treated like random init