Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Hypothetical possibilities -- I reread this again more carefully
Date: Sat, 20 Jul 2024 23:51:07 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <6883b0a9674975998092c404f9eaa331ad1556b9@i2pn2.org>
References: <v7gl30$3j9fi$1@dont-email.me> <v7h1fl$3lcvq$3@dont-email.me>
 <v7h224$3li66$3@dont-email.me>
 <e975eef57ba6d3d4cc790818c05b7165443f7ce4@i2pn2.org>
 <v7h5b2$3m6kq$2@dont-email.me>
 <73e4850d3b48903cf85b2967ba713aced98caf96@i2pn2.org>
 <v7h9on$3muu0$1@dont-email.me>
 <09536cf44fc4c3d14b37641cf8fdc9e8a8c24580@i2pn2.org>
 <v7hept$3o0be$1@dont-email.me>
 <97884acd35091ddd67bda892c7a3dd28e188f760@i2pn2.org>
 <v7hftt$3o7r5$1@dont-email.me>
 <f74209ef7d87b6f7891e4a2b89cc18bfe7233810@i2pn2.org>
 <v7hkb2$3otgn$1@dont-email.me>
 <1c5729ae6d0a7bca84d24eec9f85bf30de70e3d9@i2pn2.org>
 <v7hnu6$3pd9s$1@dont-email.me>
 <f0dda3e0d0e85081d8ce0cdd494f5f1f8f8c89e3@i2pn2.org>
 <v7huen$3u1jc$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Jul 2024 03:51:07 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3938152"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v7huen$3u1jc$3@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 8013
Lines: 168

On 7/20/24 11:14 PM, olcott wrote:
> On 7/20/2024 8:46 PM, Richard Damon wrote:
>> On 7/20/24 9:23 PM, olcott wrote:
>>> On 7/20/2024 8:01 PM, Richard Damon wrote:
>>>> On 7/20/24 8:21 PM, olcott wrote:
>>>>> On 7/20/2024 7:05 PM, Richard Damon wrote:
>>>>>> On 7/20/24 7:06 PM, olcott wrote:
>>>>>>> On 7/20/2024 6:00 PM, Richard Damon wrote:
>>>>>>>> On 7/20/24 6:47 PM, olcott wrote:
>>>>>>>>> On 7/20/2024 5:11 PM, Richard Damon wrote:
>>>>>>>>>> On 7/20/24 5:21 PM, olcott wrote:
>>>>>>>>>>> On 7/20/2024 4:06 PM, joes wrote:
>>>>>>>>>>>> Am Sat, 20 Jul 2024 15:05:53 -0500 schrieb olcott:
>>>>>>>>>>>>> On 7/20/2024 2:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/20/24 3:09 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/20/2024 2:00 PM, Fred. Zwarts wrote:
>>>>>>>>>>>>>>>> Op 20.jul.2024 om 17:28 schreef olcott:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (a) Termination Analyzers / Partial Halt Deciders must 
>>>>>>>>>>>>>>>>> halt this is
>>>>>>>>>>>>>>>>> a design requirement.
>>>>>>>>>>>>>>>>> (b) Every simulating termination analyzer HHH either 
>>>>>>>>>>>>>>>>> aborts the
>>>>>>>>>>>>>>>>> simulation of its input or not.
>>>>>>>>>>>>>>>>> (c) Within the hypothetical case where HHH does not 
>>>>>>>>>>>>>>>>> abort the
>>>>>>>>>>>>>>>>> simulation of its input {HHH, emulated DDD and executed 
>>>>>>>>>>>>>>>>> DDD}
>>>>>>>>>>>>>>>>> never stop running.
>>>>>>>>>>>>>>>>> This violates the design requirement of (a) therefore 
>>>>>>>>>>>>>>>>> HHH must abort
>>>>>>>>>>>>>>>>> the simulation of its input.
>>>>>>>>>>>> You missed a couple details:
>>>>>>>>>>>> A terminating input shouldn't be aborted, or at least not 
>>>>>>>>>>>> classified
>>>>>>>>>>>> as not terminating. Terminating inputs needn't be aborted; 
>>>>>>>>>>>> they and the
>>>>>>>>>>>> simulator halt on their own.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And when it aborts, the simulation is incorrect. When 
>>>>>>>>>>>>>>>> HHH aborts and
>>>>>>>>>>>>>>>> halts, it is not needed to abort its simulation, because 
>>>>>>>>>>>>>>>> it will halt
>>>>>>>>>>>>>>>> of its own.
>>>>>>>>>>>>>>> So you are trying to get away with saying that no HHH 
>>>>>>>>>>>>>>> ever needs to
>>>>>>>>>>>>>>> abort the simulation of its input and HHH will stop running?
>>>>>>>>>>>> Pretty much.
>>>>>>>>>>>>>> It is the fact that HHH DOES abort its simulation that 
>>>>>>>>>>>>>> makes it not
>>>>>>>>>>>>>> need to.
>>>>>>>>>>>>> No stupid it is not a fact that every HHH that can possibly 
>>>>>>>>>>>>> exist aborts
>>>>>>>>>>>>> its simulation.
>>>>>>>>>>>> I thought they all halt after a finite number of steps?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void DDD()
>>>>>>>>>>> {
>>>>>>>>>>>     HHH(DDD);
>>>>>>>>>>>     return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> DDD correctly simulated by pure function HHH cannot
>>>>>>>>>>> possibly reach its own return instruction.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Wrong.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You know that you are lying about this as you admit below:
>>>>>>>>
>>>>>>>> Nope, YOU just don't what the words mean, and reckless disregard 
>>>>>>>> the teaching you have been getting, which makes your errors not 
>>>>>>>> just honest mistakes but reckless pathological lies.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> It may be that the simulation by HHH never reaches that point, 
>>>>>>>>>
>>>>>>>>>> but if HHH aborts its simuliaton and returns (as required for 
>>>>>>>>>> it to be a decider) then the behavior of DDD 
>>>>>>>>>
>>>>>>>>> Simulated by HHH is to Die, stop running, no longer function.
>>>>>>>>
>>>>>>>> Nope, HHH is NOT the "Machine" that determines what the code 
>>>>>>>> does, so can not "Kill" it.
>>>>>>>>
>>>>>>>
>>>>>>> So you are trying to get away with the lie
>>>>>>> that an aborted simulation keeps on running.
>>>>>>>
>>>>>>
>>>>>> No, but the BEHAVIOR of the program does, and that is what matters.
>>>>>
>>>>> So you agree that DDD correctly simulated by any pure function
>>>>> HHH cannot possibly reach its own return instruction?
>>>>>
>>>>>
>>>>
>>>> No, I will let you claim (without proof, so we can argue tha later) 
>>>> that the simulation by HHH of DDD does not reach the return, but the 
>>>> behavior of the DDD simuliated by HHH continues, 
>>>
>>> We are talking about real hardware here not figments
>>> of your imagination.
>>>
>>
>> No, you are not. The "Hardware" would be the actual CPU chip which 
>> never stops the program when it is running. A Simulator is just a 
>> piece of software running on it, and what it does can't affect the 
>> behavior of the actual CPU running the program.
>>
>>
>>> When an actual x86 emulator stops emulating its input
>>> this emulated input immediately stops running.
>>>
>>
>> Nope, that is you stupidity where you confuse the observation for the 
>> facts.
>>
>> It has been told to you MANY times, but it seems that you just can not 
>> understand it.
>>
>> The SIMULATION is an observation of the program, that if it stops 
>> doesn't affect the actual behavior of the program in question.
>>
> 
> *If the simulator stops simulating then the simulated stops running*

No, the SIMULA*TION* stops running, the SIMULATED (which is the actual 
program) behaviof continues.

Does you computer program stop at a point just because someone aborted a 
simulation at that poiint?

> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> DDD *correctly simulated* by pure function HHH cannot
> possibly reach its own return instruction.
> 
> 

But HHH doesn't DO a "correct simulation" if it ever aborts and returns 
the answer about not halting.

I guess you just don't know what "correct" means.

You are nothing but a pathetic ignorant pathological liar that has shows 
that he has wasted his life by beliving his own lies.


The halting problem, BY ITS DEFINITION, as about a decider deciding from 
an input representing the program to be decided on.

Since you claim the input doesn't represent a program, it can't be a 
Halt Decider.

A program include all of the code that it uses.
========== REMAINDER OF ARTICLE TRUNCATED ==========