Re: D simulated by H never halts no matter what H does

On 4/26/2024 10:45 PM, Richard Damon wrote:

On 4/26/24 11:02 PM, olcott wrote:

On 4/26/2024 9:18 PM, Richard Damon wrote:

On 4/26/24 9:43 PM, olcott wrote:

On 4/26/2024 7:26 PM, Richard Damon wrote:

On 4/26/24 8:02 PM, olcott wrote:

On 4/26/2024 12:05 PM, olcott wrote:

On 4/26/2024 11:19 AM, Richard Damon wrote:

On 4/26/24 11:34 AM, olcott wrote:

On 4/26/2024 3:32 AM, Mikko wrote:

On 2024-04-25 14:15:20 +0000, olcott said:

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11   D(D);
12 }
>
That H(D,D) must report on the behavior of its caller is the
one that is incorrect.

>
What H(D,D) must report is independet of what procedure (if any)
calls it.
>

>
Thus when H(D,D) correctly reports that its input D(D) cannot possibly
reach its own line 6 and halt no matter what H does then H can abort its
input and report that its input D(D) does not halt.

>
But since the program D(D) DOES reach its own line 6 when run, because H aborts its simulation and return 0 (since that is what you say this H will do), your statement is PROVEN TO BE A LIE, and you "logic" just a collection of contradictions.
>

>
D simulated by H cannot possibly reach its own line 06 thus when we do
not use the strawman deception to refer to a different D then we know
that D simulated by H never halts.
>

>
The fact that the D(D) executed in main does halt is none of H's
business because H is not allowed to report on the behavior of its
caller.
>

>
In other words, H doesn't need to report on the Behavior of the Program described by its input because it isn't actually a Halt Decider, because you are just a LIAR.
>
>

>
Anyone knowing the theory of computation knows that H is not allowed to
report on the behavior of its caller.
>
In computability theory and computational complexity theory, an
undecidable problem is a decision problem for which it is proved to be
impossible to construct an algorithm that always leads to a correct yes-
or-no answer. https://en.wikipedia.org/wiki/Undecidable_problem
>
The behavior of the simulated D(D) before H aborts its simulation is
different than the behavior of the executed D(D) after H has aborted
its simulation.
>
Every time that a simulated input would never stop running unless
aborted the simulating termination analyzer must abort this simulation
to prevent its own infinite execution.
>
H(D,D) is a case of this H1(D,D) is not a case of this even though
the only difference between H and H1 is that D calls H and D does
not call H1.
>
D simulated by H would never stop running unless aborted and cannot
possibly reach its own line 06 and halt no matter what H does.
>
Thus whenever we do not use the strawman deception to refer to a
different D we know that D simulated by H specifies a non-halting
sequence of configurations to H.
>

>
*This might be a more succinct way of summing that up*
When you understand that D simulated by H cannot possibly reach past its own line 03 (thus cannot possibly halt) no matter what H does and

>
But since H does whatever H does, if H aborts and returns 0, the the direct execution of D, which is what actually matters, DOES get to that point.
>

>
That is another much less useful way to make a universally correct
termination analyzer:
>
int H(ptr x, ptr y)
{
   printf("The input program does whatever it does!\n");
   return 777; // code for it does what it does
}

>
But that doesn't make H answer the question.
>
I guess you don't understand what I am saying.
>
You said "no matter what H does", but that is a MEANINGLESS statement, because H will do what H is programmed to do, so we don't need to look at other behavior, but just the behavior that H ac
>

>
It can be verified through ordinary software engineering that D(D)
simulated H cannot possibly reach past its own line 03.

>
>
Yes, but that is just a lying RED HERRING, as the question isn't about what H's simulation of the input does, but what the program the input actually represents does when run.
>
YOu are just effectively admitting that you are nothing but a stupid liar that doesn't know what he is talking about.
>

>
It can be verified through computer science that this means that D(D) simulated H by never reaches its own final state and halts whether
H aborts its simulation or not.

>
Which, since this H DOES abort its simulation is trying to introduce a red herring.
>

>
D(D) simulated by H never halts
D(D) simulated by H never halts
D(D) simulated by H never halts
D(D) simulated by H never halts
D(D) simulated by H never halts

 STRAWMAN
 The question is does the conputation described by the input halt.
 

A method that I used very effectively on another forum and made much
progress with is utterly insisting that we cannot move on to any
additional point until we have 100% complete mutual agreement on
the current point.
If we (possibly falsely assume) that H(D,D) is supposed to report
on the behavior of D(D) simulated by H and
we understand that D(D) simulated by H cannot possibly reach past its
own line 3 thus cannot reach its own final state at line 6 and halt
then (within this possibly false assumption) it <is> correct for
H to abort its simulation and report halting.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer