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
in this proof. I simplified the Linz syntax on the top
of page 3.
But it has key errors that have been explained to you that you just
ignore so you can continue to just spread your LIES.
https://www.liarparadox.org/Linz_Proof.pdf
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)