Path: ...!news.roellig-ltd.de!open-news-network.org!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: THREE DIFFERENT QUESTIONS
Date: Fri, 18 Oct 2024 22:19:44 -0500
Organization: A noiseless patient Spider
Lines: 186
Message-ID: <vev8gg$3me0u$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>
 <vetq7u$3b8r2$1@dont-email.me>
 <522ecce215e636ddb7c9a1f75bff1ba466604cc5@i2pn2.org>
 <veuvt9$3hnjq$1@dont-email.me>
 <87634d01e18903c744d109aaca3a20b9ce4278bb@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 19 Oct 2024 05:19:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a2f4596ff028e636d7320aa11ac5f85c";
	logging-data="3880990"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+zngpL6wQv2TMBILg2aBAz"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:tapoRyZ8yEwG1nit1NeSwqcJja0=
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 241018-10, 10/18/2024), Outbound message
Content-Language: en-US
In-Reply-To: <87634d01e18903c744d109aaca3a20b9ce4278bb@i2pn2.org>
Bytes: 8149

On 10/18/2024 9:49 PM, Richard Damon wrote:
> On 10/18/24 8:52 PM, olcott wrote:
>> On 10/18/2024 6:06 PM, Richard Damon wrote:
>>> On 10/18/24 10:10 AM, olcott wrote:
>>>> 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.
>>>
>>>
>>> Nope, remember, each of those levels are CONDITIONAL, 
>>
>> *There are THREE different questions here*
>> (1) Can DDD emulated by HHH according to the semantics
>>      of the x86 language possibly reach its machine address
>>      [00002183] no matter what HHH does?
>>
> 
> Ambiguouse question, as pointed out previously.
> 
> A) Do you mean the behavior of the PROGRAM DDD, that HHH has emulated a 
> copy of.
> 
> In that case, the answer is, if HHH aborts its emulation and return, 
> YES, if HHH never aborts its emulation, and thus doesn't ever return an 
> answer to anyone NO.
> 
> B) If you mean, does the emulation done by HHH ever reach that place, no.
> 

We are not asking if the code of HHH reaches inside
the code of DDD. Of course it doesn't this is stupid.

We are asking does any DDD of any DDD/HHH pair of the
infinite set of pairs such that DDD is emulated by HHH
according to the semantics of the x86 language reach its
own return instruction?

> 
>> (2) Does HHH correctly detect and report the above?
> 
> No, because that isn't what you claim HHH is doing, so it can't be 
> correct about that.
> 

In other words you fail to comprehend that DDD failing
to reach its "return" instruction is isomorphic to:

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
 > ... PO really /has/ an H
 > (it's trivial to do for this one case) that correctly determines
 > that P(P) *would* never stop running *unless* aborted.

> We need to look at the two possible interpreations to question 1.
> 
> If you means A, then since HHH says no but the correct answer is yes, it 
> is wrong.
> 
> If you mean B, and you mean your question is can HHH predict that it 
> can't reach the final state, but only needs to be right for this one 
> input, then the problem is the question has become trivial, if it 
> doesn't need to actually know anything about the input, it can just be 
> programmed to say no.
> 

I mean that the execution trace of DDD proves that HHH is correct
to reject DDD as impossibly reaching its own "return" instruction
even if it just guesses.

> Also, we can make a trivial HHH, that just does the absolute minimum, 
> then aborts and returns no unconditionally to be correct, showing your 
> problem isn't interesting.
> 
> Or, your "problem" has left the domain of Program Theory, becuause you 
> don't consider DDD to be an actual program, at which point it also 
> becomes much less interesting.
> 
>>
>> (3) Does HHH do (2) it as a Turing computable function?
>>
> 
> No, because the method your HHH uses isn't possible to be expressed as a 
> Turing Machine with a seperate input tape with the full representatation 
> of the program DDD.
========== REMAINDER OF ARTICLE TRUNCATED ==========