Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Sequence of sequence, selection and iteration matters --
 Professor Hehner
Date: Sun, 14 Jul 2024 10:02:33 -0500
Organization: A noiseless patient Spider
Lines: 141
Message-ID: <v70pa9$61d8$11@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> <v702nt$2kut$1@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 17:02:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="315e0a3cec91d4c915c12e3bad83b2c9";
	logging-data="198056"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19A5pnUUWc07ypr7UFddqWX"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ZTbt3tKnZOiDe8BZh5RZRXCdvkI=
Content-Language: en-US
In-Reply-To: <v702nt$2kut$1@dont-email.me>
Bytes: 6815

On 7/14/2024 3:37 AM, Mikko wrote:
> 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. 

Going to the assembly language level provides a directed
graph of control flow. It also shows the final state that
is not shown at the C level. Can't reach the final state
is what not halting means.

> 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 fact that DD remains stuck in recursive simulation is
what determines that DD never halts. Professor Hehner
figured out that part 5 years before me.

     From a programmer's point of view, if we apply an
     interpreter to a program text that includes a call
     to that same interpreter with that same text as
     argument, then we have an infinite loop. A halting
     program has some of the same character as an interpreter:
     it applies to texts through abstract interpretation.
     Unsurprisingly, if we apply a halting program to a program
     text that includes a call to that same halting program with
     that same text as argument, then we have an infinite loop.
     (Hehner:2011:15)

[5] E C R Hehner. Problems with the Halting Problem, COMPUTING2011 
Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe 
Germany, invited, 2011 October 20-21; Advances in Computer Science and 
Engineering v.10 n.1 p.31-60, 2013
https://www.cs.toronto.edu/~hehner/PHP.pdf

> The halt status of DD is differnt
> from the halt status of DDD if HHH(DD) returns nonzero. Otherwise
> it is the same.
> 

That code is dead code (unreachable) to the simulated DD.

>> 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.
> 

You have to read everything else that I said about the
above expressions. I already provided the key details
in this proof. I simplified the Linz syntax on the top
of page 3.

https://www.liarparadox.org/Linz_Proof.pdf

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer