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

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.  I expect even his (highly filtered) execution log will be unchanged, since corrections will be in the filtered portion of the log!  PO's argument for how this refutes Linz will not have any reason to change, so his error is not really a /consequence/ of any incorrect simulation within HH - it is more basic.  [Still, you're right - if x86utm code doesn't actually correctly implement what PO argues about, it is completely pointless, demonstrating nothing.]
Another consequence if PO does correct his misuse of global variables in HH: his routines HH and HH1 [*] should be equivalent computationally, and so HH and HH1 will give the /same/ result for input (DD,DD).  That contrasts with the current behaviour seen for H/H1 where H(D,D) = non-halting and H1(D,D) = halts.  [Due to H1 not actually being a proper clone of H.]
Doesn't that feature in one of PO's more dappy recent arguments, something about HH being "the real decider" for H/D rather than H, explaining why HH gets the wrong/right answer precisely because H/D.H gets the right/wrong answer [Or whatever - the idea is so silly I can't even be bothered to look up which way round it's all supposed to go]?
If so, by obvious extension, shouldn't PO say HH1 was "the real decider" for (DD,DD), even though HH1 gives the /same/ wrong result for input (DD,DD) as HH?  None of this makes any sense...
Regardless of what /actually/ happens in these simulations, we can be sure PO will just carry on regardless, Saying More Words - basically anything his mind can conjure up to excuse the differences between his mistaken intuitions and reality.  Nobody will change PO's intuitions, and none of this makes any difference to anybody other than PO...
[*]  HH1 being a direct code-copy of HH but at a new address, mirroring the H/H1 setup.
      Actually, I've just checked halt7.c, and there is no HH1!  I guess PO
      just never had any need to try out that scenario.
      Final thought: actually wouldn't /current/ (broken) HH/HH1 also give the same
      result for DD?  If so the point made above is not dependent on PO fixing HH logic...
Regards,
Mike.