Re: D correctly simulated by H proved for THREE YEARS --- rewritten

Op 17.jun.2024 om 16:35 schreef olcott:

On 6/17/2024 9:21 AM, Fred. Zwarts wrote:

Op 17.jun.2024 om 15:39 schreef olcott:

On 6/16/2024 2:08 PM, Fred. Zwarts wrote:

Op 16.jun.2024 om 14:37 schreef olcott:

On 6/16/2024 1:21 AM, Fred. Zwarts wrote:

Op 15.jun.2024 om 17:23 schreef olcott:

On 6/15/2024 10:12 AM, Fred. Zwarts wrote:

Op 15.jun.2024 om 16:48 schreef olcott:

On 6/15/2024 9:37 AM, Fred. Zwarts wrote:

>
Is this the new definition of "pathological"?

>
*It is the same thing that I have been saying all along*
>
00   typedef void (*ptr)(); // pointer to void function
01
02   int HH(ptr P, ptr I);
03
04   void DDD(int (*x)())
05   {
06     HH(x, x);
07     return;
08   }
09
10   int main()
11   {
12     HH(DDD,DDD);
13   }
>
Line 12 main()
   invokes HH(DDD,DDD); that simulates DDD()
>
*REPEAT UNTIL outer HH aborts*
   Line 06 simulated DDD()
   invokes simulated HH(DDD,DDD); that simulates DDD()
>
DDD correctly simulated by HH never reaches its own "return"
instruction and halts.

>
So, you agree that you are changing definitions.

>
Not at all. The original definition still applies when it
is made more generic.
>
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
>
D correctly simulated by H has isomorphic behavior to DDD
correctly simulated by HH, both get stuck in recursive
simulation.
>

>
When asked what is a pathological program olcott replied:
Op 14.jun.2024 om 21:18 schreef olcott:

For any program H that might determine whether programs halt, a
"pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts D will do. No H can exist that handles this case.

>
>
No he defines a "pathological" program as a program that calls H.
All words about doing the opposite of what H predicts, have disappeared.
Everyone sees the difference, but he is stuck is rebuttal mode and denies the change of definition.
>

>
The code that "does the opposite" was never reachable by
a simulating halt decider thus does not change the problem
for a simulating halt decider when this code is removed.

>
So, there was never a relation with the Linz proof, where the part that does the opposite of what H predicts plays the essential role.
>

>
This is the key essence of the pathological relationship in all
of the halting problem counter-example proofs including the Linz proof.
>
void DDD()
{
   H0(DDD);
}
>
int main()
{
   H0(DDD);
}
>

What remains is the fact that H is unable to simulate itself up to its final state, which is called a "pathological" property of H.
>

>
H is always correct to abort the simulation of any input
that would cause itself to not terminate normally.
>
When this is construed as non-halting criteria then H is
always correct to reject all of these inputs as non-halting.
>

>
When! But that would be a big mistake to do. The inability of H0 to simulate itself does not tell us anything about the halting behaviour of the program.
>

 Your view here is merely ignorant of the fact that deciders
must report on the behavior specified by their inputs.
 It is incorrect to assume against the facts when DDD correctly
simulated by H0 calls a simulated H0(DDD) that this call will
return to the correctly simulated DDD.

It is incorrect to assume that a failing simulator reports anything, except it own failure.
So, you may wish that it reports about DDD, but that is irrelevant.