| Deutsch English Français Italiano |
|
<105abom$25t70$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory,sci.logic
Subject: Re: My reviewers think that halt deciders must report on the behavior
of their caller
Date: Thu, 17 Jul 2025 10:20:39 +0200
Organization: A noiseless patient Spider
Lines: 148
Message-ID: <105abom$25t70$1@dont-email.me>
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 08:20:39 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="265b0ed1a353b5a6daa3ca8c8c558248";
logging-data="2290912"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18AJK/vQB6WZL4oAhxCDPBg"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:fCqD7Nscn2WI24qy85qqL25DFxg=
Content-Language: nl, en-GB
In-Reply-To: <1058gq9$q07u$1@dont-email.me>
Op 16.jul.2025 om 17:34 schreef olcott:
> 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.
No rebuttal. I am not going to solve your problem, which has no
solution. If you want a square circle, don't ask me to make it.
It is impossible for HHH to follow the semantics of the x86 language up
to the point of the final halt state.
The semantics of the x86 language makes it impossible for HHH to
correctly simulate itself up to its final halt state. You know that,
because I have told you that many times. There is a final halt state,
but HHH must fail to reach it.
Stop dreaming of finding a square circle.
Stop dreaming about HHH doing a correct simulation of itself. Face the
facts and think!