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: behaviour and description
Date: Tue, 6 Aug 2024 21:38:55 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <98c9d58d07784afeb7df85b85d468edc2c5a82ab@i2pn2.org>
References: <v8tcqm$1l0av$1@dont-email.me>
 <9cdb7748ed3906718c6fa7354c81479c24c76885@i2pn2.org>
 <v8tlov$1nl6s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 7 Aug 2024 01:38:55 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1715116"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v8tlov$1nl6s$1@dont-email.me>
Bytes: 2792
Lines: 40

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 
PROGRAM DDD that it is given. SInce it doesn't actual do that, despite 
your attempts to lie about it, your claim doesn't matter.

Since HHH does actual emulate the instructions of HHH when DDD calls it 
(or you haven't shown any evidence that it does, just that x86UTM does 
when it runs HHH) and that it fails to be correct by aborting its 
emulation of DDD, means your arguement is just BOGUS.

YOu are just proving you don't actually understand how the x86 processor 
works, and thus how the language that describes it works.

The trace of the emulation of a call to HHH produce the METHOD that 
generates the result of HHH, not the results of HHH.