Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: DDD correctly emulated by HHH is Correctly rejected as
 non-halting V2 ---woefully mistaken rebuttal
Date: Fri, 26 Jul 2024 08:54:32 -0500
Organization: A noiseless patient Spider
Lines: 229
Message-ID: <v809qo$2rabc$3@dont-email.me>
References: <v6rg65$32o1o$3@dont-email.me>
 <056325e336f81a50f4fb9e60f90934eaac823d22@i2pn2.org>
 <v73gk2$obtd$1@dont-email.me>
 <e2958e7ea04d53590c79b53bfb4bc9dff468772b@i2pn2.org>
 <v742r2$s48s$2@dont-email.me>
 <210383b2ee318f68a96d94aec314ee8b93f79b7f@i2pn2.org>
 <v75u22$19j7l$4@dont-email.me>
 <fde630817c49562bc765bdbc98e16a1582bcad53@i2pn2.org>
 <v78mda$1smtm$2@dont-email.me> <v7d5cl$2t3ja$1@dont-email.me>
 <v7ds0o$30pvh$3@dont-email.me> <v7fs29$3f4g7$1@dont-email.me>
 <v7gd17$3hlc2$2@dont-email.me> <v7ikn4$1jv5$1@dont-email.me>
 <v7j2pg$3o7r$3@dont-email.me> <v7l3di$idv1$1@dont-email.me>
 <v7lnrf$luh0$1@dont-email.me> <v7niqp$13ghd$1@dont-email.me>
 <v7obbn$17h8r$1@dont-email.me>
 <2eecnR6fa9XiWzz7nZ2dnZfqn_ednZ2d@brightview.co.uk>
 <v7tlin$2acgd$1@dont-email.me>
 <9KOcnbAqLvwnID_7nZ2dnZfqn_adnZ2d@brightview.co.uk>
 <v7us2g$2gvh6$1@dont-email.me>
 <xEydncDTQ97yhD77nZ2dnZfqnPGdnZ2d@brightview.co.uk>
 <v7v8gn$2m27k$1@dont-email.me>
 <fad91f57ff0a31257ab8ce5e2e0a47f4bd4c7bbc@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 26 Jul 2024 15:54:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="98ef4f11d97010b63c53911c6d37ff8b";
	logging-data="2992492"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+BieO30JZmOuJ8x9TAuNm6"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:JcyVi6DKr0rekd56yrho8BJ8qS8=
In-Reply-To: <fad91f57ff0a31257ab8ce5e2e0a47f4bd4c7bbc@i2pn2.org>
Content-Language: en-US
Bytes: 12040

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.

>>>> Although it seems that I have been correct all along about the idea
>>>> that slave instances can pass their execution trace up to the master
>>>> without breaking computability this is not the way it has been
>>>> actually encoded.

> How is it coded?
> 

That does not matter as long as we understand that 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.

Proves that it is possible for the outer HHH to see the repeating
state of DDD then the details of how my HHH does this become moot.

>>>>> b)  If the two behaviours HHH/HHH1 are indeed different, WHAT
>>>>> precisely is the coding
>>>>>       difference that accounts for that different behaviour?
>>>>>       (Like, with your H/H1 the
>>>>>       difference was that H used H's address as part of its
>>>>>       algorithm, while H1 used H1's address.)
>>>> DDD calls HHH(DDD) in recursive simulation and does not call HHH1(DDD)
>>>> in recursive simulation.
>>> You may have said it 500 times, but it doesn't answer my question!
>> The problem is that the code itself has already answered this question
>> 500 times in three years and people just ignore it.
>> When DDD emulated by HHH calls HHH(DDD) this call cannot possibly
>> return. When DDD emulated by HHH1 calls HHH(DDD) this call DOES return.

> But whyyy?
(a) Because people so stupidly assume that I must be wrong that
they make sure to not pay attention to the proof that I am correct?

(b) People don't have a clue about the semantics of the x86 language
and try to bluff using pure bluster.

> 
========== REMAINDER OF ARTICLE TRUNCATED ==========