Right - this seeming "cognition" is exactly what's so spooky about the whole thing.
Here's what spooked me out from yesterday: https://news.ycombinator.com/item?id=35167685 - specifically how it determines the divide-by-zero error in this code: https://whatdoesthiscodedo.com/g/6a8f359
...which demonstrates GPT as being capable of at-least C++ "constexpr"-style compile-time computation, which shouldn't even be possible if one presumes GPT is "just" a giant database storing only multidimensional word similarity scores and sequence distribution from text inference.
> a generative LLM
I definitely wanted to believe that GPT was "just predicting the next word" - it was somewhat comforting to think of GPT as still being far from being-human or behaving like a real brain does - but that explanation never sat well with me: it was too simplistic and dismissive, and didn't explain the behaviour I was witnessing in GPT.
...so after having read Wolfram's (surprisingly accessible) article on GPT ( https://writings.stephenwolfram.com/2023/02/what-is-chatgpt-... ) it made a lot of things "click" in my head - and enabled me to start to understand why and how GPT is capable of... the surprising things it does; but it also leads me to believe we're (warning: incoming cliche) barely scratching the surface of what we can do: right-away I do believe we're almost at the point where we could simply ask GPT how to adapt it into some kind of early AGI - and we've all heard of what's supposed to follow next... and it really is quite unsettling.
> capable of at-least C++ "constexpr"-style compile-time computation, which shouldn't even be possible if one presumes GPT is "just" a giant database storing only multidimensional word similarity scores and sequence distribution from text inference
I don't see how being a giant word-DB necessarily disqualifies compile-time computation. You can view computation as applying a series of term rewrite rules to an input until some sort of termination condition (or indefinite loop). In the case of these AI, the input is the prompt and predicting the next token is a limited form of term rewriting (where the rules are probabilistic and based off the network), and because code and explanations were probably included in the training data, it seems reasonable to me that the "rewrite rules" of Python bled a little bit into the AI.
It makes me insanely curious about the internal structures though. I gave that site 2 similar examples: one produces a correct explanation while another produces an incorrect explanation. The difference: a deleted line of insignificant whitespace
* https://whatdoesthiscodedo.com/g/dd2af89
* https://whatdoesthiscodedo.com/g/45ea060
From those 2 examples, I think its pretty clear that the AI's "rewrite rules" don't always coincide with Python's, but I would expect this to be mitigated by targeted training (like Copilot).
I asked it to write a moderately complex algorithm, and it chose to write a function to compute the Pollard's Rho algorithm.
Then, with a few example comments to show what I meant, I asked it to annotate the code to show how the constraints on the variable changed as each line was executed.
This was its output:
# n : an integer n > 3, no upper limit
# seed : an optional integer parameter (default = 1) for the polynomial function
# pollards_rho(n, seed) : an integer or nil, representing a non-trivial factor of n, or nil if the algorithm fails to find a factor
def pollards_rho(n, seed = 1)
return n if n <= 3
x = 2
# x : an integer, initially set to 2, will be updated using the polynomial function f
# x will always be in the range [0, n)
y = 2
# y : an integer, initially set to 2, will be updated using the polynomial function f
# y will always be in the range [0, n)
d = 1
# d : an integer, initially set to 1, will store the greatest common divisor of (x - y) and n
# 1 <= d <= n
while d == 1
x = f(x, n, seed)
# x : updated using the polynomial function f, x = (x * x + seed) % n
# x will always be in the range [0, n)
y = f(f(y, n, seed), n, seed)
# y : updated using the polynomial function f twice, y = ((y * y + seed) * (y * y + seed) + seed) % n
# y will always be in the range [0, n)
d = gcd((x - y).abs, n)
# d : the greatest common divisor of the absolute difference between x and y, and n
# 1 <= d <= n, such that (x - y) % d == 0 and n % d == 0
end
d == n ? nil : d
# Returns a non-trivial factor of n (1 < d < n) if one is found, or nil if the algorithm fails to find a factor
endThis is not actually the most impressive thing I've seen it do, but it illustrates that, even if GPT doesn't "really understand" code, it can emulate understanding to an impressive level. I'd go further and say that it opens up new questions as to what understanding actually means.
One personal "woah" moment was asking it to write some unit tests for a simple 2d game GPT and I wrote together. One function, "create_area" took a 2d array of characters (representing a map) and four integers representing coordinates, and a tile type. (The purpose being to create a rectangular area of the desired tile on the map according to the passed coordinates.)
GPT-4 successfully figured out how to write a unit test: it created a 5x5 array of ROCK tiles, passed it to create_area with the coordinates 1, 1 and 3, 3, and successfully figured out what the output should look like, even writing a fairly concise test to check the output (modified) 5x5 array. This was an eyebrow-raising moment for me: it made clear that GPT really does emulate some kind of "computation" internally, though quite possibly in some abstracted form. The geometric nature of this problem stuck out to me: a human can "see" a 2d array as a rectangular grid, and might realise the function carved out a smaller rectangle from that grid, but I never expected to see a computer (let alone a language model) figure it out. Interesting times, indeed.