[Krssst]

Fully agree with the article (as my comment history would attest). I wonder why people worry so much more about "determinism" over conformance to a spec. (a compiler can be nondeterministic and correct which is not particularly good but definitely not worse than being incorrect)

Maybe most devs don't care so much about the language specification and just expect the code to do vaguely what it looks it should do intuitively? This is not very clear to me, at least for libraries I guess a lot of people don't read API docs and just call the API hoping it does what the name says (preconditions be damned) in which case nondeterminisc observable behavior would be more problematic than nonconformance to a spec (API doc) they don't read.

[nyrikki]

Two things are being conflated here.

Try writing the grammar of natural language in EBNF if you want a fast but unsatisfying answer.

The univalence axiom and HoTT is another path.

Or just trying to find out why two programs in lambda calculus that are beta convertible and thus recursively inseparable is another path.

Finite model theory and how gödels completeness theorem doesn’t hold while it does for infinite models is another path.

Finite VC dimensionality being required for PAC learnability is a path from the other side.

There are many forms of indeterminacy, and some allow for a concept of equality that disallows apartness, like computing, but the relationship with choice/omniscience/set shattering is complicated.

Perhaps non HoTT type theory being a map between type Families may provide some useful intuition.

Under lambda calculus, which is equivalent to intuitionistic logic, the principle of explosion (ex falso quodlibet) states that any statement can be proven from a contradiction.

Intuitionists accept this rule because, under their constructive interpretation, an absurdity means a problem is demonstrably impossible to solve.

PAC learning, through set shattering makes any logic Classic, introducing PEM/AC or various forms of it.

It isn’t just the presence of indeterminacy that matters, the form it takes matters.

[orbital-decay]

>I wonder why people worry so much more about "determinism" over conformance to a spec.

From what I've seen in these HN discussions, most people are using "determinism" when they really mean "prompt sensitivity", i.e. minor variations in framing leading to different results. This, in turn, confuses people who do understand what determinism is supposed to mean and where it's necessary (build reproducibility for example).

>nonconformance to a spec

This is bound to happen for informal specs. It's the inherent property of the domain both models and humans operate in.

Current models are optimized for coding rather than human communication, and have shallow understanding of human intent. Their reading between the lines is pretty poor, and they can't distinguish between important and unimportant details of the prompt, following it too literally and forcing you to give them more context for clarification.

[Delk]

> From what I've seen in these HN discussions, most people are using "determinism" when they really mean "prompt sensitivity", i.e. minor variations in framing leading to different results. This, in turn, confuses people who do understand what determinism is supposed to mean and where it's necessary (build reproducibility for example).

For lack of a better word, I'd also have used "determinism". But to borrow a bit from TFA, what I'd really mean by that would some kind of "semantic determinism": for any input source code in a well-defined language, a correctly working compiler will always produce output that's semantically correct for the input.

Let's say a compiler implementation internally does something random or nondeterministic but that the nondeterminism does not affect the semantics of the output. You could argue that the compiler is technically nondeterministic, but in terms of program semantics it would still be deterministic.

I assume that's what people mean when they say compilers are deterministic in comparison to LLMs.

So in some sense the post is correct, but I think the author is somewhat pedantically misinterpreting the way people use the word "nondeterminism".

IMO prompt sensitivity is something different. A prompt does not unambiguously describe full program semantics in the first place, and the neural network would not contain an explicit mechanism for producing semantically matching output even if it did. Prompt sensitivity comes on top of that but isn't the core matter.

[orbital-decay]

I think you want the impossible, because a) input semantics are non-formal and ambiguous/subjective by definition, and b) the model suffers from the curse of its knowledge being vastly wider than yours and doesn't have enough context to converge on exactly what you want in the huge space of possibilities presented by even the most constraining but still informal inputs.

If you limit your requirement to the difference between your and model's interpretations being small enough, that's probably doable. Which is realistically what most people want, and most good coding models already have, more or less (with caveats that still need to be addressed, of course). But a hard guarantee of output staying unchanged with different inputs is not possible to give (regardless of whether you think they're unambiguous) due to the nature of intelligence, human or machine.

[Delk]

I'm not asking for LLM tools to be similar to compilers, or saying that they can't be useful if they aren't. I know rather well that the two are different, and that's the point.

Because LLMs aren't deterministic in terms of producing semantically correct output, that just means they aren't similar to compilers. That means you probably can't just start blindly trusting that their output matches the input and thus ignore understanding the code, as most people mostly can with compilers.

I think that's what people mean with "determinism" when they compare LLMs to compilers, or in response to other people suggesting LLMs are no different than compilers.