When I was a bored and under-challenged student in the early days of university, one of my tests during a programming exam was to write a program that spit out the factorial of an input integer.

For shits and giggles, I just just wrote a series of `if...then` statements for 0 to 5, and only actually calculated the factorial for inputs >=6. I passed after the examiner just input 3 and 5 and was satisfied that the output was correct. Oops.

Doing a table lookup for common cases and computing for the less common ones is perfectly valid!

And for some problems it's even efficient. Not factorial, though.

Oh you're right, hive mind, it's efficient. Sorry.

Not 100% sure but I believe this is how we landed the lunar module on the moon the first time...tan/arctan/both were too hard to compute on the processors of those days so they discretized into half angles & stored the tangents in a lookup table.

That's how early calculators worked, and some fast math libraries today too.

The Pentium FDIV bug was due to a bad value in a lookup table.

This is the way. Next, you could cache those values for >=6 when you compute them and also use the previously cached values for sub-problem solutions.

Sorry, did it try to predict the output, or did it only predict the output based on what it has seen people say about similar code online?

Is your objection to the use of the word "try"?

The difference is "did it study the code and inputs/outputs" vs "it studied comments about the code"

What would it do if the training data was only code? Only code+inputs+outputs? Only function signature+inputs/outputs? Only signature+comments?

Etc.

The second one

I think its knowledge of python can only come from comments about code, since it can't execute the python or learn from trying code like a human would.

That doesn't change the fact that its predicting the output based on its knowledge of python though.

So, yes you're right, but at the same time it doesn't change anything IMO.