Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <abc@def.com>
Newsgroups: comp.theory
Subject: Re: behavior and description --- All of the code is here it is just
 hard to find
Date: Wed, 7 Aug 2024 07:59:06 -0500
Organization: A noiseless patient Spider
Lines: 205
Message-ID: <v8vr2q$32fso$1@dont-email.me>
References: <v8tcqm$1l0av$1@dont-email.me>
 <9cdb7748ed3906718c6fa7354c81479c24c76885@i2pn2.org>
 <v8tlov$1nl6s$1@dont-email.me>
 <98c9d58d07784afeb7df85b85d468edc2c5a82ab@i2pn2.org>
 <v8ujp7$20c5q$1@dont-email.me>
 <931e370770170d2392a73c564552d84270526201@i2pn2.org>
 <v8uncm$255gv$2@dont-email.me>
 <15ded861fa978eb287e35a859118e7ed48ae6d84@i2pn2.org>
 <v8uoj6$25e3e$1@dont-email.me>
 <e622a920b2fbcce6b0d18be5a0265aa16ec4c7b5@i2pn2.org>
 <v8uqns$25lht$1@dont-email.me>
 <e3665dd986f538a33e981d1ca531ccba855f2790@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 07 Aug 2024 14:59:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f6826d85dca534e829aa60949a8b0d61";
	logging-data="3227544"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+odgkrLmrdqXGPycuqqSU8"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:cid5JyLEJlU6cOmlF/MvcCqLJ6k=
In-Reply-To: <e3665dd986f538a33e981d1ca531ccba855f2790@i2pn2.org>
Content-Language: en-US
Bytes: 9491

On 8/7/2024 6:25 AM, Richard Damon wrote:
> On 8/6/24 11:47 PM, olcott wrote:
>> On 8/6/2024 10:21 PM, Richard Damon wrote:
>>> On 8/6/24 11:10 PM, olcott wrote:
>>>> On 8/6/2024 10:00 PM, Richard Damon wrote:
>>>>> On 8/6/24 10:49 PM, olcott wrote:
>>>>>> On 8/6/2024 9:27 PM, Richard Damon wrote:
>>>>>>> On 8/6/24 9:48 PM, olcott wrote:
>>>>>>>> On 8/6/2024 8:38 PM, Richard Damon wrote:
>>>>>>>>> On 8/6/24 1:16 PM, olcott wrote:
>>>>>>>>>> On 8/6/2024 12:02 PM, joes wrote:
>>>>>>>>>>> Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:
>>>>>>>>>>>> Understanding that DDD correctly simulated by HHH cannot 
>>>>>>>>>>>> possibly reach
>>>>>>>>>>>> its own "return" instruction is a mandatory prerequisite to 
>>>>>>>>>>>> further
>>>>>>>>>>>> discussion.
>>>>>>>>>>
>>>>>>>>>>> There is nothing to discuss after agreeing with your conclusion.
>>>>>>>>>>>
>>>>>>>>>>>> Everyone remains convinced that HHH must report on the 
>>>>>>>>>>>> behavior of the
>>>>>>>>>>>> computation that itself is contained within and not the 
>>>>>>>>>>>> behavior that
>>>>>>>>>>>> its finite string input specifies.
>>>>>>>>>>
>>>>>>>>>>> The construction is not recursive if the description does not 
>>>>>>>>>>> describe
>>>>>>>>>>> the surrounding computation. And that behaviour cannot depend 
>>>>>>>>>>> on the
>>>>>>>>>>> decider, as they should all give the same answer.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That is far too vague.
>>>>>>>>>>
>>>>>>>>>> DDD correctly emulated by HHH according to the semantics
>>>>>>>>>> of the x86 programming language specifies a single exact
>>>>>>>>>> sequence of state changes. None of these state changes
>>>>>>>>>> ends up at the x86 machine language address of the "ret"
>>>>>>>>>> instruction of DDD.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Which would be meaningful if HHH actual did a correct emulation 
>>>>>>>>> of the 
>>>>>>>>
>>>>>>>> HHH does emulate the exact sequence that the machine code
>>>>>>>> of DDD specifies. This has been conclusively proven by
>>>>>>>> the execution traces that the two instances of HHH provide.
>>>>>>>
>>>>>>> Nope, because it didn't emulate the call instruction properly.
>>>>>>>
>>>>>>
>>>>>> It is proved that it does emulate the call instruction
>>>>>> properly by the correct execution trace of the second
>>>>>> DDD derived by the second HHH.
>>>>>
>>>>> Nope, just proves you don't know what you are talking about.
>>>>>
>>>>
>>>> Because your rebuttals have always been pure bluster
>>>
>>> No, YOUR rebuttal have been pure bluster that have avoided answering 
>>> my challenges, thus effectively ADMITTING that you arte just a liar.
>>>
>>>> you have only used double-talk and misdirection to dodge
>>>> pointing out any mistake in the following:
>>>
>>> How about the trace that HHH generates shouldn't start with the code 
>>> of main, since that isn't what HHH starts simulating, thus your 
>>> claims about the trace generate by HHH can not be supported by 
>>> something elses trace.
>>>
>>
>> That is a very ignorant thing to say.
> 
> NO, it is the truth.
> 
>>
>>> Second, the CORRECT emulation of a "call" instruciton should show the 
>>> instruction of the routine called.
>>>
>>
>> The extra 200 pages prove to be too confusing. The
>> fact that after DDD calls HHH we do get the correct
>> execution trace that would be derived from this call
>> proves that the second HHH was called.
> 
> Nope, they show you wrong.
> 
> HOW can the emulation that HHH is doing show code that HHH doesn't look at?
> 
> Your failure to answer (may times from the past) just prove that you 
> KNOW that you have been lying, but don't want to face it.
> 
> Sorry, you are just proving your stupidity
> 
>>
>> I will highlight all of the code so that you
>> can see the each instruction both HHH are shown
>> and both DDD are shown. I will use four different
>> colors.
> 
> Since the trace isn't the right trace, that doesn't mean anything.
> 
> And, where are the colors, you said there would be colors.
> 
> Did you not know that this group is text only?
> 
>>
>> It really have already been 100% totally proven in
>> that after DDD calls HHH we to get the correct
>> execution trace of DDD emulated by this second HHH
>>
>>> Thus, a "Call 000015d2" *MUST* be followed by the instruction AT 
>>> 000015d2, and not "Begin Local Halt Decider Simulation"
>>>
>>> Since you have just been repeating this smae ERROR over and over, you 
>>> are just proving that you just don't care about the truth, but are 
>>> just repeating your same LIES over and over and over, securing your 
>>> place in Gehenna.
>>>
>>  >>>> _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
>>>>
>>>> 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)
>>>> New slave_stack at:14e2ec
>>
>> This execution trace proves that the second HHH did
>> emulate the second DDD correctly:
>>
> 
> Nope, where is the fact that that either HHH has the power to stop any 
========== REMAINDER OF ARTICLE TRUNCATED ==========