Re: HHH(DDD) sees the exact same behavior pattern as HHH(Infinite_Recursion)

Op 28.jul.2024 om 22:10 schreef olcott:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

On 7/28/2024 2:59 AM, Fred. Zwarts wrote:

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:
>

Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).

>
I think you're wrong, here.  All your C programs are a stand in for
turing machines.  A turing machine is either running or halted. There is
no third state "aborted".  An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing
machine.
>
So aborted programs are halted programs.  If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
>

>
Aborting is an action performed by a simulator, not the TM being simulated.
>
If we want to count "aborted" as some kind of final status, it will have to be the status of a specific /PARTIAL SIMULATOR's/ simulation of a given computation.  That's not a property of the computation itself, as different partial simulators can simulate the same computation and terminate for different reasons.  Like HHH(DDD) aborts, while UTM(DDD) simulates to completion and so the final simulation status is halts. [Neither of those outcomes contradict the fact that the computation DDD() halts.]
>
If some partial simulator halts when simulating a computation [as with UTM(DDD)] that implies the computation DDD() halts.  But if the simulator aborts, it doesn't say that much (in and of itself) about whether the /computation/ halts.  The halting problem statement is not concerned with simulations or how the simulations end.
>
Every time anyone in these PO threads says "halts" it ought to be 100% clear to everyone whether the computation itself is being discussed, or whether some simulation final status is intended. (But that's far from being the case!)  Since the halting problem is concerned with computations halting and not how partial simulations are ended, I suggest that PO explicitly make clear that he is referring to simulations, whenever that is the case.  It seems reasonable that readers seeing "halts" with no further clarification can interpret that as actual computation behaviour, as that is how the term is always used in the literature.  Same with other terms like "reach"...
>
So when PO says "DDD simulated by HHH cannot reach its final ret instruction" is he talking about the computation DDD() [as defined mathematically], or its simulation by HHH?  He means the latter, but its far from clear, I'd say!  [I think most readers now have come around to reading it as a statement about simulations rather than the actual computation, which totally changes things...]
>
>
Mike.
>

>
_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]
>
It is a verified fact that DDD emulated by HHH 100% exactly
and precisely according to the actual x86 semantics of
the emulated code including the recursive call that causes
HHH to emulate itself emulating DDD cannot possibly get
past it own 0000216b machine address.
>
*Anyone as much as hinting otherwise is not being truthful*
If we remove all of the problematic code then this same
trace still occurs until it crashes from OOM error.
>

>
No matter how much olcott wants it to be correct, or how many times olcott repeats that it is correct, it does not change the fact that such a simulation is incorrect, because it is unable to reach the end.

>
It is ridiculously stupid to expect the correct emulation
of a non-halting input to end.

>
Irrelevant nonsense ignored.
We are not discussing a non-halting HHH,

 No we are not. Please don't act so stupidly.

Why are you contradicting yourself so often? It does not look very clever.
You were talking about an infinite set of HHH, some of which abort, some of which do not abort.
We all agree that the HHH that do not abort are incorrect, even Olcott agrees with it. Therefore, no further discussion is needed about the HHH that do not abort. Starting to mention it again is distracting from the points of disagreement.
The disagreement that is left is about the HHH that do abort.
Olcott has shown 'traces' of such an HHH when simulating itself.
This proves that after two recursive simulations, HHH aborts its simulation and halts.
It is comparible with:
void Finite_Recursion (int N) {
   if (N > 0) Finite_Recursion (N - 1);
}
which also halts after a few recursions.
For some unclear reason, olcott keeps dreaming of the HHH that does not abort and he thinks that such dreams should play a role in the logic to determine whether the simulation of a halting program is correct.
Olcott's aborting HHH is programmed to abort the simulation after N cycles of recursive simulations. Therefore, it is incorrect to abort the simulation of HHH when the simulated HHH has performed only N-1 cycles, because that changes the behaviour of the simulated HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH, it is clear that HHH can never simulate enough cycles for a correct simulation, as is required by the x86 language.
Therefore, the simulation is incomplete and therefore incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.
No matter how much olcott wants it to be correct, or how many times olcott repeats that it is correct, it does not change the fact that such a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end confirms it. The trace he has shown also proves that HHH cannot reach the end of its own simulation. So, his own claims prove that it is true that HHH cannot possibly simulate itself up to the end, which makes the simulation incomplete and, therefore, incorrect.
Sipser would agree that this incorrect simulation cannot be used to detect a non-halting behaviour.