Path: ...!weretis.net!feeder8.news.weretis.net!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: Thu, 25 Jul 2024 19:53:34 -0500
Organization: A noiseless patient Spider
Lines: 255
Message-ID: <v7us2g$2gvh6$1@dont-email.me>
References: <v6rg65$32o1o$3@dont-email.me>
 <34Ocnd4voeWlDAn7nZ2dnZfqnPudnZ2d@brightview.co.uk>
 <v725d7$hlvg$1@dont-email.me>
 <aa7643b6d8c46d2c4dd5ef92ae3650afe114adbb@i2pn2.org>
 <v734ct$mjis$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 26 Jul 2024 02:53:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="98ef4f11d97010b63c53911c6d37ff8b";
	logging-data="2653734"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18owvvvEAJwv/7Q/gRRt2lN"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:43sqtHKjF+9gLRoOpvgD7sdnXDE=
In-Reply-To: <9KOcnbAqLvwnID_7nZ2dnZfqn_adnZ2d@brightview.co.uk>
Content-Language: en-US
Bytes: 12833

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:
>>>>>>>>>>>
>>>>>>>>>>>> When we use your incorrect reasoning we would conclude
>>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it
>>>>>>>>>>>> only repeats until aborted and is aborted.
>>>>>>>>>>>
>>>>>>>>>>> You and your HHH can reason or at least conclude correctly about
>>>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to
>>>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Because this is true I don't understand how you are not 
>>>>>>>>>> simply lying*
>>>>>>>>>> int main
>>>>>>>>>> {
>>>>>>>>>>    DDD();
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Calls HHH(DDD) that must abort the emulation of its input
>>>>>>>>>> or {HHH, emulated DDD and executed DDD} never stop running.
>>>>>>>>>
>>>>>>>>> You are the lying one.
>>>>>>>>>
>>>>>>>>> If HHH(DDD) abrots its simulation and returns true it is 
>>>>>>>>> correct as a
>>>>>>>>> halt decider for DDD really halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> (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.
>>>>>>>
>>>>>>
>>>>>> Turing machines never take actual Turing machines as inputs.
>>>>>> They only take finite strings as inputs and an actual executing
>>>>>> Turing machine is not itself a finite string.
>>>>>
>>>>> The definition of a Turing machine does not say that a Turing machine
>>>>> is not a finite string. It is an abstract mathematical object without
>>>>> a specification of its exact nature. It could be a set or a finite
>>>>> string. Its exact nature is not relevant to the theory of computation,
>>>>> which only cares about certain properties of Turing machines.
>>>>>
>>>>>> 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.
>>>>>
>>>>>> Another different TM can take the TM description of this
>>>>>> machine and thus accurately report on its actual behavior.
>>>>>
>>>>> If a Turing machine can take a description of a TM as its input
>>>>> or as a part of its input it can also take its own description.
>>>>> Every Turing machine can be given its own description as input
>>>>> but a Turing machine may interprete it as something else.
>>>>>
>>>> In this case we have two x86utm machines that are identical
>>>> except that DDD calls HHH and DDD does not call HHH1.
>>>>
>>>> It is empirically proven that this changes their behavior
>>>> and the behavior of DDD.
>>>>
>>>
>>> You say a lot about things that are "empirically proven" and without 
>>> exception they are never "proven" at all.
>>>
>>
>> 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.

> 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.

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.

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.


> 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.)
> 

*I have said this about 500 times in the last three years*
DDD calls HHH(DDD) in recursive simulation and does
not call HHH1(DDD) in recursive simulation.

>>
>> _DDD()
>> [00002177] 55         push ebp
>> [00002178] 8bec       mov ebp,esp
>> [0000217a] 6877210000 push 00002177
>> [0000217f] e853f4ffff call 000015d7
>> [00002184] 83c404     add esp,+04
>> [00002187] 5d         pop ebp
>> [00002188] c3         ret
>> Size in bytes:(0018) [00002188]
>>
>> _main()
>> [00002197] 55         push ebp
>> [00002198] 8bec       mov ebp,esp
>> [0000219a] 6877210000 push 00002177
>> [0000219f] e863f3ffff call 00001507
>> [000021a4] 83c404     add esp,+04
>> [000021a7] 33c0       xor eax,eax
>> [000021a9] 5d         pop ebp
>> [000021aa] c3         ret
>> Size in bytes:(0020) [000021aa]
>>
========== REMAINDER OF ARTICLE TRUNCATED ==========