Deutsch   English   Français   Italiano  
<35adb477993842e03ae02a0ac99d471d6043b1f5@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: My reviewers think that halt deciders must report on the behavior
 of their caller
Date: Wed, 16 Jul 2025 22:15:52 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <35adb477993842e03ae02a0ac99d471d6043b1f5@i2pn2.org>
References: <101nq32$99vd$1@dont-email.me>
 <1ca786773f9ff02718c66e082bbc4182b36732ab@i2pn2.org>
 <104fduv$2n8gq$2@dont-email.me>
 <4cb5d16be8d1e6549823f35081050e7dad462da2@i2pn2.org>
 <104gi8j$2uc68$2@dont-email.me>
 <152859a4a4ef31aa45580e873eb6970c34b97ef9@i2pn2.org>
 <104hmb5$35gkb$1@dont-email.me>
 <f12be9e3474cf08b01ae1a4381f77205bbac1da3@i2pn2.org>
 <104i15g$36mma$2@dont-email.me>
 <c0cf1db3b26b15b6b2df8a22e9f415c10aee59a7@i2pn2.org>
 <104jcqn$3jrpl$10@dont-email.me> <104lb03$13ioh$2@dont-email.me>
 <104lp8o$7l4q$7@dont-email.me> <104o662$18h8g$1@dont-email.me>
 <104oj2v$t0u4$7@dont-email.me> <104qjcg$1c0m7$1@dont-email.me>
 <104ruag$1ml84$3@dont-email.me> <104t5nk$1frch$2@dont-email.me>
 <104tuh6$264oq$9@dont-email.me> <104vij5$1jfin$2@dont-email.me>
 <1050juk$2qkok$6@dont-email.me> <1052i2m$1pbs1$1@dont-email.me>
 <10530ga$3dptv$4@dont-email.me> <10559er$1tk4j$3@dont-email.me>
 <1055hn6$2t13$1@dont-email.me> <1057mgt$21svn$3@dont-email.me>
 <1058gq9$q07u$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 17 Jul 2025 02:16:34 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="959202"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <1058gq9$q07u$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US

On 7/16/25 11:34 AM, olcott wrote:
> On 7/16/2025 3:05 AM, Fred. Zwarts wrote:
>> Op 15.jul.2025 om 14:31 schreef olcott:
>>> On 7/15/2025 5:10 AM, Fred. Zwarts wrote:
>>>> Op 14.jul.2025 om 15:25 schreef olcott:
>>>>> On 7/14/2025 4:19 AM, Fred. Zwarts wrote:
>>>>>> Op 13.jul.2025 om 17:38 schreef olcott:
>>>>>>> On 7/13/2025 1:09 AM, Fred. Zwarts wrote:
>>>>>>>> Op 12.jul.2025 om 17:21 schreef olcott:
>>>>>>>>> On 7/12/2025 3:17 AM, Fred. Zwarts wrote:
>>>>>>>>>> Op 11.jul.2025 om 23:05 schreef olcott:
>>>>>>>>>>> On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
>>>>>>>>>>>> Op 10.jul.2025 om 16:35 schreef olcott:
>>>>>>>>>>>>> On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>> Op 09.jul.2025 om 15:02 schreef olcott:>
>>>>>>>>>>>>>>> All Turing machine deciders only compute the mapping
>>>>>>>>>>>>>>> from their actual inputs. This entails that they never
>>>>>>>>>>>>>>> compute any mapping from non-inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At least one thing you understand.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *From the bottom of page 319 has been adapted to this*
>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>>>>>>>>>>
>>>>>>>>>>>>> *The Linz proof does not understand this*
>>>>>>>>>>>>>
>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
>>>>>>>>>>>>>    *if Ĥ applied to ⟨Ĥ⟩ halts, and*
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>    *if Ĥ applied to ⟨Ĥ⟩ does not halt*
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The evidence is that the input includes the code to 
>>>>>>>>>>>>>>>> abort and halt,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> abort and stop running
>>>>>>>>>>>>>>> *IS NOT THE SAME THING AS*
>>>>>>>>>>>>>>> abort and halt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another claim without evidence.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> *It is common knowledge in the theory of computation*
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Another claim without evidence.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Your lack of knowledge of computer science is not a rebuttal*
>>>>>>>>>>>
>>>>>>>>>>> Look at the definition of a Turing Machine (e.g., the one 
>>>>>>>>>>> here). The machine has states. Each state can be final or 
>>>>>>>>>>> non- final. If the machine's state is non-final, in the next 
>>>>>>>>>>> step the machine "does" something, namely, it can write 
>>>>>>>>>>> something on the tape, move its head, and/or change its state 
>>>>>>>>>>> to a different state. This is how the machine makes a progress.
>>>>>>>>>>
>>>>>>>>>> So, aborting the simulation when the machine has not yet 
>>>>>>>>>> reached its final state, is a violation of the Turing Machine.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void DDD()
>>>>>>>>> {
>>>>>>>>>    HHH(DDD);
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> So you don't understand that DDD simulated by
>>>>>>>>> pure simulator HHH keeps repeating its first
>>>>>>>>> line forever?
>>>>>>>>
>>>>>>>> Irrelevant, because that is not what HHH does.
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>>    HHH(DDD);
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> I stipulated this HHH <is> a pure simulator temporarily
>>>>>>> overriding and superseding everything else that I ever
>>>>>>> said about HHH.
>>>>>>
>>>>>> You can stipulate that, but is irrelevant for the HHH you 
>>>>>> published in Halt7.c. *That* HHH is not a pure simulator. The fact 
>>>>>> that a pure simulator fails is no proof for the correctness of the 
>>>>>> non- pure simulator.
>>>>>> Dreaming of other simulators with other behaviour does not change 
>>>>>> the factual behaviour of the HHH we are discussing.
>>>>>>
>>>>>
>>>>> void RRR()
>>>>> {
>>>>>    SSS(RRR);
>>>>>    return;
>>>>> }
>>>>>
>>>>> When RRR is simulated by pure simulator SSS
>>>>> RRR simulated by SSS never reaches its own
>>>>> "return" statement.
>>>>
>>>> You have been corrected on this many times, but you seem unable to 
>>>> understand it.
>>>> We are discussing a non-pure simulator, so the behaviour of a pure 
>>>> simulator is irrelevant.
>>>>
>>>>>
>>>>> When we adapt SSS so that it only simulates
>>>>> N instructions of RRR then no RRR ever reaches
>>>>> its own "return" statement.
>>>
>>>> Now there is a final halt state, but SSS is unable to reach it. This 
>>>> illustrates that simulation is not the right tool for this input to 
>>>> analyse the behaviour, because it cannot see the full specification. 
>>>> Other tools are needed, but each tool will fail for some inputs.
>>>
>>> _DDD()
>>> [00002192] 55             push ebp
>>> [00002193] 8bec           mov ebp,esp
>>> [00002195] 6892210000     push 00002192  // push DDD
>>> [0000219a] e833f4ffff     call 000015d2  // call HHH
>>> [0000219f] 83c404         add esp,+04
>>> [000021a2] 5d             pop ebp
>>> [000021a3] c3             ret
>>> Size in bytes:(0018) [000021a3]
>>>
>>> So when the actual behavior of the actual x86 code
>>> disagrees with you you disagree with the x86 language.
>>>
>>
>> And since it does not disagree with me, 
> Show how DDD emulated by HHH
> (according to the semantics of the x86 language)
> reaches its "ret" instruction final halt state.
> 
> Don't fucking change the subject to something else.
> 

That isn't our problem.

YHOUR problem is YOU need to prove that it DOES a correct simulation, 
even though the code for HHH isn't in the input.

The definition of non-halting references the behavior of the DIRECT 
EXECUTION of the PROGRAM that the input represents.

Since you input doesn't include HHH, it isn't a program, and thus 
doesn't have a halting property, and you arguement blows up in a 
category error.