Deutsch   English   Français   Italiano  
<xEydncDTQ97yhD77nZ2dnZfqnPGdnZ2d@brightview.co.uk>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!Xl.tags.giganews.com!local-3.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 26 Jul 2024 03:35:11 +0000
Subject: Re: DDD correctly emulated by HHH is Correctly rejected as
 non-halting V2 ---woefully mistaken rebuttal
Newsgroups: comp.theory
References: <v6rg65$32o1o$3@dont-email.me> <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>
 <v7us2g$2gvh6$1@dont-email.me>
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Date: Fri, 26 Jul 2024 04:35:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.17
MIME-Version: 1.0
In-Reply-To: <v7us2g$2gvh6$1@dont-email.me>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <xEydncDTQ97yhD77nZ2dnZfqnPGdnZ2d@brightview.co.uk>
Lines: 296
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-HCxNJ/pg8hBl6SuC3p4t25mlPSVfAXbHBkzdrnrFVmUQtNHCOnxJRph77Kc4bAqcN4dilslicklXxM2!g5jw5hw7mpkJlwZ3RQKRtu9RXxD/ZhfUAfgBkKdZQEuYoPI5S7T+cWPtS04hYMaMv6lFSbyMSnPq!Qc8BmxTAewcrPFdipOr/sJqFQrE=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 15635

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

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

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

You may have said it 500 times, but it doesn't answer my question!

Look, here is a rough sketch of the two traces side by side just done by hand:

[VIEW WITH FIXED FONT!!]

   HHH1 (DDD)                          HHH (DDD)
   -----------------------------------------------------------------
1 main ()                             main ()
2   HHH1 (DDD)                          HHH (DDD)
4     Simulate (DDD)                      Simulate (DDD)
5     | DDD()                             | DDD()
6     |   HHH (DDD)                       |   HHH (DDD)
7     |     Simulate (DDD)                |     Simulate (DDD)
8     |     | DDD()                       |       DDD()
9     |     |   HHH (DDD)                 |         HHH (DDD)
10    |     |     Simulate (DDD)          Abort
11    |     |       DDD()                 ret 0
12    |     |         HHH (DDD)         ret 0
13    |     Abort
========== REMAINDER OF ARTICLE TRUNCATED ==========