Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: Hypothetical possibilities --- stupid rebuttal ---
Date: Wed, 31 Jul 2024 10:44:13 +0200
Organization: A noiseless patient Spider
Lines: 146
Message-ID: <v8ctgt$1gbu7$4@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 31 Jul 2024 10:44:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ecb5db382df1907940b8ec29fc629507";
	logging-data="1585095"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/nDiluDAL5OLEZrEnoO+z3"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:540u/sJEJzPdnvE1yyKEroyVAw4=
Content-Language: en-GB
In-Reply-To: <v8cde0$1ecgo$1@dont-email.me>
Bytes: 8059

Op 31.jul.2024 om 06:09 schreef olcott:
> On 7/30/2024 10:19 PM, Richard Damon wrote:
>> On 7/30/24 10:13 PM, olcott wrote:
>>> On 7/30/2024 8:21 PM, Richard Damon wrote:
>>>> On 7/30/24 2:42 PM, olcott wrote:
>>>>> On 7/28/2024 3:10 AM, Mikko wrote:
>>>>>> On 2024-07-27 14:45:21 +0000, olcott said:
>>>>>>
>>>>>>> On 7/27/2024 9:28 AM, Alan Mackenzie wrote:
>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 7/27/2024 1:54 AM, Mikko wrote:
>>>>>>>>>> If a simulator correctly simulates a finite number of 
>>>>>>>>>> instructions
>>>>>>>>>> where x86 program specifies an execution of an infinite number of
>>>>>>>>>> instructions then the simulation deviates from x86 semantics 
>>>>>>>>>> at the
>>>>>>>>>> point where the simulation stops but the x86 semantics specify
>>>>>>>>>> countinuation.
>>>>>>>>
>>>>>>>>
>>>>>>>>> In other words you believe that instead of recognizing a
>>>>>>>>> non-halting behavior pattern, then aborting the simulation
>>>>>>>>> and rejecting the input as non-halting the termination
>>>>>>>>> analyzer should just get stuck in recursive simulation?
>>>>>>>>
>>>>>>>> You're doing it again.  "In other words" is here a lie; you've just
>>>>>>>> replaced Mikko's words with something very different.
>>>>>>>>
>>>>>>>
>>>>>>> He just said that the simulation of a non-terminating input
>>>>>>> is incorrect unless it is simulated forever.
>>>>>>
>>>>>> I said it deviates form the x86 semantics. I didn't say whether it is
>>>>>> incorrect to deviate from x86 semantics. 
>>>>>
>>>>> The measure of DDD correctly emulated by HHH
>>>>>     until HHH correctly determines that its emulated DDD would never
>>>>>      stop running unless aborted...
>>>>>
>>>>> is that the emulation of DDD by HHH
>>>>> *DOES NOT DEVIATE FROM THE X86 SEMANTICS*
>>>>
>>>> Which frst means it must emulate per the x86 semantics, which means 
>>>
>>>
>>>> the call to HHH must be followed by the emulation of the x86 
>>>> instructions of  HHH, not something else.
>>>>
>>>
>>> *The call to HHH HAS ALWAYS BEEN FREAKING FOLLOWED*
>>> *by the emulation of the x86 instructions of HHH*
>>
>> Then why don't you show it then
>>
>>>
>>> It seems best proven by this source-code
>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>
>>> This level of detail was never required because we
>>> could always see from the trace of DDD that it must
>>> have been a call to an x86 emulator or we would
>>> never have gotten to the first line of DDD again.
>>>
>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
>>> We can see from the first page of the trace on
>>> page 38 of the file that DDD calls HHH(DDD) and
>>> the next line is the address of HHH.
>>
>> But that call is from MAIN not DDD.
>>
> 
> Ah you are right. So now you see what I mean.
> They are all mixed together just like I expected
> The first five lines of HHH are on pages 44-49
> 
> That is why I always presented it this way.
> 
> _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]
> 
> _main()
> [00002192] 55         push ebp
> [00002193] 8bec       mov ebp,esp
> [00002195] 6872210000 push 00002172 ; push DDD
> [0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
> [0000219f] 83c404     add esp,+04
> [000021a2] 50         push eax
> [000021a3] 6843070000 push 00000743
> [000021a8] e8b5e5ffff call 00000762
> [000021ad] 83c408     add esp,+08
> [000021b0] 33c0       xor eax,eax
> [000021b2] 5d         pop ebp
> [000021b3] c3         ret
> Size in bytes:(0034) [000021b3]
> 
>   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. In fact, it is a simulator with 
conditional branch instructions, that aborts its simulation after a few 
recursive cycles.
Probably olcott hides this trace on purpose to hide the conditional 
branch instructions.

> 
> *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)
> 
> If the emulated call to HHH(DDD) from the emulated DDD wasn't correct
> then how the hell did it get to the first line of DDD shown below?
> 
> [00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
> [00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
> [00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
> *Local Halt Decider: Infinite Recursion Detected Simulation Stopped*

An incorrect message, probably because of the false assumption the HHH 
is an unconditional simulator that never aborts, where it is known to be 
a conditional simulator that aborts after two cycles.
Olcott is dreaming again of a HHH that does not abort and runs forever.
Dreams are no substitute for logic proofs.
No matter how much olcott wants it to be correct, or how many times 
olcott repeats that it is correct, it does not change the fact that such 
a simulation is incorrect, because it is unable to reach the end of a 
halting program.