XPost: sci.logic

On 6/8/24 3:49 PM, olcott wrote:

*This has been corrected so that it can be verified that*
*the execution trace matches the x86 source-code of DD*
(two versions of my text files were out-of-sync)

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022>

Which, since his definition of "Correct Simulation" is not yours, you
can not use.

For you to use it, you need to first show that your H actually does a
correct simulation of the input, which is a simualation that actually
recreates the behavior of the input, which requires a simulation that
never aborts.

Since your H doesn't do this, your logic fails.

Sipser would also allow for us to hypothocate that THIS H changes into
such a simulator, but in doing so, the input does not change (since it
can't) and thus for your system, that means the DD still says paired
with the original HH that you are going to claim to be correct.

Since that simulation WILL HALT if H ever decides to abort and return 0,
as long as that option remains, H can never correctly determine that its simulation would not halt if not aborted.

So, you FAIL to acheive the requirements, and can not use the clause
that you did use, so you have lost correctness of your decider.

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

And who cares, since you have defined your "correct simulation" to allow
for just partial simuations, and thus do not indicate non-halting behavior.

_DD()
[00001c22] 55         push ebp
[00001c23] 8bec       mov ebp,esp
[00001c25] 51         push ecx
[00001c26] 8b4508     mov eax,[ebp+08]
[00001c29] 50         push eax      ; push DD 1c22
[00001c2a] 8b4d08     mov ecx,[ebp+08]
[00001c2d] 51         push ecx      ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; 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.

In other words the first seven steps of DD correctly simulated
by HH call HH(DD,DD) to repeat these first seven steps. HH then
simulates itself simulating DD until this second instance of DD
calls another HH(DD,DD) to repeat these first seven steps again.

Nope, as after the 7th instruction must be the 8th instruction, which is
thw Call HH instruction. To meet your definition, the simulation must
then continue into HH as THAT is the correct behavior of that instruction

So your arguement is totally off track, andyou are failing to meet even
your own requirements.

New slave_stack at:10306d
Begin Local Halt Decider Simulation   Execution Trace Stored at:113075
 machine   stack     stack     machine    assembly
 address   address   data      code       language
 ========  ========  ========  =========  ============= [00001c22][00113061][00113065] 55         push ebp        ; begin DD
[00001c23][00113061][00113065] 8bec       mov ebp,esp [00001c25][0011305d][00103031] 51         push ecx [00001c26][0011305d][00103031] 8b4508     mov eax,[ebp+08] [00001c29][00113059][00001c22] 50         push eax         ; push DD
[00001c2a][00113059][00001c22] 8b4d08     mov ecx,[ebp+08] [00001c2d][00113055][00001c22] 51         push ecx         ; push DD
[00001c2e][00113051][00001c33] e80ff7ffff call 00001342    ; call HH
New slave_stack at:14da95
[00001c22][0015da89][0015da8d] 55         push ebp         ; begin DD
[00001c23][0015da89][0015da8d] 8bec       mov ebp,esp [00001c25][0015da85][0014da59] 51         push ecx [00001c26][0015da85][0014da59] 8b4508     mov eax,[ebp+08] [00001c29][0015da81][00001c22] 50         push eax         ; push DD
[00001c2a][0015da81][00001c22] 8b4d08     mov ecx,[ebp+08] [00001c2d][0015da7d][00001c22] 51         push ecx         ; push DD
[00001c2e][0015da79][00001c33] e80ff7ffff call 00001342    ; call HH
Local Halt Decider: Recursive Simulation Detected Simulation Stopped

The above is the complete proof that DD correctly simulated
by any HH that can possibly exist never stops running without
having its simulation aborted by HH (or crashing for OOM error).

But if fails to meet your definition of "Correct Simulation" so your
argument is just shown to be a LIE.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022>

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are asking a question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to the
point where the simulated HH aborts. That is logically impossible. So,
either it is a correct simulation and then we see that the simulated HH
aborts and returns, or the simulation is incorrect, because it assumes incorrectly that things that happen (abort) do not happen.
A premature conclusion.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/9/24 8:21 AM, olcott wrote:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022>

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are asking
a question that contradicts itself.

In other words the best selling author of theory of
computation textbooks doesn't have a clue?

Nope, you asked him a defective question, and he did his best.

H can not have done a correct simulation, per the definitions in place,
and abort its simulation.

A correct simulation of HH that aborts itself,
should simulate up to the point where the simulated HH aborts.

The outer HH always sees a longer execution trace than
the inner ones. Unless the outer one aborts none of them
abort.

No, you are forgetting that simulation is not the reality, but an
exploration of it.

THe outer HH sees a longer execution trace then the simulated part of
the inner one.

"The inner one" would generally mean the execution of that inner one,
(not an aborted simualation of it) and that, since it is the exact same algorithm and data, will see EXACTLY the same execution trace as the
outer one saw when it interrupt its simulation.

Your problem is you seem to have forgotten that simulation are just explorations of the reality of the execution, and not a reality of
themselves.

That is logically impossible. So, either it is a correct simulation
and then we see that the simulated HH aborts and returns, or the
simulation is incorrect, because it assumes incorrectly that things
that happen (abort) do not happen.
A premature conclusion.

_DD()
[00001e32] 55               push ebp      ; Begin DD [00001e33] 8bec             mov ebp,esp
[00001e35] 51               push ecx
[00001e36] 8b4508           mov eax,[ebp+08]
[00001e39] 50               push eax      ; push DD [00001e3a] 8b4d08           mov ecx,[ebp+08]
[00001e3d] 51               push ecx      ; push DD [00001e3e] e83ff5ffff       call 00001382 ; call DD

If you can't see this then you seem to just not have
enough technical skill:

The first seven steps of DD correctly simulated by HH call
HH(DD,DD) to repeat these first seven steps.

Nope, becase the outer simulator, if simulating per your definition,
won't simulate the input given to that simulated HH, but will simulate
the CODE of HH as it simulates DD(DD).

So that outer HH will NEVER see the actual address 00001E32 again. EVER.

HH then simulates itself simulating DD until this second
instance of DD calls another HH(DD,DD) to repeat these first
seven steps again.

Which means you keep on changing what simulation you are looking at,
which violates your definiton of simulation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Op 10.jun.2024 om 07:17 schreef olcott:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022>

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are asking
a question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically impossible.
So, either it is a correct simulation and then we see that the
simulated HH aborts and returns, or the simulation is incorrect,
because it assumes incorrectly that things that happen (abort) do not
happen.
A premature conclusion.

*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*

On 5/29/2021 2:26 PM, olcott wrote: https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ

THE ONLY POSSIBLE WAY for D simulated by H to have the same
behavior as the directly executed D(D) is for the instructions
of D to be incorrectly simulated by H (details provided below).

_D()
[00000cfc](01)  55                      push ebp [00000cfd](02)  8bec                    mov ebp,esp [00000cff](03)  8b4508                  mov eax,[ebp+08] [00000d02](01)  50                      push eax       ; push D
[00000d03](03)  8b4d08                  mov ecx,[ebp+08] [00000d06](01)  51                      push ecx       ; push D
[00000d07](05)  e800feffff              call 00000b0c  ; call H
[00000d0c](03)  83c408                  add esp,+08 [00000d0f](02)  85c0                    test eax,eax [00000d11](02)  7404                    jz 00000d17 [00000d13](02)  33c0                    xor eax,eax [00000d15](02)  eb05                    jmp 00000d1c [00000d17](05)  b801000000              mov eax,00000001 [00000d1c](01)  5d                      pop ebp [00000d1d](01)  c3                      ret
Size in bytes:(0034) [00000d1d]

In order for D simulated by H to have the same behavior as the
directly executed D(D) H must ignore the instruction at machine
address [00000d07]. *That is an incorrect simulation of D*

H does not ignore that instruction and simulates itself simulating D.
The simulated H outputs its own execution trace of D.

On 05.jun.2024 at 15:59 (CET) olcott proved that in the example

int main()
{
Output("Input_Halts = ", HH(main,(ptr)0));
}

main halts and HH reported a non-halting behaviour. This means that when
HH is used as a test for halting, it produces a false negative.

Olcott is rather silent about this result, probably, because in this
case he can not make a difference between the direct execution and the simulation. In the D case he argues that the order of D and H makes a difference. When D starts and calls H would be different from when H
starts and simulates D. In the above example, it is not possible to
change the order.

Since olcott himself has proven that HH produces a false negative, why
does he continue to claim that there should be a difference between
direct execution and simulation? This is again a false negative.
HH, nor H can be used as a test for halting of a program, at best as a
test for halting of olcott's simulator, but is not interesting for most
people.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-06-09 14:13:23 +0000, olcott said:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022>

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are asking a
question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically impossible.
So, either it is a correct simulation and then we see that the
simulated HH aborts and returns, or the simulation is incorrect,
because it assumes incorrectly that things that happen (abort) do not
happen.
A premature conclusion.

I have a clearer explanation now that I have gone through
all of Mikko's posts: (you must know C to understand this)

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

As the code above shows, HHH is not a simulating halt decider:
(a) HHH does not simulate, (b) HHH does not decide.
Consequently, you are talking about nothing.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/10/24 1:17 AM, olcott wrote:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022>

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are asking
a question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically impossible.
So, either it is a correct simulation and then we see that the
simulated HH aborts and returns, or the simulation is incorrect,
because it assumes incorrectly that things that happen (abort) do not
happen.
A premature conclusion.

*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*

So, I guess you are admitting that you claim it as a verified fact is
just a LIE.

On 5/29/2021 2:26 PM, olcott wrote: https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ

THE ONLY POSSIBLE WAY for D simulated by H to have the same
behavior as the directly executed D(D) is for the instructions
of D to be incorrectly simulated by H (details provided below).

So, I guess you are admitting that this means that "D correctly
simulated by H" is NOT a possible equivalent statement for the behavior
of the direct execution of the input as required by the Halting Problem,
so you admit you have been LYING every time you imply that it is.

_D()
[00000cfc](01)  55                      push ebp [00000cfd](02)  8bec                    mov ebp,esp [00000cff](03)  8b4508                  mov eax,[ebp+08] [00000d02](01)  50                      push eax       ; push D
[00000d03](03)  8b4d08                  mov ecx,[ebp+08] [00000d06](01)  51                      push ecx       ; push D
[00000d07](05)  e800feffff              call 00000b0c  ; call H
[00000d0c](03)  83c408                  add esp,+08 [00000d0f](02)  85c0                    test eax,eax [00000d11](02)  7404                    jz 00000d17 [00000d13](02)  33c0                    xor eax,eax [00000d15](02)  eb05                    jmp 00000d1c [00000d17](05)  b801000000              mov eax,00000001 [00000d1c](01)  5d                      pop ebp [00000d1d](01)  c3                      ret
Size in bytes:(0034) [00000d1d]

In order for D simulated by H to have the same behavior as the
directly executed D(D) H must ignore the instruction at machine
address [00000d07]. *That is an incorrect simulation of D*

No, H can, and must, simulate the call instruction correctly.


Your problem is that it turns out that the only way that a correct
simulation by H to be an actual correct simulation that shows halting
behavior, it can't answer and be a decider.

H does not ignore that instruction and simulates itself simulating D.
The simulated H outputs its own execution trace of D.

But your H DOES ignore the CORRECT behavior of that instruction, as a
correct simulation of that instruction (by what ever type of simulation
you want to do) must either continue it trace inot the function H (which
none of your publish traces of the resutls of the simulation H does do)
if the simulation instruction level, or it must show the effective
behavior of the actaul function H, which is to return 0 (since you claim
you H is correct, and correct to return 0).

Neither of these is what your "correct simulation" of the input does, so
it can not be a correct simulation of the input. Your H just doesn't
"correctly simulate" that call instruction, but does invalid logic to
conclude the wrong answer.


It seems impossible for you claim that you have looked at the trace of H acuallly doing the x86 instruction trace of H to show that it was
correctly determining what you claim, as your "250 page" trace turns out
not to be that trace, and you admit you didn't look at it closely, and
you JUST think you figured out how to get such a trace out.

Thus, you could NOT have verified it 3 years ago.

So, you have just been caught in a LIE.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mon, 10 Jun 2024 08:52:32 -0500 schrieb olcott:

On 6/10/2024 2:09 AM, Fred. Zwarts wrote:

Op 10.jun.2024 om 07:17 schreef olcott:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

On 05.jun.2024 at 15:59 (CET) olcott proved that in the example

int main()
{
    Output("Input_Halts = ", HH(main,(ptr)0));
}

main halts and HH reported a non-halting behaviour. This means that
when HH is used as a test for halting, it produces a false negative.

I just proved that D simulated by H has different behavior
than the directly executed D(D) and you ignored it.

A simulation must have the same behaviour.

--
joes

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mon, 10 Jun 2024 12:54:48 -0500 schrieb olcott:

On 6/10/2024 6:16 AM, Richard Damon wrote:

On 6/10/24 1:17 AM, olcott wrote:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Try to show how this DD correctly simulated by any HH ever stops
running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are asking
a question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically
impossible. So, either it is a correct simulation and then we see
that the simulated HH aborts and returns, or the simulation is
incorrect, because it assumes incorrectly that things that happen
(abort) do not happen.

Why does it need to abort, when its recursive simulation does the same
and thus returns, not needing to be aborted?

So, I guess you are admitting that this means that "D correctly
simulated by H" is NOT a possible equivalent statement for the behavior
of the direct execution of the input as required by the Halting
Problem,
so you admit you have been LYING every time you imply that it is.

Are you saying that the simulation can be different from the direct
execution?

The only way for D simulated by H to have the same behavior as the
directly executed D(D) is for D simulated by H to skip over this call.

Does D(D) skip over this call?

Your problem is that it turns out that the only way that a correct
simulation by H to be an actual correct simulation that shows halting
behavior, it can't answer and be a decider.

[no answer]

But your H DOES ignore the CORRECT behavior of that instruction, as a
correct simulation of that instruction (by what ever type of simulation
you want to do) must either continue it trace into the function H
(which none of your published traces of the results of the simulation H
does do) if the simulation instruction level, or it must show the
effective behavior of the actual function H, which is to return 0
(since you claim you H is correct, and correct to return 0).
Neither of these is what your "correct simulation" of the input does,
so it can not be a correct simulation of the input. Your H just doesn't
"correctly simulate" that call instruction, but does invalid logic to
conclude the wrong answer.
It seems impossible for you claim that you have looked at the trace of
H acually doing the x86 instruction trace of H to show that it was
correctly determining what you claim, as your "250 page" trace turns
out not to be that trace, and you admit you didn't look at it closely,
and you JUST think you figured out how to get such a trace out.

There is no need to look at the trace of H correctly simulated by H when
the trace of D correctly simulated by simulated H is proven to be
correct.

--
joes

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Op 10.jun.2024 om 21:21 schreef olcott:

On 6/10/2024 2:09 AM, Fred. Zwarts wrote:

Op 10.jun.2024 om 07:17 schreef olcott:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022> >>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are
asking a question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically
impossible. So, either it is a correct simulation and then we see
that the simulated HH aborts and returns, or the simulation is
incorrect, because it assumes incorrectly that things that happen
(abort) do not happen.
A premature conclusion.

*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*

On 5/29/2021 2:26 PM, olcott wrote:
https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ

THE ONLY POSSIBLE WAY for D simulated by H to have the same
behavior as the directly executed D(D) is for the instructions
of D to be incorrectly simulated by H (details provided below).

_D()
[00000cfc](01)  55                      push ebp
[00000cfd](02)  8bec                    mov ebp,esp
[00000cff](03)  8b4508                  mov eax,[ebp+08] >>> [00000d02](01)  50                      push eax       ; push D
[00000d03](03)  8b4d08                  mov ecx,[ebp+08] >>> [00000d06](01)  51                      push ecx       ; push D
[00000d07](05)  e800feffff              call 00000b0c  ; call H
[00000d0c](03)  83c408                  add esp,+08
[00000d0f](02)  85c0                    test eax,eax >>> [00000d11](02)  7404                    jz 00000d17
[00000d13](02)  33c0                    xor eax,eax
[00000d15](02)  eb05                    jmp 00000d1c >>> [00000d17](05)  b801000000              mov eax,00000001
[00000d1c](01)  5d                      pop ebp
[00000d1d](01)  c3                      ret
Size in bytes:(0034) [00000d1d]

In order for D simulated by H to have the same behavior as the
directly executed D(D) H must ignore the instruction at machine
address [00000d07]. *That is an incorrect simulation of D*

H does not ignore that instruction and simulates itself simulating D.
The simulated H outputs its own execution trace of D.

On 05.jun.2024 at 15:59 (CET) olcott proved that in the example

int main()
{
;    Output("Input_Halts = ", HH(main,(ptr)0));
}

main halts and HH reported a non-halting behaviour.

I cannot and will not tolerate the strawman deception
change-the-subject fake rebuttal.

That is the easiest way to ignore that it is just a proven false
negative: Remove the proof and claim that it is a change of subject.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Op 10.jun.2024 om 15:52 schreef olcott:

On 6/10/2024 2:09 AM, Fred. Zwarts wrote:

Op 10.jun.2024 om 07:17 schreef olcott:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022> >>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are
asking a question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically
impossible. So, either it is a correct simulation and then we see
that the simulated HH aborts and returns, or the simulation is
incorrect, because it assumes incorrectly that things that happen
(abort) do not happen.
A premature conclusion.

*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*

On 5/29/2021 2:26 PM, olcott wrote:
https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ

THE ONLY POSSIBLE WAY for D simulated by H to have the same
behavior as the directly executed D(D) is for the instructions
of D to be incorrectly simulated by H (details provided below).

_D()
[00000cfc](01)  55                      push ebp
[00000cfd](02)  8bec                    mov ebp,esp
[00000cff](03)  8b4508                  mov eax,[ebp+08] >>> [00000d02](01)  50                      push eax       ; push D
[00000d03](03)  8b4d08                  mov ecx,[ebp+08] >>> [00000d06](01)  51                      push ecx       ; push D
[00000d07](05)  e800feffff              call 00000b0c  ; call H
[00000d0c](03)  83c408                  add esp,+08
[00000d0f](02)  85c0                    test eax,eax >>> [00000d11](02)  7404                    jz 00000d17
[00000d13](02)  33c0                    xor eax,eax
[00000d15](02)  eb05                    jmp 00000d1c >>> [00000d17](05)  b801000000              mov eax,00000001
[00000d1c](01)  5d                      pop ebp
[00000d1d](01)  c3                      ret
Size in bytes:(0034) [00000d1d]

In order for D simulated by H to have the same behavior as the
directly executed D(D) H must ignore the instruction at machine
address [00000d07]. *That is an incorrect simulation of D*

H does not ignore that instruction and simulates itself simulating D.
The simulated H outputs its own execution trace of D.

On 05.jun.2024 at 15:59 (CET) olcott proved that in the example

int main()
{
;    Output("Input_Halts = ", HH(main,(ptr)0));
}

main halts and HH reported a non-halting behaviour. This means that
when HH is used as a test for halting, it produces a false negative.

I just proved that D correctly simulated by H has different
behavior than the directly executed D(D) and you ignored it.

There is no D in the example where your proved that HH produces a false negative.

So, I can repeat what you removed:

Olcott is rather silent about this result, probably, because in this
case he can not make a difference between the direct execution and the simulation. In the D case he argues that the order of D and H makes a difference. When D starts and calls H would be different from when H
starts and simulates D. In the above example, it is not possible to
change the order.

Since olcott himself has proven that HH produces a false negative, why
does he continue to claim that there should be a difference between
direct execution and simulation? This is again a false negative.
HH, nor H can be used as a test for halting of a program, at best as a
test for halting of olcott's simulator, but is not interesting for most
people.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/10/24 11:09 AM, olcott wrote:

On 6/10/2024 2:48 AM, Mikko wrote:

On 2024-06-09 14:13:23 +0000, olcott said:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022> >>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are
asking a question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically
impossible. So, either it is a correct simulation and then we see
that the simulated HH aborts and returns, or the simulation is
incorrect, because it assumes incorrectly that things that happen
(abort) do not happen.
A premature conclusion.

I have a clearer explanation now that I have gone through
all of Mikko's posts: (you must know C to understand this)

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

As the code above shows, HHH is not a simulating halt decider:
(a) HHH does not simulate, (b) HHH does not decide.
Consequently, you are talking about nothing.

Yes that is correct. I begin with ordinary infinite recursion.
If my reviewer does not understand that then they lack sufficient
technical competence to review my work.

After they first understand infinite recursion then I show how
infinite recursion is isomorphic to nested simulation.

Except that YOU fail to see the differences between the two, and so you
get stuck in your lies.

And, because you reuse names, it shows a proable intent to be deceptive.

It might be that YOU can't get in your mind the similarities without
reusing the names in that deceptive manner, but it just acts like a sign
of being deceptive to the rest of us.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Op 10.jun.2024 om 21:47 schreef olcott:

On 6/10/2024 2:41 PM, Fred. Zwarts wrote:

That is the easiest way to ignore that it is just a proven false
negative: Remove the proof and claim that it is a change of subject.

*You did not prove that this is false you only ignored it*
*You did not prove that this is false you only ignored it*
*You did not prove that this is false you only ignored it*

 D correctly simulated by H proved for THREE YEARS ---

*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*

On 5/29/2021 2:26 PM, olcott wrote: https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ

THE ONLY POSSIBLE WAY for D simulated by H to have the same
behavior as the directly executed D(D) is for the instructions
of D to be incorrectly simulated by H (details provided below).

Proven false. The direct execution does not ignore the call to H. So, to
get the same behaviour, the simulation should also simulate the call.
The problem is that H is required to halt and return from the call, but
your H does not return as required. It can't, because it is prematurely aborted. This proves that a simulation is unable to simulate itself up
to the end. This is what causes the false negatives.

_D()
[00000cfc](01) 55          push ebp
[00000cfd](02) 8bec        mov ebp,esp
[00000cff](03) 8b4508      mov eax,[ebp+08]
[00000d02](01) 50          push eax       ; push D [00000d03](03) 8b4d08      mov ecx,[ebp+08]
[00000d06](01) 51          push ecx       ; push D [00000d07](05) e800feffff  call 00000b0c  ; call H
[00000d0c](03) 83c408      add esp,+08
[00000d0f](02) 85c0        test eax,eax
[00000d11](02) 7404        jz 00000d17
[00000d13](02) 33c0        xor eax,eax
[00000d15](02) eb05        jmp 00000d1c
[00000d17](05) b801000000  mov eax,00000001
[00000d1c](01) 5d          pop ebp
[00000d1d](01) c3          ret
Size in bytes:(0034) [00000d1d]

Olcott has shown this and similar code, both in C as in x86 code for
several years now. He was never able to prove the claim that it never
reaches past the call at 00000d07. He thinks that he needs an expert in
C or x86 to give the proof. So he has been begging desperately for years
in several newsgroups if an expert can show the proof. This has never
resulted in a proof. In fact most reactions from the experts are that
such a proof is impossible because the requirements for H are unclear.
Olcott wants contradicting requirements for H. At the one hand he wants
H to halt and, therefore, to return to its caller, at the other hand he
wants a proof that H, called at 0000d07 does not return to its caller.

It is a great puzzle for me why he keeps believing in these
contradictory properties of H. If he could prove that the call at
0000d07 does not return, he would prove at the same time that H is not a halting function, violating its requirement.

My interest is no longer in the computation theory behind this question,
but in the psychological aspect. How is it possible that somewhat wants
to prove that a H with contradictory properties exists?

The only reason I can think of, is that he has spent so many years in
this subject, that he is unable to see the truth. He is unable to read
and to grasp the proof and stays in rebuttal mode, without even
considering for one moment that he could be wrong.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-06-10 15:09:19 +0000, olcott said:

On 6/10/2024 2:48 AM, Mikko wrote:

On 2024-06-09 14:13:23 +0000, olcott said:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022> >>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are asking a >>>> question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically impossible. >>>> So, either it is a correct simulation and then we see that the
simulated HH aborts and returns, or the simulation is incorrect,
because it assumes incorrectly that things that happen (abort) do not
happen.
A premature conclusion.

I have a clearer explanation now that I have gone through
all of Mikko's posts: (you must know C to understand this)

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

As the code above shows, HHH is not a simulating halt decider:
(a) HHH does not simulate, (b) HHH does not decide.
Consequently, you are talking about nothing.

Yes that is correct. I begin with ordinary infinite recursion.
If my reviewer does not understand that then they lack sufficient
technical competence to review my work.

After they first understand infinite recursion then I show how
infinite recursion is isomorphic to nested simulation.

To proove an isomorphism required much more effort that proving merely
what you need to prove. It is easier to prove a claim about recursive
calls and then transform that proof to a proof about nested simulation.
Other aspects of an isomorphism are not relevant so hardly worth of a
proof.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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

On 6/10/2024 2:09 AM, Fred. Zwarts wrote:

Op 10.jun.2024 om 07:17 schreef olcott:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022> >>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are
asking a question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically
impossible. So, either it is a correct simulation and then we see
that the simulated HH aborts and returns, or the simulation is
incorrect, because it assumes incorrectly that things that happen
(abort) do not happen.
A premature conclusion.

*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*

On 5/29/2021 2:26 PM, olcott wrote:
https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ

THE ONLY POSSIBLE WAY for D simulated by H to have the same
behavior as the directly executed D(D) is for the instructions
of D to be incorrectly simulated by H (details provided below).

_D()
[00000cfc](01)  55                      push ebp
[00000cfd](02)  8bec                    mov ebp,esp
[00000cff](03)  8b4508                  mov eax,[ebp+08] >>> [00000d02](01)  50                      push eax       ; push D
[00000d03](03)  8b4d08                  mov ecx,[ebp+08] >>> [00000d06](01)  51                      push ecx       ; push D
[00000d07](05)  e800feffff              call 00000b0c  ; call H
[00000d0c](03)  83c408                  add esp,+08
[00000d0f](02)  85c0                    test eax,eax >>> [00000d11](02)  7404                    jz 00000d17
[00000d13](02)  33c0                    xor eax,eax
[00000d15](02)  eb05                    jmp 00000d1c >>> [00000d17](05)  b801000000              mov eax,00000001
[00000d1c](01)  5d                      pop ebp
[00000d1d](01)  c3                      ret
Size in bytes:(0034) [00000d1d]

In order for D simulated by H to have the same behavior as the
directly executed D(D) H must ignore the instruction at machine
address [00000d07]. *That is an incorrect simulation of D*

H does not ignore that instruction and simulates itself simulating D.
The simulated H outputs its own execution trace of D.

On 05.jun.2024 at 15:59 (CET) olcott proved that in the example

int main()
{
;    Output("Input_Halts = ", HH(main,(ptr)0));
}

main halts and HH reported a non-halting behaviour. This means that
when HH is used as a test for halting, it produces a false negative.

I just proved that D correctly simulated by H has different
behavior than the directly executed D(D) and you ignored it.

Nope. You just proved that your H doesn't correct simulatie its input,
because it doesn't correctly simulate the CALL H instruction.

The CALL H innstruction, to be correctly simulated, must be followed by
a simulation of the instructions that follow.

SInce that ISN'T what H did, at least per your listing, it just never
did a correct simulation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/10/24 3:21 PM, olcott wrote:

I cannot and will not tolerate the strawman deception
change-the-subject fake rebuttal.

Of course, you think you are the only one that can do that.

*I just proved that D correctly simulated by H has different*
*behavior than the directly executed D(D) and you ignored it*

Nope, you proved that H doesn't correctly simulate the input.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-06-10 15:09:19 +0000, olcott said:

On 6/10/2024 2:48 AM, Mikko wrote:

On 2024-06-09 14:13:23 +0000, olcott said:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:

<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 words10/13/2022> >>>>>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>  > that P(P) *would* never stop running *unless* aborted.

Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

Stopping at your first error. So, we can focus on it. Your are asking a >>>> question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to
the point where the simulated HH aborts. That is logically impossible. >>>> So, either it is a correct simulation and then we see that the
simulated HH aborts and returns, or the simulation is incorrect,
because it assumes incorrectly that things that happen (abort) do not
happen.
A premature conclusion.

I have a clearer explanation now that I have gone through
all of Mikko's posts: (you must know C to understand this)

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

As the code above shows, HHH is not a simulating halt decider:
(a) HHH does not simulate, (b) HHH does not decide.
Consequently, you are talking about nothing.

Yes that is correct.

Nice to see that you agree that you are talking obout nothing.

I begin with ordinary infinite recursion.
If my reviewer does not understand that then they lack sufficient
technical competence to review my work.

I don't think you can infer so much from a failure to understand what
you are trying to say about nothing.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)