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: Sequence of sequence, selection and iteration matters --
 Professor Hehner
Date: Sun, 14 Jul 2024 17:41:35 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <4ab81e5d0b4cb099b1cb0edd08d353bdf6ec141d@i2pn2.org>
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>
 <v70pa9$61d8$11@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 21:41:35 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3273011"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v70pa9$61d8$11@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 8166
Lines: 173

On 7/14/24 11:02 AM, olcott wrote:
> 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.

Right, but the control flow for the DDD that calls the HHH that aborts 
its simulation and returns (which is the DDD the HHH that aborts its 
simulation and returns is given) will go into that HHH, and loop around 
as it does the emulation, then branches off when that HHH decides to 
abort and then returns to DDD which returns.

The fact that HHH doesn't emulate the control flow that far, doesn't 
mean tha the control flow doesn't go that far.

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

But DD doesn't get stuck in recursive simulation, because you have said 
that HHH DOES abort and returns 0.

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

His statement is about a pure UNCONDITIONAL interpreter. HHH is not that.

Make the interpreter conditional, and if the condition it uses to decide 
to stop occurs anywhere in the cycles, then it isn't an infinite loop.

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

And if he claims that above for a Halt Decider, he is just wrong.

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

Nope. It is unreached in the partial simulation, but NOT to the actual 
behavior of the program simulated.

There is a fundamental difference between the to that you blur, and 
since it seems intentional, it isn't an honest mistake, but a dishonest LIE.

> 
>>> 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
========== REMAINDER OF ARTICLE TRUNCATED ==========