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: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: A state transition diagram proves ... GOOD PROGRESS
Date: Fri, 18 Oct 2024 09:10:04 -0500
Organization: A noiseless patient Spider
Lines: 131
Message-ID: <vetq7u$3b8r2$1@dont-email.me>
References: <ves6p1$2uoln$1@dont-email.me>
 <3232d8a0cc7b5d4bba46321bf682c94573bf1b7c@i2pn2.org>
 <vesemu$2v7sh$1@dont-email.me>
 <a9fb95eb0ed914d0d9775448c005111eb43f2c5b@i2pn2.org>
 <veslpf$34ogr$1@dont-email.me>
 <647fe917c6bc0cfc78083ccf927fe280acdf2f9d@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 18 Oct 2024 16:10:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="038c6a2fd0ca42e5af4fa5df3c3c0f47";
	logging-data="3515234"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Pg+wHFiccO61iPJpBuoLK"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:DOdPmVsXzTBF3PKps8LDjqTlSeM=
X-Antivirus: Norton (VPS 241018-4, 10/18/2024), Outbound message
X-Antivirus-Status: Clean
In-Reply-To: <647fe917c6bc0cfc78083ccf927fe280acdf2f9d@i2pn2.org>
Content-Language: en-US
Bytes: 5820

On 10/18/2024 6:17 AM, Richard Damon wrote:
> On 10/17/24 11:47 PM, olcott wrote:
>> On 10/17/2024 10:27 PM, Richard Damon wrote:
>>> On 10/17/24 9:47 PM, olcott wrote:
>>>> On 10/17/2024 8:13 PM, Richard Damon wrote:
>>>>> On 10/17/24 7:31 PM, olcott wrote:
>>>>>> _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]
>>>>>>
>>>>>> When DDD is correctly emulated by HHH according
>>>>>> to the semantics of the x86 language DDD cannot
>>>>>> possibly reach its own machine address [00002183]
>>>>>> no matter what HHH does.
>>>>>>
>>>>>> +-->[00002172]-->[00002173]-->[00002175]-->[0000217a]--+
>>>>>> +------------------------------------------------------+
>>>>>>
>>>>>> That may not line up that same way when view
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/State_diagram
>>>>>>
>>>>>
>>>>>
>>>>> Except that 0000217a doesn't go to 00002172, but to 000015d2
>>>>>
>>>>
>>>> IS THIS OVER YOUR HEAD?
>>>> What is the first machine address of DDD that HHH
>>>> emulating itself emulating DDD would reach?
>>>>
>>>
>>> Yes, HHH EMULATES the code at that address, 
>>
>> Which HHH emulates what code at which address?
>>
> 
> Everyone, just once, which you should know, but ignore.
> 
> The Emulating HHH sees those addresses at its begining and then never 
> again.
> 
> Then the HHH that it is emulating will see those addresses, but not the 
> outer one that is doing that emulation of HHH.
> 
> Then the HHH that the second HHH is emulating will, but neither of the 
> outer 2 HHH.
> 
> And so on.
> 
> Which HHH do you think EVER gets back to 00002172?
> 
> What instruction do you think that it emulates that would tell it to do so?
> 
> It isn't the call instruction at 0000217a, as that tells it to go into HHH.
> 
> At best the trace is:
> 
> 00002172
> 00002173
> 00002175
> 0000217a
> conditional emulation of 00002172
> conditional emulation of 00002173
> conditional emulation of 00002175
> conditional emulation of 0000217a
> CE of CE of 00002172
> ...
> 

OK great this is finally good progress.

> The "state" never repeats, it is alway a new state, 

Every emulated DDD has an identical process state at every point
in its emulation trace when adjusting for different top of stack values.

> and if HHH decides 
> to abort its emulation, it also should know that every level of 
> condition emulation it say will also do the same thing, 

If I understand his words correctly Mike has already disagreed
with this. Let's see if you can understand my reasoning.

Not exactly. Each HHH can only abort its emulation when its
abort criteria has been met. The outermost HHH can see one
more execution trace than the next inner one thus meets its
abort criteria first.

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.

This seems to indicate that the Turing machine UTM version of
HHH can somehow see each of the state transitions of the DDD
resulting from emulating its own Turing machine description
emulating DDD.

Even though this is a little different for Turing machines it
is equivalent in essence to HHH being able to see the steps of
the DDD resulting from HHH emulating itself emulating this DDD.

*Joes can't seem to understand this*
Only the outer-most HHH meets its abort criteria first, thus
unless it aborts as soon as it meets this criteria none of
them will ever abort.

> and thus the 
> call HHH at 0000217a will be returned from, > and HHH has no idea what 
> will happen after that, so it KNOWS it is ignorant of the answer.
> 

That you don't quite yet understand the preceding points
will make it impossible for you to understand any reply
to the above point.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer