Live data from Hacker News

Language models as compilers: Simulating pseudocode execution

arxiv.org

51–57 of 57 posts

Re: Language models as compilers: Simulating pseudocode execution

#51
post #40

Non deterministic compilers, yay! Where do I sign up? In more seriousness, miscompilations or in general unexpected behavior caused by layers below you are expensive to find and fix. I think LLMs have a long way to go before such use cases seem appealing to me.

Non-determinism is an implementation detail, not an intrinsic property, as I understand it (at least as long as you're setting temperature to zero). I likewise don't really think LLMs are the right tool for this job, though. There's a whole class of systems that we built because humans take a long time to learn new skills, are fallible and non-repeatable, and get bored easily. Compilers are in this group along with s…

>Non-determinism is an implementation detail, not an intrinsic property, as I understand it (at least as long as you're setting temperature to zero).

Right. A transformer outputs a probability distribution over all possible tokens from which the next token is sampled and then appended to the input sequence, at which point the process repeats. Temperature controls the entropy of the distribution - higher temperature, higher entropy, conversely, lower temperature, lower temperature. Technically zero temperature involves dividing by zero, so under the hood it's simply set to be an epsilon so small that the entropy of the distribution is low enough that sampling from it always effectively gives one token - the token with the highest probability. And so at every step in inference, the highest probability token is emitted.

Re: Language models as compilers: Simulating pseudocode execution

#52
Researchers are trying their damndest to build a "reasoning" layer using LLMs as the foundation. But, they need to go back to the drawing-board and understand from first principles what it means to reason. For this in my view, they need to go back to epistemology (and refer to Peirce and logicians like him).

Re: Language models as compilers: Simulating pseudocode execution

#53
post #40

Earlier quoted context omitted.

Non-determinism is an implementation detail, not an intrinsic property, as I understand it (at least as long as you're setting temperature to zero). I likewise don't really think LLMs are the right tool for this job, though. There's a whole class of systems that we built because humans take a long time to learn new skills, are fallible and non-repeatable, and get bored easily. Compilers are in this group along with s…

>Non-determinism is an implementation detail, not an intrinsic property, as I understand it (at least as long as you're setting temperature to zero). Right. A transformer outputs a probability distribution over all possible tokens from which the next token is sampled and then appended to the input sequence, at which point the process repeats. Temperature controls the entropy of the distribution - higher temperature,…

[deleted]

Re: Language models as compilers: Simulating pseudocode execution

#55
post #41

Earlier quoted context omitted.

In my experience it’s not exactly trivial to validate code you didn’t write yourself, because you have to think through it in similar depth to when you write it yourself. While on the one hand you save the time of coming up with a solution, the task of merely verifying an existing solution is also more tedious, because it isn’t intermixed with the problem-solving activity that you perform when writing the code yourse…

I agree with you. I never liked how AI is really generating ton of code for us, then you need to read through it and understand it. Plus, the fail rate is to high. That is why I design the language the way it is. You must define each step you want to happen in your application. Lets take for example user registration, it looks like this --- plang code --- CreateUser - Make sure %password% and %email% is not empty - H…

But you have to double-check those 130 lines and think through all possible cases (edge cases, error cases) for each statement. I don’t see how you save all that much time. And your example output doesn’t even contain error handling, logging, and so on. There’s also no way to roundtrip any changes you want to add to the output code, while still making changes to the high-level description. (This is one reason why model-driven programming largely failed.)

Re: Language models as compilers: Simulating pseudocode execution

#56
post #35

I wrote a toy language along these lines a while back[0]. Basically, types and function signatures, with comments in English, produce a valid program. You write a type and a comment, and the compiler goes through GPT to run the code. Fun novel idea. [0] - https://github.com/eeue56/neuro-lingo

This paper suggests that pseudocode is more understandable to LLM's than natural language. So building off of that, one should not write comments in the method bodies, one should translate a function body (in mixed English and pseudocode) as a unit. LLM's can memorize a lot but there is a limit so I guess it would have to be structured as a multi-level translation. You mention in the Readme that it is persnickety, this is probably due to the use of "auto-complete" in the prompt. I would use an intro like "here is a function body in pseudocode", then prompts "split it into chunks by inserting labels", "translate whole body preserving chunk labels", "re-translate each chunk using whole body as context", "fix type errors". I think the biggest issues besides prompt engineering are cost and latency though.

Re: Language models as compilers: Simulating pseudocode execution

#57
post #5

Any sufficiently advanced LLM is indistinguishable from Prolog. I half-jest but I envision the direction of LLM research to head towards a parser-oriented setup where LLMs merely extract the entities and relations and the actual logic is done by a logical engine such as Prolog.

You aren't half jesting, you have been thinking about this for months as have I.
Post reply on HN