Re: DDD correctly emulated by HHH is Correctly rejected as non-halting V2 ---woefully mistaken rebuttal

On 7/26/2024 9:02 AM, Fred. Zwarts wrote:

Op 26.jul.2024 om 15:54 schreef olcott:

On 7/26/2024 3:50 AM, joes wrote:

Am Thu, 25 Jul 2024 23:25:59 -0500 schrieb olcott:

On 7/25/2024 10:35 PM, Mike Terry wrote:

On 26/07/2024 01:53, olcott wrote:

On 7/25/2024 4:03 PM, Mike Terry wrote:

On 25/07/2024 14:56, olcott wrote:

On 7/24/2024 10:29 PM, Mike Terry wrote:

On 23/07/2024 14:31, olcott wrote:

On 7/23/2024 1:32 AM, 0 wrote:

On 2024-07-22 13:46:21 +0000, olcott said:

On 7/22/2024 2:57 AM, Mikko wrote:

On 2024-07-21 13:34:40 +0000, olcott said:

On 7/21/2024 4:34 AM, Mikko wrote:

On 2024-07-20 13:11:03 +0000, olcott said:

On 7/20/2024 3:21 AM, Mikko wrote:

On 2024-07-19 14:08:24 +0000, olcott said:

>

(b) We know that a decider is not allowed to report on the
behavior computation that itself is contained within.

No, we don't. There is no such prohibition.

>

Therefore It is not allowed to report on its own behavior.

Anyway, that does not follow. The theory of Turing machines does
not prohibit anything.

>

In this case we have two x86utm machines that are identical except
that DDD calls HHH and DDD does not call HHH1.

I don't see how the outside use of a function can influence it.
>

It is empirically proven according to the semantics of the x86
machine code of DDD that DDD correctly emulated by HHH has different
behavior than DDD correctly emulated by HHH1.

Perhaps your actual code does behave differently!

OK great, we are making headway.

Thanks, Mike, for the detailed analysis.
>

The questions are:
a)  are HHH and HHH1 "identical copies", in the TM machine sense of
incorporating
      the algorithm of one TM inside another TM?  (As Linz
      incorporates H inside H^, meaning that the behaviours of H
      and embedded_H MUST be identical for any input.)
      [You claim HHH and HHH1 /are/ proper copies, and yet give
different results for input (D), which is impossible.]

>
They are identical in the that have identical x86 machine code except
for the x86 quirk that function calls are to a relative rather than
absolute address. So when HHH calls the same function that HHH1 calls
the machine code is not the same.  The only other case where the
machine code of HHH1 and HHH is not identical is the way for slave
instances of HHH to pass its execution trace up to the master.

How is the trace passed?
>

>
That does not matter. As long as we understand that Mike is correct about this:
>
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
 >
 > Obviously a simulator has access to the internal state
 > (tape contents etc.) of the simulated machine. No problem there.
>
Then we know that HHH can see the the first four instructions of
DDD have no conditional code that could prevent them from endlessly
repeating.
>
This is the exact same pattern with Infinite_Recursion()
where there are no conditional branch instructions that
would prevent the first three instructions of
Infinite_Recursion() from endlessly repeating.
>
_Infinite_Recursion()
[0000215a] 55               push ebp
[0000215b] 8bec             mov ebp,esp
[0000215d] e8f8ffffff       call 0000215a ; recursive call
[00002162] 5d               pop ebp
[00002163] c3               ret
Size in bytes:(0010) [00002163]
>
Begin Local Halt Decider Simulation   Execution Trace Stored at:113934
Decide_Halting_HH:1
[0000215a][00113924][00113928] 55               push ebp
[0000215b][00113924][00113928] 8bec             mov ebp,esp
[0000215d][00113920][00002162] e8f8ffffff       call 0000215a
[0000215a][0011391c][00113924] 55               push ebp
[0000215b][0011391c][00113924] 8bec             mov ebp,esp
[0000215d][00113918][00002162] e8f8ffffff       call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>

The relative addressing is to be expected as a difference, and is fine
provided the actual target is the same. [Which it seems to be...]
The whole thing with the slave instances might well be where the bug
lies!  That would be slightly funny, as I pointed out that problem on
some completely unrelated post, and this could be a follow-on issue
where it has caused observable misbehavior in the code.  (Needs a bit
more investigation...)
>

There never is any actual bug with the simulation.

>

I bet my nonexistent soul that there are bugs left in libx86. Apart
from that, your use of the library may be buggy.
>

>
That is irrelevant. We can see by the execution trace of
DDD emulated by HHH that this emulation does precisely
match the semantics of the first four x86 machine language
instructions of DDD.
>
We can also see that DDD emulated by HHH1 does precisely
match the semantics of the x86 machine language instructions
of DDD.
>
People have been saying that I am wrong about the for three
years never bothering to notice that I have always proved
that I am correct about this.

 But you have been told that it is not enough to simulate only four instructions of a halting program. The simulation is aborted when the simulated HHH has only one cycle to go.

*This is merely your own software engineering incompetence*
Unless the outermost HHH (having seen the longest execution
trace sequence) aborts its own simulation of DDD then none of
them, ever abort.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer