XPost: comp.theory

Many times already olcott has claimed to have a proof.
Each time again it turned out that there was no proof.

Op 28.jul.2025 om 18:13 schreef olcott:

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

To make this easier to understand we replace line three
with the more conventional terminology this line:
"cannot possibly reach its own simulated final halt state then"

Which changes the meaning of the sentence, so you can no longer claim
that Sipser agreed to it.

In addition not-reaching the halt state can have more reasons than a non-halting sequence of instructions. E.g.: a computer being switched
off, a simulation aborted.

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.  He knows and accepts that
P(P) actually does stop.  The wrong answer is justified by what would
happen if H (and hence a different P) where not what they actually are.

Saying that H is required report on the behavior of
machine M is a category error.

Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.

Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.

No, because there is no difference between the specification of the
input and the direct execution. At most there is a difference between
what the simulator sees and the specification. But that indicates an
error in the simulator, not a change in the specification.

DDD correctly simulated by HHH cannot possibly
reach its own simulated "return" instruction
final halt state, thus overruling and superseding
the behavior of the directly executed DDD().

So, not possible to reach the final halt state can also bee a failure of
the simulator. That is the case in HHH.

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

XPost: comp.theory

On 7/29/25 5:34 PM, olcott wrote:

On 7/29/2025 3:37 AM, Fred. Zwarts wrote:

Many times already olcott has claimed to have a proof.
Each time again it turned out that there was no proof.

Op 28.jul.2025 om 18:13 schreef olcott:

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

To make this easier to understand we replace line three
with the more conventional terminology this line:
"cannot possibly reach its own simulated final halt state then"

Which changes the meaning of the sentence, so you can no longer claim
that Sipser agreed to it.

Yes

In addition not-reaching the halt state can have more reasons than a
non-halting sequence of instructions. E.g.: a computer being switched
off, a simulation aborted.

This is you not paying close enough attention to the exact
words that I exactly said.

I did not say: DOES NOT REACH ITS FINAL STATE (might have been aborted)
I said: CANNOT POSSIBLY REACH ITS FINAL STATE (aborted or not)

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.  He knows and accepts that >>>> P(P) actually does stop.  The wrong answer is justified by what would >>>> happen if H (and hence a different P) where not what they actually are. >>>>

Saying that H is required report on the behavior of
machine M is a category error.

Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.

Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.

No, because there is no difference between the specification of the
input and the direct execution.

*I have proven this to be counter-factual*

HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)

HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT
CALL HHH1(DDD)   --- [same behavior as direct execution]

The problem is since you HHH *DOES* abort, the input DDD is built on
that HHH, and includes THAT code, and thus if you give *THIS* input to a version of HHH that doesn't abort, it will simulate the HHH that DOES
abort, since that is what the input has in it. THus, the variant of HHH
that doesn't abort, *WILL* simulate *THIS* input to a final state.

Your argument LIED by changing the code in the input, because you LIE
about the input not containing the code of HHH. But, if it doesn't
contaiin that code, then either your HHH isn't "simulating its input" or
can't actually simulate this input, since it doesn't contain anything to simulate after the call to HHH.

That is where you make your error, and by refusing to accept that, you
just make yourself a pathological liar, showing that you don't know the
meaning of the words you are using.

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

XPost: comp.theory

On 7/29/25 9:36 PM, olcott wrote:

On 7/29/2025 8:28 PM, Richard Damon wrote:

On 7/29/25 5:34 PM, olcott wrote:

On 7/29/2025 3:37 AM, Fred. Zwarts wrote:

Many times already olcott has claimed to have a proof.
Each time again it turned out that there was no proof.

Op 28.jul.2025 om 18:13 schreef olcott:

<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> >>>>>
To make this easier to understand we replace line three
with the more conventional terminology this line:
"cannot possibly reach its own simulated final halt state then"

Which changes the meaning of the sentence, so you can no longer
claim that Sipser agreed to it.

Yes

In addition not-reaching the halt state can have more reasons than a
non-halting sequence of instructions. E.g.: a computer being
switched off, a simulation aborted.

This is you not paying close enough attention to the exact
words that I exactly said.

I did not say: DOES NOT REACH ITS FINAL STATE (might have been aborted)
I said: CANNOT POSSIBLY REACH ITS FINAL STATE (aborted or not)

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.  He knows and accepts >>>>>> that
P(P) actually does stop.  The wrong answer is justified by what would >>>>>> happen if H (and hence a different P) where not what they actually >>>>>> are.

Saying that H is required report on the behavior of
machine M is a category error.

Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.

Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.

No, because there is no difference between the specification of the
input and the direct execution.

*I have proven this to be counter-factual*

HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)

HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES
NOT CALL HHH1(DDD)   --- [same behavior as direct execution]

The problem is since you HHH *DOES* abort,

void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}

void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}

As it always does as soon as it correctly determines
that there exists no N steps of correct simulation
that can possibly reach the "return" instruction final
halt state.

But their is a N number of steps of the correct simulation of DDD that
cause it to halt, since HHH does abort its simulation and return 0.

That N is just bigger than the number of steps that HHH does, and thus
it can never know that result, but it is still the result of the correct simulation of the input.

It is clear you just don't understand what "correct" means, in part
because you don't understand basic terms like "truth" or "logic".

Sorry, you are just showing how stupid and ignorant you are, and that
you don't care that you don't actually know that the words you are using actually mean in this context, which is what makes you the pathological
liar you are.

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

XPost: comp.theory

Op 29.jul.2025 om 23:34 schreef olcott:

On 7/29/2025 3:37 AM, Fred. Zwarts wrote:

Many times already olcott has claimed to have a proof.
Each time again it turned out that there was no proof.

Op 28.jul.2025 om 18:13 schreef olcott:

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

To make this easier to understand we replace line three
with the more conventional terminology this line:
"cannot possibly reach its own simulated final halt state then"

Which changes the meaning of the sentence, so you can no longer claim
that Sipser agreed to it.

Yes

In addition not-reaching the halt state can have more reasons than a
non-halting sequence of instructions. E.g.: a computer being switched
off, a simulation aborted.

This is you not paying close enough attention to the exact
words that I exactly said.

I did not say: DOES NOT REACH ITS FINAL STATE (might have been aborted)
I said: CANNOT POSSIBLY REACH ITS FINAL STATE (aborted or not)

Yes it cannot possibly reach its final halt state, because it is
programmed to do a premature abort. A program cannot possibly do
something else that what the code specifies. In this case a premature
abort, preventing the simulated program to reach its final halt state.
When the simulated program is prevented to reach its final halt state,
that does not indicate non-halting behaviour of the program, only the
failure of the simulation and the 'detection' of non-halting.

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.  He knows and accepts that >>>> P(P) actually does stop.  The wrong answer is justified by what would >>>> happen if H (and hence a different P) where not what they actually are. >>>>

Saying that H is required report on the behavior of
machine M is a category error.

Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.

Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.

No, because there is no difference between the specification of the
input and the direct execution.

*I have proven this to be counter-factual*

No, you dreamed about it. That is not a proof. If it were true, you
could show us the instruction that is correctly simulated differently
from the direct execution. The only thing the traces show is that the simulation fails the correct simulation of a instruction when it does
not continue with the next one, violating the x86 language.

HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)

This 'itself' is HHH.

HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT
CALL HHH1(DDD)   --- [same behavior as direct execution]

Indeed, HHH1 must not simulate something different, but the same thing
as HHH tries to simulate: HHH.
(Your back is the same back that other people see, even if it is not
their back.)

HHH and HHH1 are simulating exactly the same thing: the code in the
input including HHH. Here HHH1 succeeds to reach the final halt state,
proving that this final halt states exists, but HHH fails to reach the
same final halt state specified in the input, closes it eyes when it
does a premature abort, and then assumes that what it does not see is
also not in the specification.
That is your logic: Close your eyes and pretend that what is not seen
does not exist.
Open your eyes. HHH and HHH1 have exactly the same input, specifying
exactly the same behaviour according to the x86 language. HHH1 sees the
full specification, but HHH sees only the first part of the
specification and misses the final part, because of a bug hat causes a premature abort. When it would count the conditional branch instructions encountered during the simulation it would be able to see that a finite recursion is not a pattern for non-halting.

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