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

Python <[email protected]> writes:

Olcott (annotated):

If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running

[comment: as D halts, the simulation is faulty, Pr. Sipser has been
fooled by Olcott shell game confusion "pretending to simulate" and
"correctly simulate"]

unless aborted then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.

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.

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

DD correctly simulated by HHH cannot possibly reach its
own "return" instruction final halt state thus is correctly
rejected as non-halting.

This is not actually contradicted by the fact that the
directly executed DD() does halt because directly
executed Turing machines are not actually in the domain
of any Turing machine based decider.

*Here is the corrected Linz Ĥ machine*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.

https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf



--
Copyright 2024 Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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

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


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

Python <[email protected]> writes:

Olcott (annotated):

If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running

[comment: as D halts, the simulation is faulty, Pr. Sipser has been
fooled by Olcott shell game confusion "pretending to simulate" and
"correctly simulate"]

unless aborted then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.

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.

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

DD correctly simulated by HHH cannot possibly reach its
own "return" instruction final halt state thus is correctly
rejected as non-halting.

This is not actually contradicted by the fact that the
directly executed DD() does halt because directly
executed Turing machines are not actually in the domain
of any Turing machine based decider.

*Here is the corrected Linz Ĥ machine*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.

https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

--
Copyright 2024 Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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

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

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

Which your H doesn't satisfy.

First, your claim your H and D aren't programs, and thus are category
errors to try to apply this.

To use this, H must be a SPECIFIC program, with a definite algorithm,
and not an "infinte set" of them. (You can have an infinite set of them,
but you look at each one individually).

And, D includes the code for H as that is part of its algorithm, and
thus is part of its representation, and thus each (H,D) pairing creates
a different D, totally distinct, and thus you can't talk about "H
simulates 1 to infinity steps of D", as each H in that set simulated a DIFFERENT D, and thus you can't just combine those results.

When you fix this, then you have the problem that H can nover correctly
decide this, as if H does, then it doesn't do a correct simulation by
the definition of the system, but the correct simulation of that input,
which is the D that calls THIS H, that aborts is simulation and returns
0, will simulate to the point of that abort (which will be long after
the simulation that H does aborted its simulation, and so it has no
knowledge of this behavior) and see it return 0 to D which will then halt.

Since the correct simulation of the input halts, there is no way that H
can correctly determine such a thing to never halt.

The preasumption that it can is just a error, and repeating it after
being pointed out is just a LIE.

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

Python <[email protected]> writes:

Olcott (annotated):

   If simulating halt decider H correctly simulates its input D until H >>>    correctly determines that its simulated D would never stop running

   [comment: as D halts, the simulation is faulty, Pr. Sipser has been >>>     fooled by Olcott shell game confusion "pretending to simulate" and >>>     "correctly simulate"]

   unless aborted then H can abort its simulation of D and correctly
   report that D specifies a non-halting sequence of configurations.

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.

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

DD correctly simulated by HHH cannot possibly reach its
own "return" instruction final halt state thus is correctly
rejected as non-halting.

But you HHH doesn't correctly simulate DD, so this doesn't apply, and
making the claim is just a lie.

In fact, as described above, the correct simulation of DD will reach a
final state and halt, and thus you claims are just a LIE.

This is not actually contradicted by the fact that the
directly executed DD() does halt because directly
executed Turing machines are not actually in the domain
of any Turing machine based decider.

Sure it is, as the DEFINITION of "Correct Simulation" is to totally
replicate the behavior of the direct execution of the machine the input describes.

Thus, you are just admitting that you have no idea of the meaning of the
words you are using, and by repeating this after being told so, becomes
a LIE, and shows that you don't understand how logic work.

It seems that you think you can change definitions, which you aren't,
which is what makes you a pathological liar who doesn't care about the
rules or what is truth.

*Here is the corrected Linz Ĥ machine*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
   if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
   its simulated final halt state of ⟨Ĥ.qn⟩, and

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
   reach its simulated final halt state of ⟨Ĥ.qn⟩.

https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Which is just a LIE, as the simulation of Ĥ.embedded_H is not a definer
of halting, again just showing your ignorance and disregarding of what
is truth,

Sorry, you are just torpedoing your reputation with every repeat of your errors, which just PROVES that you are just totally IGNORANT of the
meaning of the words, and that you just don't care about what is right,
just what you believe.

You are just showing that you are living in a false fantasy world that
doesn't care about the actual rules of the games, and thus doesn't lead
to truth. THAT is your life, and your future.

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

Op 26.jul.2025 om 01:36 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>

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

Python <[email protected]> writes:

Olcott (annotated):

   If simulating halt decider H correctly simulates its input D until H >>>    correctly determines that its simulated D would never stop running

   [comment: as D halts, the simulation is faulty, Pr. Sipser has been >>>     fooled by Olcott shell game confusion "pretending to simulate" and >>>     "correctly simulate"]

   unless aborted then H can abort its simulation of D and correctly
   report that D specifies a non-halting sequence of configurations.

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.

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

DD correctly simulated by HHH cannot possibly reach its
own "return" instruction final halt state thus is correctly
rejected as non-halting.

Irrelevant, because HHH cannot correctly simulate itself up to the end.
There is no correct simulation. When the condition is not met, the
conclusion is irrelevant.

This is not actually contradicted by the fact that the
directly executed DD() does halt because directly
executed Turing machines are not actually in the domain
of any Turing machine based decider.

No, but the description of the Turing Machine in the input specifies
what would happen when directly executed. That does belong to the domain.

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

On 7/26/25 9:18 AM, olcott wrote:

On 7/26/2025 4:10 AM, Fred. Zwarts wrote:

Op 26.jul.2025 om 01:36 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>


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

Python <[email protected]> writes:

Olcott (annotated):

   If simulating halt decider H correctly simulates its input D
until H
   correctly determines that its simulated D would never stop running >>>>>
   [comment: as D halts, the simulation is faulty, Pr. Sipser has been >>>>>     fooled by Olcott shell game confusion "pretending to simulate" and >>>>>     "correctly simulate"]

   unless aborted then H can abort its simulation of D and correctly >>>>>    report that D specifies a non-halting sequence of configurations. >>>>

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

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

DD correctly simulated by HHH cannot possibly reach its
own "return" instruction final halt state thus is correctly
rejected as non-halting.

Irrelevant, because HHH cannot correctly simulate itself up to the end.
There is no correct simulation. When the condition is not met, the
conclusion is irrelevant.

You have the requirement incorrectly

<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

No, you do.

Remember, to use this D and H need to be programs, and thus fully
include all of the code they use.

Thus, if H DOES eventually abort and return 0, that code IS in H, AND D,
and thus H doesn't actually do a correct simulation per the meaning of
the term-of-art, and the correct simulation of D will, after the point
that H aborts its partial simulation, reach the point that the simulated
H also aborts and returns 0, and thus cause the correct simulation of D
to halt.

The phrase "H correctly simulate its input" is just a meaningless lie.

And H can never correctly determine that ANY correct simulation (let
alone its non-existant one) will never halt, as it does halt.

All you are proving is that you think lies are valid logic forms, and
thus that your logic is just patholological lying.

This is not actually contradicted by the fact that the
directly executed DD() does halt because directly
executed Turing machines are not actually in the domain
of any Turing machine based decider.

No, but the description of the Turing Machine in the input specifies
what would happen when directly executed. That does belong to the domain.

Proven to be counter-factual by the execution trace of
DDD emulated by HHH (according to the rules of the x86
language) in the case where an input calls its own simulating
termination analyzer.

No, your "proof" is proven to be counter-factual as your HHH doesn't
follow ALL of the rules of the x86 languge, which requires EVERY
(non-final) instruction to be followed in execution/simulation by the
next one defined by the exeuction order.

Sorry, you are just the poster child for GIGO.

_DDD()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6892210000 push 00002192  // push DDD
[0000219a] e833f4ffff call 000015d2  // call HHH
[0000219f] 83c404     add esp,+04
[000021a2] 5d         pop ebp
[000021a3] c3         ret
Size in bytes:(0018) [000021a3]

Can't be the full input, as the call HHH can not be simulated.

When we fix this by adding the code of HHH from Halt7.c, then you claim
that HHH correctly simulates its input is proven to be a lie, as it only
does a PARTIAL simulation.

DDD emulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state.

Only because HHH doesn't fully simulate per the rules of the x86 language.

The correct simulation of DDD, when including the only allowed
definition from Halt7.c, shows that it WILL reach that final state.

Sorry, but you LYING by using incorrect definitions just proves your
ignorance.

Are you not getting this due to lack of technical
competence or dishonesty?

No, it seems you are though, and that you don't care that you are
ignorant of the actual meaning of the word you use, but are willing to
just make yourself a pathological liar by your disregard of them.

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

Am Sat, 26 Jul 2025 08:18:55 -0500 schrieb olcott:

On 7/26/2025 4:10 AM, Fred. Zwarts wrote:

Op 26.jul.2025 om 01:36 schreef olcott:

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.

Ben wasn't agreeing with you here.

Irrelevant, because HHH cannot correctly simulate itself up to the end.
There is no correct simulation. When the condition is not met, the
conclusion is irrelevant.

You have the requirement incorrectly

No, DDD would actually stop running if simulated further, although
naturally HHH can't do it, as you have shown.

This is not actually contradicted by the fact that the directly
executed DD() does halt because directly executed Turing machines are
not actually in the domain of any Turing machine based decider.

No, but the description of the Turing Machine in the input specifies
what would happen when directly executed. That does belong to the
domain.

Proven to be counter-factual by the execution trace of DDD emulated by
HHH in the case where an input calls its own simulating termination
analyzer.

The uncountered facts are that an UTM can produce the same trace as the
direct execution.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Op 26.jul.2025 om 21:07 schreef olcott:

On 7/26/2025 1:42 PM, joes wrote:

Am Sat, 26 Jul 2025 08:18:55 -0500 schrieb olcott:

On 7/26/2025 4:10 AM, Fred. Zwarts wrote:

Op 26.jul.2025 om 01:36 schreef olcott:

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.

Ben wasn't agreeing with you here.

counter-factual.
Ben perfectly agreed with exactly half of what I said.
Ben agreed that the Sipser approved criteria was 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 words 10/13/2022>

It does not matter whether he agreed or not, because it is a vacuous
statement. H does not do a correct simulation. H does not correctly
determines never stop running.
When the conditions are not met, the conclusion is irrelevant and the
whole statement is vacuous.

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

Op 26.jul.2025 om 15:18 schreef olcott:

On 7/26/2025 4:10 AM, Fred. Zwarts wrote:

Op 26.jul.2025 om 01:36 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>


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

Python <[email protected]> writes:

Olcott (annotated):

   If simulating halt decider H correctly simulates its input D
until H
   correctly determines that its simulated D would never stop running >>>>>
   [comment: as D halts, the simulation is faulty, Pr. Sipser has been >>>>>     fooled by Olcott shell game confusion "pretending to simulate" and >>>>>     "correctly simulate"]

   unless aborted then H can abort its simulation of D and correctly >>>>>    report that D specifies a non-halting sequence of configurations. >>>>

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

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

DD correctly simulated by HHH cannot possibly reach its
own "return" instruction final halt state thus is correctly
rejected as non-halting.

Irrelevant, because HHH cannot correctly simulate itself up to the end.
There is no correct simulation. When the condition is not met, the
conclusion is irrelevant.

You have the requirement incorrectly

<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

This is not actually contradicted by the fact that the
directly executed DD() does halt because directly
executed Turing machines are not actually in the domain
of any Turing machine based decider.

No, but the description of the Turing Machine in the input specifies
what would happen when directly executed. That does belong to the domain.

Proven to be counter-factual by the execution trace of
DDD emulated by HHH (according to the rules of the x86
language) in the case where an input calls its own simulating
termination analyzer.

No proof, but invalid claims without evidence, using a failing HHH that
is unable to follow the specification of the x86 code up to the end.

_DDD()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6892210000 push 00002192  // push DDD
[0000219a] e833f4ffff call 000015d2  // call HHH
[0000219f] 83c404     add esp,+04
[000021a2] 5d         pop ebp
[000021a3] c3         ret
Size in bytes:(0018) [000021a3]

DDD emulated by HHH according to the rules of the x86
language cannot possibly reach its own "ret" instruction
final halt state.

Yes, we know that HHH fails to reach the final halt state due to a
premature abort. Whey repeating HHH's failure?

Are you not getting this due to lack of technical
competence or dishonesty?

Irrelevant and incorrect questions are no rebuttal.

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

On 7/28/25 9:42 AM, olcott wrote:

On 7/28/2025 4:22 AM, Fred. Zwarts wrote:

Op 26.jul.2025 om 21:07 schreef olcott:

On 7/26/2025 1:42 PM, joes wrote:

Am Sat, 26 Jul 2025 08:18:55 -0500 schrieb olcott:

On 7/26/2025 4:10 AM, Fred. Zwarts wrote:

Op 26.jul.2025 om 01:36 schreef olcott:

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.

Ben wasn't agreeing with you here.

counter-factual.
Ben perfectly agreed with exactly half of what I said.
Ben agreed that the Sipser approved criteria was 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 words 10/13/2022>

It does not matter whether he agreed or not, because it is a vacuous
statement. H does not do a correct simulation. H does not correctly
determines never stop running.
When the conditions are not met, the conclusion is irrelevant and the
whole statement is vacuous.

*A more conventional way of saying that is*

If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*cannot possibly reach its own simulated final state*

Which has to mean the correct simulation of it input, not ITS simulation
of the input.

Since the halt decider must be fixed code, it can't both abort its
simulation and do a correct simulation.

If it never does a correct simulation, you can't determine what its
correct simulation would be.

That is why the proper statement doesn't restict the correct simulation
to something that doesn't do one.

That just makes your criteria nonsense.

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

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*cannot possibly reach its own simulated final state*

No, it is not more conventional, only more deceptive.

If we said that halting is stopping running
for any reason then HHH would have to say
that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either
halting or non-halting but not both even if the execution is never
started.

--
Mikko

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

On 7/31/25 11:57 AM, olcott wrote:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*cannot possibly reach its own simulated final state*

No, it is not more conventional, only more deceptive.

If we said that halting is stopping running
for any reason then HHH would have to say
that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either
halting or non-halting but not both even if the execution is never
started.

void DDD()
{
  HHH(DDD);
  return;
}

Halting is only defined as reaching one's own "return"
statement final halt state.

DDD correctly simulated by HHH cannot possibly do that.

But your HHH doesn't correcxt simulate DDD, as if it did, it would fail
to answer.

Note, different HHHs get different DDDs, so you can't move one HHHs
simulation to another.

Sorry, you are just showing that you "logic" is based on LYING>

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

On 7/31/25 7:40 PM, olcott wrote:

On 7/31/2025 6:17 PM, Richard Damon wrote:

On 7/31/25 11:57 AM, olcott wrote:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*cannot possibly reach its own simulated final state*

No, it is not more conventional, only more deceptive.

If we said that halting is stopping running
for any reason then HHH would have to say
that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either
halting or non-halting but not both even if the execution is never
started.

void DDD()
{
   HHH(DDD);
   return;
}

Halting is only defined as reaching one's own "return"
statement final halt state.

DDD correctly simulated by HHH cannot possibly do that.

But your HHH doesn't

Every DDD simulated by each HHH that can possibly exist
cannot possibly reach its own final halt state.

Sure it does, just not in the simulation by HHH, but after the point
where the HHH gave up on it.

Unless HHH simulated to the end, it doesn't show that DDD doesn't make
it to the end,

SInce there is no correct induction to prove the non-halting of DDD, you
can't make you claim from the partial simulation that the complete
emulaiton won't reach the end.

In fact, we CAN prove that it will.

Sorry, you are just proving you stupidity, that you hide your head in
your lies to try to ignore the truth.

All that does is show your stupidity.

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

On 2025-07-31 15:57:34 +0000, olcott said:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*cannot possibly reach its own simulated final state*

No, it is not more conventional, only more deceptive.

If we said that halting is stopping running
for any reason then HHH would have to say
that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either
halting or non-halting but not both even if the execution is never
started.

void DDD()
{
HHH(DDD);
return;
}

Halting is only defined as reaching one's own "return"
statement final halt state.

DDD correctly simulated by HHH cannot possibly do that.

DDD is specified to halt. HHH cannot fully reproduce the specified
behaviour nor otherwise determine that it nalts.

--
Mikko

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

Am Thu, 31 Jul 2025 18:40:24 -0500 schrieb olcott:

On 7/31/2025 6:17 PM, Richard Damon wrote:

On 7/31/25 11:57 AM, olcott wrote:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If we said that halting is stopping running for any reason then HHH
would have to say that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either
halting or non-halting but not both even if the execution is never
started.

Halting is only defined as reaching one's own "return" statement final
halt state.

DDD correctly simulated by HHH cannot possibly do that.

But your HHH doesn't

Every DDD simulated by each HHH that can possibly exist cannot possibly
reach its own final halt state.

We should be comparing the simulations of the one DDD that exists.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 8/1/25 10:50 AM, olcott wrote:

On 8/1/2025 2:07 AM, joes wrote:

Am Thu, 31 Jul 2025 18:40:24 -0500 schrieb olcott:

On 7/31/2025 6:17 PM, Richard Damon wrote:

On 7/31/25 11:57 AM, olcott wrote:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If we said that halting is stopping running for any reason then HHH >>>>>>> would have to say that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either >>>>>> halting or non-halting but not both even if the execution is never >>>>>> started.

Halting is only defined as reaching one's own "return" statement final >>>>> halt state.

DDD correctly simulated by HHH cannot possibly do that.

But your HHH doesn't

Every DDD simulated by each HHH that can possibly exist cannot possibly
reach its own final halt state.

We should be comparing the simulations of the one DDD that exists.

That is more confusing. People can't seem to see
the repeating pattern until after it repeats ten times.

Because all those other patterns aren't the truth about the HHH that you
have.

void DDD()
{
  HHH(DDD);
  return;
}

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0

And the unaltered behavior of the process continues one more cycle and
halts.

HHH is asked about the unalterd process, not the partial simulation tha
it does.

You are just stuck with you lies that you so stupidly believe.

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

On 8/1/25 10:58 AM, olcott wrote:

On 8/1/2025 1:53 AM, Mikko wrote:

On 2025-07-31 15:57:34 +0000, olcott said:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*cannot possibly reach its own simulated final state*

No, it is not more conventional, only more deceptive.

If we said that halting is stopping running
for any reason then HHH would have to say
that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either
halting or non-halting but not both even if the execution is never
started.

void DDD()
{
   HHH(DDD);
   return;
}

Halting is only defined as reaching one's own "return"
statement final halt state.

DDD correctly simulated by HHH cannot possibly do that.

DDD is specified to halt. HHH cannot fully reproduce the specified
behaviour nor otherwise determine that it nalts.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

Which since it DOES abort its simulation, is like saying if pi was 3
then ...

(2) I have never been taking about DDD() the behavior of a non-input.
Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.

Then you have never been talking about the halting problem, and just
admitted that you wasted the last 20 years of your life on a lie.

(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.

No, making a claim about DDD simulated by HHH and saying that has
meaning for the halting problem is the strawman error.

The error that cost you the last 20 years of your work to your own lies.

void DDD()
{
  HHH(DDD);
  return;
}

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0

And the undisturbed behavior of that process, which is what the halting
problem is asking about, continues for one more cycle, then halts.

All you are doing is proving that you are so stupid you beleive your own ignorant lies because you refuse to learn the meaning of the words you used.

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

Am Fri, 01 Aug 2025 09:50:00 -0500 schrieb olcott:

On 8/1/2025 2:07 AM, joes wrote:

Am Thu, 31 Jul 2025 18:40:24 -0500 schrieb olcott:

On 7/31/2025 6:17 PM, Richard Damon wrote:

On 7/31/25 11:57 AM, olcott wrote:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If we said that halting is stopping running for any reason then
HHH would have to say that these two functions halt.

That is a good reason to not say so. After all, a behaviour is
either halting or non-halting but not both even if the execution is >>>>>> never started.

Halting is only defined as reaching one's own "return" statement
final halt state.

DDD correctly simulated by HHH cannot possibly do that.

But your HHH doesn't

Every DDD simulated by each HHH that can possibly exist cannot
possibly reach its own final halt state.

We should be comparing the simulations of the one DDD that exists.

That is more confusing. People can't seem to see the repeating pattern
until after it repeats ten times.

Confusing? It is a different thing.
The 10 (finite!) repetitions have been acknowledged by everybody. HHH
doesn't run forever, and neither does DDD, precisely because *its*
HHH aborts.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 8/1/25 11:35 AM, olcott wrote:

On 8/1/2025 10:16 AM, joes wrote:

Am Fri, 01 Aug 2025 09:50:00 -0500 schrieb olcott:

On 8/1/2025 2:07 AM, joes wrote:

Am Thu, 31 Jul 2025 18:40:24 -0500 schrieb olcott:

On 7/31/2025 6:17 PM, Richard Damon wrote:

On 7/31/25 11:57 AM, olcott wrote:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If we said that halting is stopping running for any reason then >>>>>>>>> HHH would have to say that these two functions halt.

That is a good reason to not say so. After all, a behaviour is >>>>>>>> either halting or non-halting but not both even if the execution is >>>>>>>> never started.

Halting is only defined as reaching one's own "return" statement >>>>>>> final halt state.

DDD correctly simulated by HHH cannot possibly do that.

But your HHH doesn't

Every DDD simulated by each HHH that can possibly exist cannot
possibly reach its own final halt state.

We should be comparing the simulations of the one DDD that exists.

That is more confusing. People can't seem to see the repeating pattern
until after it repeats ten times.

Confusing? It is a different thing.
The 10 (finite!) repetitions have been acknowledged by everybody. HHH
doesn't run forever, and neither does DDD, precisely because *its*
HHH aborts.

I have told you this fifty times now.

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

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

The above two functions don't run forever either
when simulated by HHH.

So?

Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It detects a non-terminating behavior pattern then it aborts its simulation and returns 0,

except that some of the patterns it calls non-terminating ARE
terminating, and thus are wrong.

(b) Its simulated input reaches its simulated "return" statement then it returns 1.

DDD correctly simulated by HHH cannot possibly reach
its own final halt state.

But DDD isn't correctly simuated by HHH.

And THIS DDD, when correctly simulated halts.

The problem is you LIE about what DDD is, as it needs to be a FULL
PROGRAM, which means it includes the code for THE HHH that it calls, and
thus changing HHH as you try is just a LIE as you end up with a
DIFFERENT DDD.

without the code of HHH, you can't "simulate the input" past the call
HHH instruction.

Thus, all you have done is proved that you logic is based on LYING
because you just don't understand what you are talking about.

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

On 2025-08-01 14:58:28 +0000, olcott said:

On 8/1/2025 1:53 AM, Mikko wrote:

On 2025-07-31 15:57:34 +0000, olcott said:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*cannot possibly reach its own simulated final state*

No, it is not more conventional, only more deceptive.

If we said that halting is stopping running
for any reason then HHH would have to say
that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either
halting or non-halting but not both even if the execution is never
started.

void DDD()
{
   HHH(DDD);
   return;
}

Halting is only defined as reaching one's own "return"
statement final halt state.

DDD correctly simulated by HHH cannot possibly do that.

DDD is specified to halt. HHH cannot fully reproduce the specified
behaviour nor otherwise determine that it nalts.

(1) That is counter-factual.

No, it is not.

Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

Yes, that is what I said.

(2) I have never been taking about DDD() the behavior of a non-input.
Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.

The behaviour specified by DDD is what the question is about. That
your HHH is unable to find the correct answer to that question does
not affect the meaning of the question or correctness of any answer.

(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.

When you make a claim about "DDD simulated by HHH" you apparently
don't know what the words mean. The DDD simulated by HHH is the
same as DDD executed directly and it specifies the same behaviour
no matter how you call it.

But the halting problem is about the direct execution. If you are
talking about something else you are talking about something else.
When you pretend to talk about halting problem when you actually
talk about simulation by HHH you lying.

--
Mikko

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

On 8/2/25 9:33 AM, olcott wrote:

On 8/2/2025 2:43 AM, Mikko wrote:

On 2025-08-01 14:58:28 +0000, olcott said:

On 8/1/2025 1:53 AM, Mikko wrote:

On 2025-07-31 15:57:34 +0000, olcott said:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*cannot possibly reach its own simulated final state*

No, it is not more conventional, only more deceptive.

If we said that halting is stopping running
for any reason then HHH would have to say
that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either >>>>>> halting or non-halting but not both even if the execution is never >>>>>> started.

void DDD()
{
   HHH(DDD);
   return;
}

Halting is only defined as reaching one's own "return"
statement final halt state.

DDD correctly simulated by HHH cannot possibly do that.

DDD is specified to halt. HHH cannot fully reproduce the specified
behaviour nor otherwise determine that it nalts.

(1) That is counter-factual.

No, it is not.

Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

Yes, that is what I said.

(2) I have never been taking about DDD() the behavior of a non-input.
Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.

The behaviour specified by DDD is what the question is about. That
your HHH is unable to find the correct answer to that question does
not affect the meaning of the question or correctness of any answer.

(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.

When you make a claim about "DDD simulated by HHH" you apparently
don't know what the words mean. The DDD simulated by HHH is the
same as DDD executed directly and it specifies the same behaviour
no matter how you call it.

Counter factual

void DDD()
{
  HHH(DDD);
  return;
}

HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)

This is stipulated by the basic structure
of the relationship between DDD and each HHH.

Then you are stipulating that you HHH isn't allowed to abort its
simulation without making you a liar.>

But the halting problem is about the direct execution. If you are
talking about something else you are talking about something else.
When you pretend to talk about halting problem when you actually
talk about simulation by HHH you lying.

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

On 2025-08-02 13:33:04 +0000, olcott said:

On 8/2/2025 2:43 AM, Mikko wrote:

On 2025-08-01 14:58:28 +0000, olcott said:

On 8/1/2025 1:53 AM, Mikko wrote:

On 2025-07-31 15:57:34 +0000, olcott said:

On 7/31/2025 3:39 AM, Mikko wrote:

On 2025-07-30 15:13:41 +0000, olcott said:

On 7/30/2025 1:40 AM, Mikko wrote:

On 2025-07-28 13:42:09 +0000, olcott said:

If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
*cannot possibly reach its own simulated final state*

No, it is not more conventional, only more deceptive.

If we said that halting is stopping running
for any reason then HHH would have to say
that these two functions halt.

That is a good reason to not say so. After all, a behaviour is either >>>>>> halting or non-halting but not both even if the execution is never >>>>>> started.

void DDD()
{
   HHH(DDD);
   return;
}

Halting is only defined as reaching one's own "return"
statement final halt state.

DDD correctly simulated by HHH cannot possibly do that.

DDD is specified to halt. HHH cannot fully reproduce the specified
behaviour nor otherwise determine that it nalts.

(1) That is counter-factual.

No, it is not.

Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

Yes, that is what I said.

(2) I have never been taking about DDD() the behavior of a non-input.
Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.

The behaviour specified by DDD is what the question is about. That
your HHH is unable to find the correct answer to that question does
not affect the meaning of the question or correctness of any answer.

(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.

When you make a claim about "DDD simulated by HHH" you apparently
don't know what the words mean. The DDD simulated by HHH is the
same as DDD executed directly and it specifies the same behaviour
no matter how you call it.

Counter factual

Appearances can be false or misleading. However, in absense of contrary information, being true is more likely.

--
Mikko

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