Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: Sequence of sequence, selection and iteration matters
Date: Sun, 14 Jul 2024 11:37:17 +0300
Organization: -
Lines: 98
Message-ID: <v702nt$2kut$1@dont-email.me>
References: <v6e7va$c4sv$1@dont-email.me> <v6g444$pdc2$1@dont-email.me> <v6go4d$sg7f$1@dont-email.me> <v6ikv5$19h6q$1@dont-email.me> <v6jguf$1ctoi$5@dont-email.me> <v6ji1d$1dpoc$1@dont-email.me> <v6jig0$1ctoi$11@dont-email.me> <v6jkib$1e3jq$1@dont-email.me> <v6jpe5$1eul0$1@dont-email.me> <v6jpqo$1e3jq$2@dont-email.me> <v6jqfg$1eul0$2@dont-email.me> <v6k6md$1h3a7$1@dont-email.me> <v6k9ef$1hicb$1@dont-email.me> <v6lc9v$1q8jn$1@dont-email.me> <v6lva1$1tj30$1@dont-email.me> <v6m4nk$1uean$1@dont-email.me> <v6m53s$1ugv5$1@dont-email.me> <v6m6i9$1uean$3@dont-email.me> <v6m78d$1uq86$1@dont-email.me> <v6o17i$2bu9u$1@dont-email.me> <v6ordc$2fuva$9@dont-email.me> <v6qrq1$2v5cr$1@dont-email.me> <v6rbf7$30qtt$10@dont-email.me> <v6tcth$3gm3g$1@dont-email.me> <v6tss2$3imib$10@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 14 Jul 2024 10:37:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9a92efa79bf89cf93bddcd1bb941165c";
	logging-data="87005"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18pH5jZoXmufEpGWZc8LVXb"
User-Agent: Unison/2.2
Cancel-Lock: sha1:F/iR9C12dRuL4CSi3rYprh00cyA=
Bytes: 4832

On 2024-07-13 12:44:50 +0000, olcott said:

> On 7/13/2024 3:12 AM, Mikko wrote:
>> On 2024-07-12 13:35:34 +0000, olcott said:
>> 
>>> On 7/12/2024 4:08 AM, Mikko wrote:
>>>> 
>>>> In that situation you should use the symobls HHH₁, HHH₂, HHH₃, ...
>>>> so that you can use HHHᵢ when you say aothing about every one of them.
>>>> And the one more symbols for the one that runs forever.
>>> 
>>> I did not want to say it as verbosely as that, yet your suggestion
>>> would be clearer.
>> 
>> For honest purposes clearer would be better. But understand that
>> different purposes mean different priorities.
> 
> I made it clearer using your suggestions.

Where is that clearer presentations?

>>>> And they should
>>>> not be defined to run DDD but whatever input is given.
>>> 
>>> I certainly can't do that. People here use every excuse
>>> they can to change the subject and then stay on this
>>> changed subject and never get back to the point.
>> 
>> Of course you can and should. No reason to expect them to protest less
>> if you make more errors.
>> 
> 
> My current paper examines these three inputs at the C
> source-code level in the simplest one first order.
> 
> void Infinite_Loop()
> {
>    HERE: goto HERE;
> }
> 
> void Infinite_Recursion()
> {
>    Infinite_Recursion();
> }
> 
> void DDD()
> {
>    HHH(DDD);
> }
> 
> It then examines the simplest possible pathological input
> above at the assembly language level.

Going to the assembly langage level does not add anything if the code
of HHH is not shown. That HHH simulates at the machine langage level
does not alter the fact that the behaviour it simulates is the behaviour
of the C code.

> Then it moves on to this input showing that its x86 execution
> trace is essentially the same as DDD correctly emulated by HHH.

If HHH aborts its simulation and never simulates the return from HHH or
anything past that point then it does not matter what the behaour after
point is. This is obvious from the C semantics.

> int DD()
> {
>    int Halt_Status = HHH(DD);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }

But the part that HHH never simulates is the part that determines
whether the program returns or not. The halt status of DD is differnt
from the halt status of DDD if HHH(DD) returns nonzero. Otherwise
it is the same.

> Then the last half of the paper applies these same ideas
> to the Peter Linz Turing machine based proof based on this
> greatly simplified syntax.
> 
> I show that ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by adapted UTM embedded_H has
> this same essential pattern as the above two, it remains
> stuck in recursive simulation until its input is aborted.
> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

This is incorrect. That looks like tree clauses, a subordinate clause and
two main coordinated main clauses. But there should be conjunctions that
show either that the structure really is so or that the intended meaning
is something else.

-- 
Mikko