Re: At least 100 people kept denying the easily verified fact --- last communication with Richard

On 6/9/24 10:04 AM, olcott wrote:

On 6/9/2024 4:33 AM, Mikko wrote:

On 2024-06-08 13:06:06 +0000, olcott said:
>

On 6/8/2024 1:58 AM, Mikko wrote:

On 2024-06-07 18:41:47 +0000, olcott said:
>

On 6/7/2024 1:24 PM, Richard Damon wrote:

On 6/7/24 2:02 PM, olcott wrote:

On 6/7/2024 12:50 PM, Alan Mackenzie wrote:

[ Followup-To: set ]
>
In comp.theory olcott <polcott333@gmail.com> wrote:
>
[ .... ]
>

_DD()
[00001e12] 55         push ebp
[00001e13] 8bec       mov  ebp,esp
[00001e15] 51         push ecx
[00001e16] 8b4508     mov  eax,[ebp+08]
[00001e19] 50         push eax      ; push DD
[00001e1a] 8b4d08     mov  ecx,[ebp+08]
[00001e1d] 51         push ecx      ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH

>

A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.

>
That's a bit of sudden and substantial change, isn't it?  Less than a few
days ago, you were defining a correct simulation as "1 to N instructions"
simulated (without ever specifying what you meant by N).  It seems that
the simulation of exactly one instruction would have met your criterion.
>
That now seems to have changed.
>

>
Because I am a relatively terrible writer I must constantly
improve my words on the basis of reviews.
>
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
>
_DD()
[00001e12] 55         push ebp
[00001e13] 8bec       mov  ebp,esp
[00001e15] 51         push ecx
[00001e16] 8b4508     mov  eax,[ebp+08]
[00001e19] 50         push eax      ; push DD
[00001e1a] 8b4d08     mov  ecx,[ebp+08]
[00001e1d] 51         push ecx      ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
>
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
>
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
>

>
And thus you admit that HH is not a Halt Decider,

>
More dishonest deflection.
The point that I made and you try to deflect using the strawman
deception as a fake rebuttal is the I just proved that DD is correctly
simulated by HH and this is not the same behavior as the directly
executed DD(DD).

>
The true point is that you have never shown any proof about simulation
by HH.

>
In other words you lack the mandatory prerequisites so the
correct proof only looks like gibberish to you.

>
Hard to teest wihout the correct proof.
>
Anyway, something that starts with "Proof:" and ends with "Q.E.D." may
fail to be a proof. It depends on what is between.
>

 typedef void (*ptr)(); // pointer to void function
 void HHH(ptr P, ptr I)
{
   P(I);
   return;
}
 void DDD(int (*x)())
{
   HHH(x, x);
   return;
}
 int main()
{
   HHH(DDD,DDD);
}
 In the above Neither DDD nor HHH ever reach their own return
statement thus never halt.
 When HHH is a simulating halt decider then HHH sees that
DDD correctly simulated by HHH cannot possibly reach its
own return statement, AKA

But HHH (as shown above) ISN'T a simulating halt decider, so you are just caught in another of youre lies.
You seem to like to pretend that things aren't what they are but that they are what they aren't, as a way to try to prove false statements.

     simulating halt decider HHH correctly simulates its input DDD
    until HHH correctly determines that its simulated DDD would never
    stop running unless aborted
 

And to ACTUALLY do that, it need to run forever, because i fit everdecides to abort itsimulation, then when we *RUN* (that is directly execute it) then the HHH that it will call will also at that exact same point abort its own simulation and return to DDD.
So, your logic about our hypothetical HHH (not the one you showed is proven incorrect, and still creates the infinite recursion of your above machine.