Re: Refutation of the Peter Linz Halting Problem proof 2024-03-05 --partial agreement--

On 3/7/2024 12:36 PM, Mike Terry wrote:

On 07/03/2024 15:05, immibis wrote:

On 7/03/24 06:23, Mike Terry wrote:

On 06/03/2024 23:59, immibis wrote:

I saw x86utm. In x86utm there is a mistake because Ĥ.H is not defined to do exactly the same steps as H, which means you failed to do the Linz procedure.

>
Not sure if we're discussing a general H here, or PO's H/Ĥ under his x86utm.  (Ĥ is called D under x86utm.)
>
Under x86utm, Ĥ.H is implemented as a call to H from D, whilst H in implemented as a call to H from main.  So we would expect stack addresses to differ, but for that not to affect the computation.
>
In both cases, H:
-  simulates D(D) computation
-  spots PO's unsound "infinite recursion" pattern
-  announces it has encountered infinite recursion
-  returns 0  [non-halting]
>
So Ĥ.H does exactly the same steps as H, and reports the same result, as required for Linz proof. And just as Linz proof proves, the result reported by H is incorrect, since D(D) halts.

>
Last time I paid attention to what Olcott was saying about this scenario, I think he said something like "the non-halting result reported by H is correct, since D(D) never halts unless aborted." and then a lot of electrons were wasted trying to persuade Olcott that H was supposed to return based on whether the "direct execution" of D(D) "actually halts", not whether the "simulation" of D(D) "never halts unless aborted."
>

The HH/DD case is different, as that coding is completely broken by misuse of global variables to divert the course of the code under the simulator.  But since EVEN WHEN THINGS WORK EXACTLY AS PO WANTS his results are in AGREEMENT with Linz, it seems to me that arguing that his problem is relating to cheating with the simulation is kind of missing the point.

>
Halting deciders are allowed to do anything they want with their input programs, such as doing correct simulations, or incorrect simulators, or counting the length to see if it's a prime number. However, Olcott's argument was based on the premise that a correct simulation was involved. This is invalid since the simulation is not actually correct, and trying to hide the incorrectness - "cheating" - does not make it actually a correct one.
>
The mistake/cheating isn't that the simulation is incorrect (that's allowed) - it's that the simulation is incorrect but the argument is based on it being correct. That's why recently I got more careful by saying "you failed to do the Linz procedure" instead of "you are cheating".

 Right, but a funny thing is that if/when PO corrects his logic to do a /correct/ simulation for HH/DD, the results reported for this corrected simulation will be exactly the same as the current incorrect HH/DD!  I.e. the corrected HH will still report that the corrected DD(DD) is non-halting, and the corrected DD(DD) will in fact still halt as before. 

When every H uses the proxy criteria:
Will you halt if you never abort your simulation?
Then H(D,D) and H1(D,D) applying this same criteria
get different results.
It is an easily verified fact that:
H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address 00001422
*different machine addresses is the reason for different return values*
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer