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: DDD emulated by HHH --- (does not refer to prior posts)
Date: Thu, 29 Aug 2024 18:52:31 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <32f46e1f96e495d24419481b810a59e02b88e4fe@i2pn2.org>
References: <vajdta$2qe9s$1@dont-email.me> <vak3a0$2teq9$1@dont-email.me>
 <vakhnf$302rl$2@dont-email.me> <vamk7l$3d7ki$1@dont-email.me>
 <van3v7$3f6c0$5@dont-email.me> <vap7b1$3sobs$1@dont-email.me>
 <vapvbc$3vumk$5@dont-email.me> <vaqant$22im$1@dont-email.me>
 <vaqbbq$28ni$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 29 Aug 2024 22:52:31 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="189249"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vaqbbq$28ni$1@dont-email.me>
Bytes: 4980
Lines: 106

On 8/29/24 1:32 PM, olcott wrote:
> On 8/29/2024 12:22 PM, Fred. Zwarts wrote:
>> Op 29.aug.2024 om 16:07 schreef olcott:
>>> On 8/29/2024 2:17 AM, Mikko wrote:
>>>> On 2024-08-28 12:08:06 +0000, olcott said:
>>>>
>>>>> On 8/28/2024 2:39 AM, Mikko wrote:
>>>>>> On 2024-08-27 12:44:31 +0000, olcott said:
>>>>>>
>>>>>>> On 8/27/2024 3:38 AM, Fred. Zwarts wrote:
>>>>>>>> Op 27.aug.2024 om 04:33 schreef olcott:
>>>>>>>>> This is intended to be a stand-alone post that does not
>>>>>>>>> reference anything else mentioned in any other posts.
>>>>>>>>>
>>>>>>>>> void DDD()
>>>>>>>>> {
>>>>>>>>>    HHH(DDD);
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _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 we assume that:
>>>>>>>>> (a) HHH is an x86 emulator that is in the same memory space as 
>>>>>>>>> DDD.
>>>>>>>>> (b) HHH emulates DDD according to the semantics of the x86 
>>>>>>>>> language.
>>>>>>>>>
>>>>>>>>> then we can see that DDD emulated by HHH cannot possibly get past
>>>>>>>>> its own machine address 0000217a.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, we see. In fact DDD is not needed at all.
>>>>>>>
>>>>>>> A straw man fallacy (sometimes written as strawman) is the 
>>>>>>> informal fallacy of refuting an argument different from the one 
>>>>>>> actually under discussion...
>>>>>>> https://en.wikipedia.org/wiki/Straw_man
>>>>>>
>>>>>> You should also point a link to the equivocation fallacy. You use it
>>>>>> more often than straw man.
>>>>>
>>>>> Isomorphism is not equivocation
>>>>
>>>> The use of HHH for many purposes (a specific program, an unpsecified
>>>> memeber of a set of programs, a hypothetical program) is.
>>>>
>>>> Your first posting looked like you were going to apply equivocation
>>>> later in the discussion. Now, after several later messages, it seems
>>>> that you want to apply the fallacy of "moving the goal posts" instead.
>>>>
>>>
>>> void EEE()
>>> {
>>>    HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> HHH correctly predicts what the behavior of EEE would
>>> be if this HHH never aborted its emulation of EEE.
>>>
>>> void DDD()
>>> {
>>>    HHH(DDD);
>>>    return;
>>> }
>>>
>>> HHH correctly predicts what the behavior of DDD would
>>> be if this HHH never aborted its emulation of DDD.
>> Which is incorrect, because HHH is not allowed to change the input. 
>> The simulating HHH may abort, but it may not ignore the fact that the 
>> input (the simulated HHH) is coded to abort when it sees the 'special 
>> condition'. Otherwise it would decide about a non-input, which is not 
>> allowed.
>>
> 
> *I told you this too many times so you must be a liar*
> No DDD ever reaches its "return" instruction no matter
> what-the-Hell that HHH does, thus DDD CANNOT POSSIBLY HALT.

But thehy *DO*

It is the EMULATION of DDD by HHH that never reaches the return 
statement, not DDD itself.

You are just using the wrong definitions. showing your stupidity.

> 
>> In the same way as HHH is not allowed to change the code of EEE when 
>> it aborts EEE. The simulating HHH may abort and predict the behaviour 
>> of the *unchanged* input would be.
>>
>> In other words: HHH should process its input as if it was not its own 
>> code. In fact, that is what HHH1 does and that is correct.
>>
> 
>