Re: How do computations actually work?

On 5/22/25 10:47 PM, olcott wrote:

On 5/22/2025 8:24 PM, Mike Terry wrote:

On 22/05/2025 06:41, Richard Heathfield wrote:

On 22/05/2025 06:23, Keith Thompson wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

On 22/05/2025 00:14, olcott wrote:

On 5/21/2025 6:11 PM, Richard Heathfield wrote:

[...]

Turing proved that what you're asking is impossible.
>

That is not what he proved.

>
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good
luck with that.

>
Not necessarily.

>
Of course not. But I'm just reflecting. He seemed to think that my inability to write the kind of program Turing envisaged (an inability that I readily concede) is evidence for his argument. Well, what's sauce for the goose is sauce for the gander.
>

Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible

>
And we both know what we both think of that idea.
>

-- that doesn't imply
that he or anyone else would be able to write one.

>
Indeed.
>

I've never been entirely clear on what olcott is claiming.

>
Nor I. Mike Terry seems to have a pretty good handle on it, but no matter how clearly he explains it to me my eyes glaze over and I start to snore.

>
Hey, it's the way I tell 'em!
>
Here's what the tabloids might have said about it, if it had made the front pages when the story broke:
>
   COMPUTER BOFFIN IS TURING IN HIS GRAVE!
>
   An Internet crank claims to have refuted Linz HP proof by creating a
   Halt Decider that CORRECTLY decides its own "impossible input"!
   The computing world is underwhelmed.
>
Better?  (Appologies for the headline, it's the best I could come up with.)
>
Mike.
>

 There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
 It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.

Sure there is. Remember, "AN INPUT" in this case is defined to be the representation of a program, in it is that PROGRAM that does the opposite.
"INPUTS" don't *DO* anything, they represent things that do things.

 int main()
{
   DD; // HHH cannot report on the behavior of its caller
}     // *That is just not the way that computations work*

But it can be REQUIRED to do so.
After all, H(D) is asking/requiring H to report on the behavior of D, and that answer, if H and D are actually a programs as required, is independent of the context of the question, as the behavior of a program is independent of the context it is run in.
Note, part of your problem is that you are trying to work with category errors, as you want H to not be a program, and thus not "fixed code", but then neither is D, as it is built on H, and thus you question isn't even the same question, but one based on a category error.

 It is the same thing with the Linz proof.
 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 embedded_H cannot report on the behavior of
the computation that itself is contained within.
*That is just NOT THE WAY that computations work*

But it MUST to be correct.
embedded_H <H^> <H^> *WILL* do something, and if you follow the rules, it will do the same thing that H <H^> <H^> will do, as they are the same algorithm.
Since H^ <H^> does the opposite of what H <H^> <H^> does say, so H and embedded_H are just wrong.
It isn't that there was something wrong with the question, they are just not giving the correct answer, and are thus wrong.
THat fact that no matter HOW we write the program H, it will always be wrong says the question is not computable, not that the question is wrong.