Re: Simulating termination analyzers for dummies

On 6/20/24 10:58 AM, olcott wrote:

On 6/20/2024 6:33 AM, Richard Damon wrote:

On 6/19/24 10:25 PM, olcott wrote:

On 6/19/2024 9:17 PM, Richard Damon wrote:

On 6/19/24 10:02 PM, olcott wrote:

On 6/19/2024 8:39 PM, Richard Damon wrote:

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.
>

The finite string input does not communicate the behavior
that the textbook authors expect it to communicate.
>

>
The finite string certainly DOES communicate what is needed to determine the behavior, or it wasn't a correct representation.
>

>
There is no sequence of truth preserving operations from the finite
string machine code of DDD that can correctly ignore the pathological
relationship between H0 and DDD as an aspect of the behavior that
this finite string specifies.
>

>
Why does it need to "ignore" the relationship. We can in a finite number of operations show that the machine code of DDD (but we need ALL the machine code of DDD, including the functions it calls) show that DDD represents a Halting Program if the decider does what you claim, and returns 0 in a finite amount of time.
>

 _DDD()
[00002093] 55               push ebp
[00002094] 8bec             mov ebp,esp
[00002096] 6893200000       push 00002093
[0000209b] e853f4ffff       call 000014f3
[000020a0] 83c404           add esp,+04
[000020a3] 5d               pop ebp
[000020a4] c3               ret
Size in bytes:(0018) [000020a4]
 We can see that H0 halts and you seem insufficiently technically
competent or outright dishonest when you imply
 that H0 cannot
see that DDD correctly simulated by H0 cannot possibly get past
its own [0000209b] machine address in a finite number of steps.

The fact that is can not see, doesn't make the halting of the input not happen.
Remember, "H0" is the name for *THIS* *EXACT* *MACHINE* because there can only be one C entity by the same name at global scope.
And DDD is *DEFINED* to be using *THIS* H0, since the x86 code for H0 must be part of the x86 code for DDD, or you can't simulate more than 4 instructions correctly.
Note, the question that H0 is SUPPOSED to be answering is does its input halt, or equivalently if an actually correct (and complete) simulation of this input will halt. Since H0 doesn't do that, its simulaton doesn't count.
Also, H0 can't prove that its simulation of the input *CAN'T* reach a final state, because of the fact that it *DOES* about at the point it does, so either you admit that it is just a trival fact that a machine that aborts its simulation has shown that it couldn't go farther (since it didn't) which makes your concept just a trivial decider, or you have to try to convince people that it is ok to look at the WRONG input, which is of course, just invalid logic.

 <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H *correctly simulates its input D*
   *until H correctly determines that its simulated D would never*
   *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
 

Right, and that was with the DEFINITION that a "Correct Simulation" is a simulation that actualy DOES correctly repoduce the behavior of the input, something you claim youir doesn't' need to, and that definition means tha ta correct simulation doesn't ever stop until it gets to the end. Something your decider doesn't do, or even correctly predict the results of (since we can show, and you admit) that the direct execution of the input will halt (which is why you desperately are trying to prove that a correct simulation can be different that the actual behavior, which is just a contradiction of terms).