Path: ...!feeds.phibee-telecom.net!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: Hypothetical possibilities --- Complete Proof
Date: Fri, 2 Aug 2024 22:36:48 -0500
Organization: A noiseless patient Spider
Lines: 427
Message-ID: <v8k8kg$38685$3@dont-email.me>
References: <v7gl30$3j9fi$1@dont-email.me> <v7vlbj$2ofet$1@dont-email.me>
 <v80a2u$2rabc$4@dont-email.me> <v825jo$39i9l$1@dont-email.me>
 <v82u9d$3dftr$3@dont-email.me> <v8306v$3c7$1@news.muc.de>
 <v83161$3dftr$11@dont-email.me> <v84udt$3rp4t$1@dont-email.me>
 <v8bc6j$159av$1@dont-email.me>
 <ea673a5b4ed43fbddf938c69bd013b0cf2ca325d@i2pn2.org>
 <v8c6kb$1de3l$1@dont-email.me>
 <9f3112e056ad6eebf35f940c34b802b46addcad4@i2pn2.org>
 <v8cde0$1ecgo$1@dont-email.me> <v8ctgt$1gbu7$4@dont-email.me>
 <v8dkc3$1kii7$3@dont-email.me> <v8e55v$1nrnh$1@dont-email.me>
 <v8e9vu$1oqd7$1@dont-email.me> <v8fftq$22ege$3@dont-email.me>
 <v8fuj5$24rl1$10@dont-email.me> <v8g1j7$24u77$6@dont-email.me>
 <v8g2jl$26d7d$1@dont-email.me> <v8ibf5$2p7ho$1@dont-email.me>
 <s3CdnbweXt8ohDD7nZ2dnZfqn_ednZ2d@brightview.co.uk>
 <a287d1fc2c1fc90d4381e46eae05287b96e801b9@i2pn2.org>
 <-Vednah5VvbtwTD7nZ2dnZfqnPSdnZ2d@brightview.co.uk>
 <449d4de351f2890de028f96a3ab5a758c9ce6e72@i2pn2.org>
 <dY-cnYDtsshNAjD7nZ2dnZfqnPSdnZ2d@brightview.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 03 Aug 2024 05:36:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6697133516c971b81fd53169bb6a94ea";
	logging-data="3414277"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18fzzi0auQIj9EMeRC8QE1A"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:woygkw6ZIGFivRbUV6dZdzNEbYI=
Content-Language: en-US
In-Reply-To: <dY-cnYDtsshNAjD7nZ2dnZfqnPSdnZ2d@brightview.co.uk>
Bytes: 22759

On 8/2/2024 10:11 PM, Mike Terry wrote:
> On 03/08/2024 00:12, Richard Damon wrote:
>> On 8/2/24 6:23 PM, Mike Terry wrote:
>>> On 02/08/2024 19:25, Richard Damon wrote:
>>>> On 8/2/24 1:39 PM, Mike Terry wrote:
>>>>> On 02/08/2024 11:12, Mikko wrote:
>>>>>> On 2024-08-01 13:29:24 +0000, olcott said:
>>>>>>
>>>>>>> On 8/1/2024 8:12 AM, Fred. Zwarts wrote:
>>>>>>>> Op 01.aug.2024 om 14:20 schreef olcott:
>>>>>>>>> On 8/1/2024 3:10 AM, Fred. Zwarts wrote:
>>>>>>>>>> Op 31.jul.2024 om 23:23 schreef olcott:
>>>>>>>>>>> On 7/31/2024 3:01 PM, Fred. Zwarts wrote:
>>>>>>>>>>>> Op 31.jul.2024 om 17:14 schreef olcott:
>>>>>>>>>>>>> On 7/31/2024 3:44 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>> Op 31.jul.2024 om 06:09 schreef olcott:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   machine   stack     stack     machine    assembly
>>>>>>>>>>>>>>>   address   address   data      code       language
>>>>>>>>>>>>>>>   ========  ========  ========  =========  =============
>>>>>>>>>>>>>>> [00002192][00103820][00000000] 55         push ebp
>>>>>>>>>>>>>>> [00002193][00103820][00000000] 8bec       mov ebp,esp
>>>>>>>>>>>>>>> [00002195][0010381c][00002172] 6872210000 push 00002172 ; 
>>>>>>>>>>>>>>> push DDD
>>>>>>>>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; 
>>>>>>>>>>>>>>> call HHH(DDD)
>>>>>>>>>>>>>>> New slave_stack at:1038c4
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We don't show any of HHH and show the execution trace of
>>>>>>>>>>>>>>> of just DDD assuming that HHH is an x86 emulator.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This assumption is incorrect if it means that HHH is an 
>>>>>>>>>>>>>> unconditional simulator that does not abort.
>>>>>>>>>>>>> This algorithm is used by all the simulating termination 
>>>>>>>>>>>>> analyzers:
>>>>>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 
>>>>>>>>>>>>> 10/13/2022>
>>>>>>>>>>>>>      *If simulating halt decider H correctly simulates its 
>>>>>>>>>>>>> input D*
>>>>>>>>>>>>>      *until H correctly determines that its simulated D 
>>>>>>>>>>>>> would never*
>>>>>>>>>>>>>      *stop running unless aborted* then
>>>>>>>>>>>>>
>>>>>>>>>>>>>      H can abort its simulation of D and correctly report 
>>>>>>>>>>>>> that D
>>>>>>>>>>>>>      specifies a non-halting sequence of configurations.
>>>>>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 
>>>>>>>>>>>>> 10/13/2022>
>>>>>>>>>>>>
>>>>>>>>>>>> So, Sipser only agreed to a correct simulation, not with an 
>>>>>>>>>>>> incorrect simulation that violates the semantics of the x86 
>>>>>>>>>>>> language by skipping the last few instructions of a halting 
>>>>>>>>>>>> program.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> int DD()
>>>>>>>>>>> {
>>>>>>>>>>>    int Halt_Status = HHH(DD);
>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>    return Halt_Status;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>    HHH(DD);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> DD correctly emulated by HHH cannot possibly reach its own
>>>>>>>>>>> second line. I switched to DDD correctly emulated by HHH
>>>>>>>>>>
>>>>>>>>>> But it has been proven that no such HHH exists that simulates 
>>>>>>>>>> itself correctly. So, talking about a correct simulation by 
>>>>>>>>>> HHH is vacuous word salad.
>>>>>>>>>>
>>>>>>>>>>> because only C experts understood the above example and we
>>>>>>>>>>> never had any of those here.
>>>>>>>>>>
>>>>>>>>>> There are many C experts that looked at it, but you only got 
>>>>>>>>>> critic, because you keep hiding important properties of HHH, 
>>>>>>>>>> which made the conclusion impossible.
>>>>>>>>>
>>>>>>>>> The following is all that is needed for 100% complete proof
>>>>>>>>> that HHH did emulate DDD correctly according to the semantics
>>>>>>>>> of the x86 language and did emulate itself emulating DDD
>>>>>>>>> according to these same semantics.
>>>>>>>>
>>>>>>>> You are repeating the same false claim with out any self- 
>>>>>>>> reflection. It has been pointed out that there are many errors 
>>>>>>>> in this proof.
>>>>>>>> Why repeating such errors?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> _DDD()
>>>>>>>>> [00002172] 55         push ebp      ; housekeeping
>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping
>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>>>>>>> [0000217f] 83c404     add esp,+04
>>>>>>>>> [00002182] 5d         pop ebp
>>>>>>>>> [00002183] c3         ret
>>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>>
>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored 
>>>>>>>>> at:1138cc
>>>>>>>>> [00002172][001138bc][001138c0] 55         push ebp      ; 
>>>>>>>>> housekeeping
>>>>>>>>> [00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; 
>>>>>>>>> housekeeping
>>>>>>>>> [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
>>>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call 
>>>>>>>>> HHH(DDD)
>>>>>>>>
>>>>>>>> The trace stops and hides what happens when 000015d2 is called.
>>>>>>>> Olcott is hiding the conditional branch instructions in the 
>>>>>>>> recursion.
>>>>>>>>
>>>>>>>
>>>>>>> *Here is the full trace where nothing is hidden*
>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
>>>>>>
>>>>>> On page 36 of that "trace"
>>>>>>     [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
>>>>>> is not followed by the trace of 00000777. Instead the trace continues
>>>>>> with the next instruction after the return without any comment about
>>>>>> the omission. Meaning of 00000777 is not told.
>>>>>>
>>>>>
>>>>> 777 is the address of Allocate, which is one of PO's "primative 
>>>>> ops" within his "computing model". (Similar to his DebugStep().)
>>>>>
>>>>> It is implemented inside x86utm.exe (his COFF obj code runner), not 
>>>>> in the user code DDD/HHH/etc. in the obj file, and so we would not 
>>>>> expect to see any trace entries for its internals.  When the op 
>>>>> concludes, rax has the address of the allocated memory, which is 
>>>>> consistent with how a normal function would have returned the address.
>>>>>
>>>>> You can say correctly that PO has not explained this, but then he 
>>>>> provided the full trace under protest, so it's understandable that 
>>>>> he has not previously explained everything in it.  I'm surprised 
>>>>> that his response to your post was both to ignore the question and 
>>>>> accuse you of playing sadistic head games, as the question was 
>>>>> perfectly sensible.
>>>>>
>>>>> You can look up the 777 address in the listing at the start of the 
>>>>> trace and it's there along with a bunch of other routines which 
>>>>> appear to just return without doing anything - those are all PO's 
>>>>> primitive ops.  If you feel a need to understand exactly what they 
>>>>> do, you'll need to check his source code!  (Although for Allocate 
>>>>> there is no big surprise...)
>>>>>
>>>>>
>>>>> So your observation isn't really a problem beyond not being 
>>>>> properly explained.  An actual problem seen in his trace data is 
>>>>> that the simulation of DDD does not track the behaviour of the 
>>>>> unsimulated DDD. I.e. his simulation is incorrect.  (PO knows about 
>>>>> that but claims it doesn't matter, although on other occasions he 
>>>>> still claims the simulation is correct.)
>>>>>
>>>>>
>>>>> Mike.
>>>>>
========== REMAINDER OF ARTICLE TRUNCATED ==========