Liste des Groupes | Revenir à theory |
Op 18.jun.2024 om 14:43 schreef olcott:I worked for the Airforce at the Airforce base with a secretOn 6/18/2024 4:16 AM, Fred. Zwarts wrote:Very good olcott! We agree on this point. At least you understand something of programming.Op 17.jun.2024 om 15:07 schreef olcott:>On 6/17/2024 2:22 AM, Mikko wrote:>On 2024-06-16 12:37:38 +0000, olcott said:>
>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.
>
By simplifying the problem we gain cognitive leverage. With
less details to pay attention to the while simplified problem
can be more deeply understood.
>His only excuse is that in both cases a recursive simulation is seen, but that is not the point.>
He had already proved earlier that in
>
int main()
{
return H(main, 0);
}
>
H produces a false negative, because main halts, whereas H reports
The input does not halt and deciders are only accountable
for the behavior of their input.
If the above main does not halt then H it calls is not a decider.
>
That is merely a more difficult to understand
example of this simplest possible case.
>
void DDD()
{
H0(DDD);
}
>
int main()
{
H0(DDD);
}
>
No, the other case is is simpler:
>
int main()
{
return H(main, 0);
}
>
DDD is an unneeded complication. These four lines are sufficient to see that there is no other reason for the false negative than H itself.
>
We understand that you do not like the simplest example, because it shows that the reasoning that there is a difference between main calling DDD(), or calling H0(DDD) is futile. In the simplest case this futile trick is not possible.
Therefore, we see that the whole problem is that H, or H0 is unable to simulate itself sufficiently far enough to see the real behaviour. It always aborts one cycle too early and, therefore, produces false negatives.
The is merely your lack or programming skill. The outer H0 always
has at least one more execution trace than any of the inner ones
thus if it does not abort none of them do.
>
This means that if H0 aborts, it will do that always one cycle too early.*No that it not it*
So, it does not see that its simulated self would also abort and halt. So, indeed, an abort may be required, but then it is a wild guess, a wrong one, that it is non-halting, because the reality is that it would halt.--
Les messages affichés proviennent d'usenet.