Re: Simulating termination analyzers for dummies

On 6/19/24 8:44 PM, olcott wrote:

On 6/19/2024 7:23 PM, Richard Damon wrote:

On 6/19/24 9:00 AM, olcott wrote:

On 6/19/2024 3:08 AM, Fred. Zwarts wrote:

Op 18.jun.2024 om 18:26 schreef olcott:

On 6/18/2024 10:47 AM, Fred. Zwarts wrote:

Op 18.jun.2024 om 17:33 schreef olcott:

On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.

>
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>

You either lack this degree of skill in C or are only
interested in playing head games.

>
I have seen the response. It was most certainly not a serious reply.
But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode, even if the truth is obvious.
>

>
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
>
*You seem to be willfully ignorant*
>

It was your own proof that showed that in
>
        int main()
        {
          return H(main);
        }
>
>
main halts, whereas H reported non-halting. So, it you were honest you would stop claiming that H is correct.
>

>
That is merely a more difficult to understand version of this
same pathological relationship.
>
int main()
{
   Output("Input_Halts = ", HH0(main));
}
>
_main()
[000020c2] 55         push ebp
[000020c3] 8bec       mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404     add esp,+04
[000020d2] 50         push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408     add esp,+08
[000020e0] eb04       jmp 000020e6
[000020e2] 33c0       xor eax,eax
[000020e4] eb02       jmp 000020e8
[000020e6] 33c0       xor eax,eax
[000020e8] 5d         pop ebp
[000020e9] c3         ret
Size in bytes:(0040) [000020e9]
>
  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[000020c2][001036c3][00000000] 55         push ebp
[000020c3][001036c3][00000000] 8bec       mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:103767
>
Begin Local Halt Decider Simulation   Execution Trace Stored at:11376f
[000020c2][0011375f][00113763] 55         push ebp      ; begin main
[000020c3][0011375f][00113763] 8bec       mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55         push ebp      ; begin main
[000020c3][0015e187][0015e18b] 8bec       mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
[000020cf][001036c3][00000000] 83c404     add esp,+04
[000020d2][001036bf][00000000] 50         push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408     add esp,+08
[000020e0][001036c3][00000000] eb04       jmp 000020e6
[000020e6][001036c3][00000000] 33c0       xor eax,eax
[000020e8][001036c7][00000018] 5d         pop ebp
[000020e9][001036cb][00000000] c3         ret           ; exit main
Number of Instructions Executed(10070) == 150 Pages
>

>
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false negatives, when used to determine halting behaviour, please, stop to call them halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the simulation was correct, when false, the full simulation was not possible.

>
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
>
void DDD()
{
   H0(DDD);
}
>
_DDD()
[000020a2] 55         push ebp      ; housekeeping
[000020a3] 8bec       mov ebp,esp   ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404     add esp,+04   ; housekeeping
[000020b2] 5d         pop ebp       ; housekeeping
[000020b3] c3         ret           ; never gets here
Size in bytes:(0018) [000020b3]
>
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
>
>

>
Why does H0 NEED to be able to correctly simulate its input?
>

 Decider must compute the mapping from their finite string
input to the actual behavior that this finite string specifies.
They are not free to imagine the behavior that the authors of
textbooks expect.

AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
Yes, the DO need to follow the behavior that the author of the problem defined.
You are just showing you think it is ok to not follow the REQURIEMENTS and just LIE about what you are doing.

 

Your question is just a Strawman, replacing the OBJECTIVE criteria of the behavior of the machine represented by the input (which inlcudes the code for H0) with the SUBJECTIVE question of what H0 thinks about it.
>
And, your H0 doesn't correctly simulate the input, as the *ONLY* correct simulation of that input would be:
>
simulate the push ebp
simulate the mov ebp,esp
simulate the push 000020a2
simulate the call 00001aa2
simulate the instruction at 00001aa2
>

 I now have a 195 page color-coded execution trace
showing HH0 correctly simulating DDD calling
a simulated HH0 simulating another instance of DDD.
https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf

I'll look into it in more details later, but this is what comes from a quick look.
The first thing I note, is just like that last one, the TRACE doesn't start until page 36, so is not as long as you claim. It is nice that you include the x86 assembly of the program. But it also shows that something isn't as it seems as there are a lot of functions like:
_OutputString()
[00000743] 55 push ebp
[00000744] 8bec move ebp, esp
[00000746] 5d pop. ebp
[00000747] c3 ret
Size in bytes:(0005) [00000747]
Which your tracing seems to ignore, and the seem to end up doing something not shown, so clearly, there is activity not being traced and being hidden. This could be called a LIE.
Also, something is funny about the formatting of the text of the PDF, like it is edited and reformatted as it doesn't copy and paste well.
First, again, the simulation starts as:
[000020b3][00103680][00000000] 55.         push. ebp
[000020b4][00103680][00000000] 8bec.       mov ebp, esp
[000020b6][0010367c][00002093] 6893200000  push 00002093
and the code at 20b3 is the code of main, not DDD, so again, this is the wrong trace. The trace from H0, will start at the instructions of DDD, at address 00002093
So, this is NOT the trace of HH0(DDD,DDD)
Did you confuse me with someone else you were arguing about and forgot what the actual problem was.
Then on page 37, we see:
[000012d1][00103620][000003db] e87df4ffff  call 00000753
New slave_stack at:103724
[000012d6][00103628][00103674] 83c408      add esp,+08
So, again, your trace isn't actually a correct x86 trace of the actual code being executed. And these functions at these addresses seem to be something "magic" as the code shown doesn't match the names given.
SO, it seems something may be rotten in Denmark here.
Then we have on page 43: (spaces and comments added)
[000011dc][00103604][001036ac] 52.         push edx
[000011dd][00103604][001036ac] e8b1f5ffff  call 00000793
[0000209b][00113714][000020a0] e853f4ffff  call 000014f3
The above is NOT a correct simulation of the code that is currently being simulated by the top level decider, then it gets back to its proper trace.
[000011e2][00103610][0011372c] 83c40c      add esp,+0c
If this is showing a simulation at a different level, it really should be more clearly indicated

 

since that isn't what you have ever shown as the simulation by H0, you have lost the right to call its simulation "correct".
>
Sorry, your argument is just a lie.

 *It never has been a falsehood*
 

It has ALWAYS been. You just don't seem to know the meaning of  truth.
Look, you repeated the exact same error, even though you apparently did look at the document to add color coding. (or had a program do it).
It is clear you don't understand about what a correct simulation trace of your decider simulating the input DDD,DDD