Re: Sequence of sequence, selection and iteration matters

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