Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Hypothetical possibilities --- Complete Proof
Date: Fri, 2 Aug 2024 14:25:48 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <a287d1fc2c1fc90d4381e46eae05287b96e801b9@i2pn2.org>
References: <v7gl30$3j9fi$1@dont-email.me> <v7led6$kacj$1@dont-email.me>
 <v7lsg5$luh0$5@dont-email.me> <v7nm9m$1433k$1@dont-email.me>
 <v7ofe7$17h8r$6@dont-email.me> <v7qfu0$1m6vf$1@dont-email.me>
 <v7r040$1onhe$3@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 2 Aug 2024 18:25:48 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1215791"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <s3CdnbweXt8ohDD7nZ2dnZfqn_ednZ2d@brightview.co.uk>
Content-Language: en-US
Bytes: 9977
Lines: 175

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

But the bigger error that totally negates this trace is if you at where 
it begins, it is at program address 00002197, which just the page before 
is shown to be the address of _main.

Since HHH was not given the address of main to start with, this can not 
be the trace that HHH itself is generating and looking at, but is 
instead the trace of the running of that top level HHH.

Since that shows the trace isn't what he claims it is, nothing it says 
means anything for his argument.

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