Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:

It is a lack of technical ability on your part which is unable to
judge whether such a correct simulation is possible.  Everybody
else sees that it is not, so further questions about it are
non-sensical.

HHH emulates DDD in a separate process context. When this DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD process
context.

And that separate proccess, if left unaborted, would halt. But HHH
gives up and aborts it, so the process is Halting, not non-halting.

And HHH cannot simulate itself to its undeniable halting state.

This emulated HHH creates yet another process context to emulate its
own DDD. When this DDD calls yet another HHH(DDD) this provides enough
execution trace that the repeating pattern can be seen.

But the pattern isn't non-halting by the fact that DDD is shown to be
halting.

*No not at all. Not in the least little bit* Recursive simulation is
only a little more difficult than self recursion.

DDD halts if it weren't aborted.

When N instructions of DDD are correctly emulated by every HHH that can possibly exist (technically this is an infinite set of HHH/DDD pairs)
no emulated DDD can possibly halt and every directly executed DDD()
halts.

See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that
calls "HHH" symbolically, producing many different programs.

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

Am Thu, 31 Jul 2025 20:03:15 -0500 schrieb olcott:

On 7/31/2025 7:37 PM, Richard Damon wrote:

On 7/31/25 8:18 PM, olcott wrote:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

And that separate proccess, if left unaborted, would halt. But HHH
gives up and aborts it, so the process is Halting, not non-halting.

But the pattern isn't non-halting by the fact that DDD is shown to be
halting.

but since it is only finite recursion of partial simulation, since the
first level WILL abort the process and end the recursion.

When N instructions of DDD are correctly emulated by every HHH that
can possibly exist (technically this is an infinite set of HHH/DDD
pairs) no emulated DDD can possibly halt and every directly executed
DDD() halts.

Wrong, your problem is you forget that all those DDD are different,

It is an infinite set with every HHH/DDD pair having the same property
that each DDD cannot possibly halt.

Sure, but what about different HHH_n's simulating the same DDD?

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

HHH emulates DDD in a separate process context. When this DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD process
context.

And that separate proccess, if left unaborted, would halt. But HHH
gives up and aborts it, so the process is Halting, not non-halting.

And HHH cannot simulate itself to its undeniable halting state.

But the pattern isn't non-halting by the fact that DDD is shown to be
halting.

*No not at all. Not in the least little bit*

DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

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

They are accountable for their outputs.

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

DDD is not simulated forever by HHH.

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

When N instructions of DDD are correctly emulated by every HHH that
can possibly exist (technically this is an infinite set of HHH/DDD
pairs) no emulated DDD can possibly halt and every directly executed
DDD() halts.

See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that calls
"HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD pairs so that it could
be more easily understood that DDD simulated by HHH cannot possibly
halt.

Yes, you are talking about infinitely many counterexamples to infinitely
many "deciders".

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

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

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

Am Thu, 31 Jul 2025 20:03:15 -0500 schrieb olcott:

On 7/31/2025 7:37 PM, Richard Damon wrote:

On 7/31/25 8:18 PM, olcott wrote:

On 7/31/2025 7:07 PM, Richard Damon wrote:

And that separate proccess, if left unaborted, would halt. But HHH >>>>>> gives up and aborts it, so the process is Halting, not non-halting. >>>>>> But the pattern isn't non-halting by the fact that DDD is shown to >>>>>> be halting.

but since it is only finite recursion of partial simulation, since
the first level WILL abort the process and end the recursion.

When N instructions of DDD are correctly emulated by every HHH that
can possibly exist (technically this is an infinite set of HHH/DDD
pairs) no emulated DDD can possibly halt and every directly executed >>>>> DDD() halts.

Wrong, your problem is you forget that all those DDD are different,

It is an infinite set with every HHH/DDD pair having the same property
that each DDD cannot possibly halt.

Sure, but what about different HHH_n's simulating the same DDD?

Each element of the infinite set of HHH/DDD pairs that emulates a
natural number N number of instructions of DDD never halts. The machine
code bytes of DDD remain that same. The only thing that changes is the
code of HHH at machine address 000015d2.

That is exactly what makes them different programs. Now what about
HHH3 simulating DDD2?

--
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:22 AM, olcott wrote:

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

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

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

Am Thu, 31 Jul 2025 20:03:15 -0500 schrieb olcott:

On 7/31/2025 7:37 PM, Richard Damon wrote:

On 7/31/25 8:18 PM, olcott wrote:

On 7/31/2025 7:07 PM, Richard Damon wrote:

And that separate proccess, if left unaborted, would halt. But HHH >>>>>>>> gives up and aborts it, so the process is Halting, not non-halting. >>>>>>>> But the pattern isn't non-halting by the fact that DDD is shown to >>>>>>>> be halting.

but since it is only finite recursion of partial simulation, since >>>>>> the first level WILL abort the process and end the recursion.

When N instructions of DDD are correctly emulated by every HHH that >>>>>>> can possibly exist (technically this is an infinite set of HHH/DDD >>>>>>> pairs) no emulated DDD can possibly halt and every directly executed >>>>>>> DDD() halts.

Wrong, your problem is you forget that all those DDD are different, >>>>> It is an infinite set with every HHH/DDD pair having the same property >>>>> that each DDD cannot possibly halt.

Sure, but what about different HHH_n's simulating the same DDD?

Each element of the infinite set of HHH/DDD pairs that emulates a
natural number N number of instructions of DDD never halts. The machine
code bytes of DDD remain that same. The only thing that changes is the
code of HHH at machine address 000015d2.

That is exactly what makes them different programs. Now what about
HHH3 simulating DDD2?

What about the price of tea in China?
I am only proving that the conventional HP proofs
do not prove undecidability.

Sure they do.

HHH1(DDD) is identical to HHH(DDD) except that HHH1
is at a different machine address.

And thus, SHOULD return the same answer if it was correct.

The fact they give different answers means one of them is incorrect, as
is your logic.

Since you can't show what instruction correctly simulated per the x86
language standard differs, the fact that HHH's partial simuliaton gives
the wrong answer proves its simulation was in fact incorrect, and that
error is in the determination of what the actual correct simulation of
that last instruction is simulated means, because is DIDN'T simulate it
by the rules of the x86 language.

It ERRS in assuming that a call HHH doesn't need to be simulated because
"it knows" that a correct simulation of this code can never halt.

The problem is it makes a wrong assumption about the behavior of the
code that is there, as it is the HHH that DOES abort, while it assumes
it is not.

Sorry, you are just caught in your lies.

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

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

HHH emulates DDD in a separate process context. When this DDD
calls HHH(DDD) the original HHH emulates this HHH in the DDD
process context.

And that separate proccess, if left unaborted, would halt. But HHH >>>>>> gives up and aborts it, so the process is Halting, not non-halting.

And HHH cannot simulate itself to its undeniable halting state.

But the pattern isn't non-halting by the fact that DDD is shown to >>>>>> be halting.

*No not at all. Not in the least little bit*

DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

HHH(DDD) is only accountable for the behavior of its input that cannot possibly halt.

"HHH simulating DDD doesn't halt unless it aborts." Which it does.

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

They are accountable for their outputs.

Halt deciders are only accountable for reporting on the behavior that
their input specifies.

Right, their return value is completely irrelevant.

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

DDD is not simulated forever by HHH.

I showed how after 10 recursive simulations that there really is a non-halting repeating pattern.

The pattern does not repeat further.

When N instructions of DDD are correctly emulated by every HHH that
can possibly exist (technically this is an infinite set of HHH/DDD
pairs) no emulated DDD can possibly halt and every directly executed >>>>> DDD() halts.

See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that calls
"HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD pairs so that it
could be more easily understood that DDD simulated by HHH cannot
possibly halt.

Yes, you are talking about infinitely many counterexamples to
infinitely many "deciders".

And each HHH(DDD) gets the correct answer thus the standard proofs do
not correctly derive their undecidability result.

...for infinitely many different inputs.

--
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:32 AM, olcott wrote:

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

HHH emulates DDD in a separate process context. When this DDD calls >>>>>>> HHH(DDD) the original HHH emulates this HHH in the DDD process
context.

And that separate proccess, if left unaborted, would halt. But HHH >>>>>> gives up and aborts it, so the process is Halting, not non-halting.

And HHH cannot simulate itself to its undeniable halting state.

But the pattern isn't non-halting by the fact that DDD is shown to be >>>>>> halting.

*No not at all. Not in the least little bit*

DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

HHH(DDD) is only accountable for the behavior of its
input that cannot possibly halt.

Except that the "behavior of its input" is the behavior of the program
it represents, which halts.

So, you are just showing you don't know what you are talking about.

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

They are accountable for their outputs.

Halt deciders are only accountable for reporting on the
behavior that their input specifies.

Which *IS* the behavior of the program that the input correctly
represent when it is run.

Thus, they ARE responsible for that direct execution.

All you are proving is you don't know what you are talking about as you
have lied to yourself and stupidly believed that 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.

DDD is not simulated forever by HHH.

I showed how after 10 recursive simulations that
there really is a non-halting repeating pattern.

Which halts after the 11th cycle throgh the program, so isn't non-halting.

Your problem is you don't understand what "non-halting" means, it isn't
about a partial simulation, but the full behavior of the program represented

And you don't understand the meaning of a program, as you think you can
omit some of the code in it.

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

When N instructions of DDD are correctly emulated by every HHH that
can possibly exist (technically this is an infinite set of HHH/DDD
pairs) no emulated DDD can possibly halt and every directly executed >>>>> DDD() halts.

See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that calls
"HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD pairs so that it could
be more easily understood that DDD simulated by HHH cannot possibly
halt.

Yes, you are talking about infinitely many counterexamples to infinitely
many "deciders".

And each HHH(DDD) gets the correct answer thus the standard
proofs do not correctly derive their undecidability result.

Nope, each HHH(DDD) gets the WRONG answer, as all the DDD that they were
given will halt when run, which is the DEFINITION of the problem.

You are just showing that you lie about what you are talking about and
think that strawman are valid alternatives.

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

Am Fri, 01 Aug 2025 11:08:56 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

And that separate proccess, if left unaborted, would halt. But >>>>>>>> HHH gives up and aborts it, so the process is Halting, not
non-halting.

And HHH cannot simulate itself to its undeniable halting state.

But the pattern isn't non-halting by the fact that DDD is shown >>>>>>>> to be halting.

*No not at all. Not in the least little bit*

DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

HHH(DDD) is only accountable for the behavior of its input that cannot
possibly halt.

"HHH simulating DDD doesn't halt unless it aborts." Which it does.

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

DDD is not simulated forever by HHH.

I showed how after 10 recursive simulations that there really is a
non-halting repeating pattern.

The pattern does not repeat further.

Likewise with this function.
Infinite_Loop correctly simulated by HHH stops running very quickly.

Unlike DDD, Infinite_Loop *would* repeat the pattern.

When N instructions of DDD are correctly emulated by every HHH
that can possibly exist (technically this is an infinite set of
HHH/DDD pairs) no emulated DDD can possibly halt and every
directly executed DDD() halts.

See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that
calls "HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD pairs so that it
could be more easily understood that DDD simulated by HHH cannot
possibly halt.

Yes, you are talking about infinitely many counterexamples to
infinitely many "deciders".

And each HHH(DDD) gets the correct answer thus the standard proofs do
not correctly derive their undecidability result.

...for infinitely many different inputs.

It only takes one recursive emulation (two emulations)
for HHH(DDD) to detect a non-halting behavior pattern.
I showed ten recursive simulations because people could not see the
repeating pattern with only one recursive simulation.

The pattern does not repeat more than 10 times.

--
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 12:28 PM, olcott wrote:

On 8/1/2025 11:04 AM, Richard Damon wrote:

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

HHH(DDD) is only accountable for the behavior of its
input that cannot possibly halt.

Except that the "behavior of its input" is the behavior of the program
it represents

That has never been true.
When textbooks such as Linz say this they are wrong.

Nope, the problem is you think you can LIE and change the definitions.

That just shows you are a pathological liar that doesn't understand what
Truth is.

A halt decider maps the input to the behavior that
it actually specifies. Halt deciders must always totally
ignore the behavior of directly executing Turing machines
because these are outside of its problem domain.

And the behavior the input specifies IS DEFINED to be the behavior of
the program that it represents.

IT seems you think requirements and specifications don't matter, but
then to you truth doesn't matter so that makes sense.

READ THE ACTUAL PROBLEM and point out where you get that from?

"To decide if the program its input describes will halt"

How is the behavior of that program outside the domain of the problem?

It seems facts are outside the domain of your ability to think.

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

On 8/1/25 12:08 PM, olcott wrote:

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

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

HHH emulates DDD in a separate process context. When this DDD >>>>>>>>> calls HHH(DDD) the original HHH emulates this HHH in the DDD >>>>>>>>> process context.

And that separate proccess, if left unaborted, would halt. But HHH >>>>>>>> gives up and aborts it, so the process is Halting, not non-halting. >>>>>> And HHH cannot simulate itself to its undeniable halting state.

But the pattern isn't non-halting by the fact that DDD is shown to >>>>>>>> be halting.

*No not at all. Not in the least little bit*

DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

HHH(DDD) is only accountable for the behavior of its input that cannot
possibly halt.

"HHH simulating DDD doesn't halt unless it aborts." Which it does.

<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 requires H and D to be full programs, fully defined and represented.

And it requires H to CORRECTLY determine that the CORRECT simuolation of
its input, D, would not reach a final state.

It does NOT mean you get to CHANGE the input to use a different HHH that
isn't the HHH that you claim to give the right answer, as the code for
that HHH was part of the input to HHH, or it can't simulate it at all.

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

They are accountable for their outputs.

Halt deciders are only accountable for reporting on the behavior that
their input specifies.

Right, their return value is completely irrelevant.

Their return value must correspond to the behavior
that their input specifies.

Which is the behavior of the program the input represents, by the
DEFINITION of the problem.

If you try to claim it corresponds to something else, you just admitted
that either you rules of representation are invalid, or you gave the
decider an incorrect representation.

The "proof program" is DEFINED to give the decider a representation of
itself, so the "behavior of the input" that it gives *IS* the behavior
of itself.

Otherwise, you are just admitting to being a stupid liar.

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

DDD is not simulated forever by HHH.

I showed how after 10 recursive simulations that there really is a
non-halting repeating pattern.

The pattern does not repeat further.

Likewise with this function.
Infinite_Loop correctly simulated by HHH stops
running very quickly.

Nope, the correct simulation of that input can never stop.

HHH may be able to determine that fact quickly, but that is just
confusion computing the answer with simulating the input.

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

When N instructions of DDD are correctly emulated by every HHH that >>>>>>> can possibly exist (technically this is an infinite set of HHH/DDD >>>>>>> pairs) no emulated DDD can possibly halt and every directly executed >>>>>>> DDD() halts.

See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that calls >>>>>> "HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD pairs so that it
could be more easily understood that DDD simulated by HHH cannot
possibly halt.

Yes, you are talking about infinitely many counterexamples to
infinitely many "deciders".

And each HHH(DDD) gets the correct answer thus the standard proofs do
not correctly derive their undecidability result.

...for infinitely many different inputs.

All of the conventional HP proofs fail to prove the undecidability
of the halting problem when the halt decider is based on a UTM
that simulates its input.

Sure they do. You are just proving you don't know what the words mean.

Things liek Program, Input, Correct, Halting or Non-Halting.

It only takes one recursive emulation (two emulations)
for HHH(DDD) to detect a non-halting behavior pattern.

Can't, since the input isn't non-halting.

Just proving you think wrong answer can be right.

I showed ten recursive simulations because people could
not see the repeating pattern with only one recursive
simulation.

And you show that you don't know what you are talking about, but just
lie about almost everything you talk about.

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

On 8/1/25 1:16 PM, olcott wrote:

On 8/1/2025 11:30 AM, joes wrote:

Am Fri, 01 Aug 2025 11:08:56 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

And that separate proccess, if left unaborted, would halt. But >>>>>>>>>> HHH gives up and aborts it, so the process is Halting, not >>>>>>>>>> non-halting.

And HHH cannot simulate itself to its undeniable halting state.

But the pattern isn't non-halting by the fact that DDD is shown >>>>>>>>>> to be halting.

*No not at all. Not in the least little bit*

DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

HHH(DDD) is only accountable for the behavior of its input that cannot >>>>> possibly halt.

"HHH simulating DDD doesn't halt unless it aborts." Which it does.

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

DDD is not simulated forever by HHH.

I showed how after 10 recursive simulations that there really is a
non-halting repeating pattern.

The pattern does not repeat further.

Likewise with this function.
Infinite_Loop correctly simulated by HHH stops running very quickly.

Unlike DDD, Infinite_Loop *would* repeat the pattern.

When N instructions of DDD are correctly emulated by every HHH >>>>>>>>> that can possibly exist (technically this is an infinite set of >>>>>>>>> HHH/DDD pairs) no emulated DDD can possibly halt and every
directly executed DDD() halts.

See, and I thought DDD was a concrete program filled in with HHH, >>>>>>>> which aborts after two levels of simulation, not something that >>>>>>>> calls "HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD pairs so that it >>>>>>> could be more easily understood that DDD simulated by HHH cannot >>>>>>> possibly halt.

Yes, you are talking about infinitely many counterexamples to
infinitely many "deciders".

And each HHH(DDD) gets the correct answer thus the standard proofs do >>>>> not correctly derive their undecidability result.

...for infinitely many different inputs.

It only takes one recursive emulation (two emulations)
for HHH(DDD) to detect a non-halting behavior pattern.
I showed ten recursive simulations because people could not see the
repeating pattern with only one recursive simulation.

The pattern does not repeat more than 10 times.

Of the infinite set of HHH that stops simulating and
aborts after N recursive simulations one of them is
the above HHH.

And *ALL* of those HHH are simulating a DDD that will HALT if simulated
longer to completion.

What no one has acknowledged in three years is that when
N instructions of DDD are correctly emulated by some
HHH that none of these DDD instances ever reaches its
own "return" statement final halt state.

But it doesn't matter that a partial simulation doesn't reach the final
state, that isn't what non-halting is.

For *ALL* of those inputs, a complete simulation of them WILL reach the
final state, as they include the exact code of the HHH that simulated
them for N steps, and then returns 0.

Because this seems dead obvious to anyone knowing
a little bit of C programming and it is too implausible
that people interested in the theory of computation
would not know this little bit of C programming
I assess they they are probably dishonest.

No, you are just showing yourself too stupid to understand that the requriements are about the direct execution, and trying to replace that
with a partial simulation is just a LIE.

Sorry, you seem to be growning dumber as the days go by.

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

Am Fri, 01 Aug 2025 12:16:01 -0500 schrieb olcott:

On 8/1/2025 11:30 AM, joes wrote:

Am Fri, 01 Aug 2025 11:08:56 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

And HHH cannot simulate itself to its undeniable halting state.

DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

HHH(DDD) is only accountable for the behavior of its input that
cannot possibly halt.

"HHH simulating DDD doesn't halt unless it aborts." Which it does.

DDD is not simulated forever by HHH.

I showed how after 10 recursive simulations that there really is a
non-halting repeating pattern.

The pattern does not repeat further.

Infinite_Loop correctly simulated by HHH stops running very quickly.

Unlike DDD, Infinite_Loop *would* repeat the pattern.

When N instructions of DDD are correctly emulated by every HHH >>>>>>>>> that can possibly exist (technically this is an infinite set of >>>>>>>>> HHH/DDD pairs) no emulated DDD can possibly halt and every
directly executed DDD() halts.

See, and I thought DDD was a concrete program filled in with HHH, >>>>>>>> which aborts after two levels of simulation, not something that >>>>>>>> calls "HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD pairs so that it >>>>>>> could be more easily understood that DDD simulated by HHH cannot >>>>>>> possibly halt.

Yes, you are talking about infinitely many counterexamples to
infinitely many "deciders".

And each HHH(DDD) gets the correct answer thus the standard proofs
do not correctly derive their undecidability result.

...for infinitely many different inputs.

It only takes one recursive emulation (two emulations)
for HHH(DDD) to detect a non-halting behavior pattern.
I showed ten recursive simulations because people could not see the
repeating pattern with only one recursive simulation.

The pattern does not repeat more than 10 times.

Of the infinite set of HHH that stops simulating and aborts after N
recursive simulations one of them is the above HHH.
What no one has acknowledged in three years is that when N instructions
of DDD are correctly emulated by some HHH that none of these DDD
instances ever reaches its own "return" statement final halt state.

Because they are all simulating different programs.

--
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 02.aug.2025 om 08:02 schreef olcott:

On 8/2/2025 12:55 AM, joes wrote:

Am Fri, 01 Aug 2025 12:16:01 -0500 schrieb olcott:

On 8/1/2025 11:30 AM, joes wrote:

Am Fri, 01 Aug 2025 11:08:56 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>
DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

HHH(DDD) is only accountable for the behavior of its input that
cannot possibly halt.

"HHH simulating DDD doesn't halt unless it aborts." Which it does.

DDD is not simulated forever by HHH.

I showed how after 10 recursive simulations that there really is a >>>>>>> non-halting repeating pattern.

The pattern does not repeat further.

Infinite_Loop correctly simulated by HHH stops running very quickly.

Unlike DDD, Infinite_Loop *would* repeat the pattern.

When N instructions of DDD are correctly emulated by every HHH >>>>>>>>>>> that can possibly exist (technically this is an infinite set of >>>>>>>>>>> HHH/DDD pairs) no emulated DDD can possibly halt and every >>>>>>>>>>> directly executed DDD() halts.

See, and I thought DDD was a concrete program filled in with HHH, >>>>>>>>>> which aborts after two levels of simulation, not something that >>>>>>>>>> calls "HHH" symbolically, producing many different programs. >>>>>>>>> I had to turn it into an infinite set of HHH/DDD pairs so that it >>>>>>>>> could be more easily understood that DDD simulated by HHH cannot >>>>>>>>> possibly halt.

Yes, you are talking about infinitely many counterexamples to
infinitely many "deciders".

And each HHH(DDD) gets the correct answer thus the standard proofs >>>>>>> do not correctly derive their undecidability result.

...for infinitely many different inputs.

It only takes one recursive emulation (two emulations)
for HHH(DDD) to detect a non-halting behavior pattern.
I showed ten recursive simulations because people could not see the
repeating pattern with only one recursive simulation.

The pattern does not repeat more than 10 times.

Of the infinite set of HHH that stops simulating and aborts after N
recursive simulations one of them is the above HHH.
What no one has acknowledged in three years is that when N instructions
of DDD are correctly emulated by some HHH that none of these DDD
instances ever reaches its own "return" statement final halt state.

Because they are all simulating different programs.

That is not relevant. The only relevant thing is that
DDD correctly simulated by HHH never reaches its final state.

This failure is seen by all these programs, showing that a simulation
with a premature abort is not the right way to analyse the behaviour of
a program.

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

On 8/2/25 2:02 AM, olcott wrote:

On 8/2/2025 12:55 AM, joes wrote:

Am Fri, 01 Aug 2025 12:16:01 -0500 schrieb olcott:

On 8/1/2025 11:30 AM, joes wrote:

Am Fri, 01 Aug 2025 11:08:56 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>
DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

HHH(DDD) is only accountable for the behavior of its input that
cannot possibly halt.

"HHH simulating DDD doesn't halt unless it aborts." Which it does.

DDD is not simulated forever by HHH.

I showed how after 10 recursive simulations that there really is a >>>>>>> non-halting repeating pattern.

The pattern does not repeat further.

Infinite_Loop correctly simulated by HHH stops running very quickly.

Unlike DDD, Infinite_Loop *would* repeat the pattern.

When N instructions of DDD are correctly emulated by every HHH >>>>>>>>>>> that can possibly exist (technically this is an infinite set of >>>>>>>>>>> HHH/DDD pairs) no emulated DDD can possibly halt and every >>>>>>>>>>> directly executed DDD() halts.

See, and I thought DDD was a concrete program filled in with HHH, >>>>>>>>>> which aborts after two levels of simulation, not something that >>>>>>>>>> calls "HHH" symbolically, producing many different programs. >>>>>>>>> I had to turn it into an infinite set of HHH/DDD pairs so that it >>>>>>>>> could be more easily understood that DDD simulated by HHH cannot >>>>>>>>> possibly halt.

Yes, you are talking about infinitely many counterexamples to
infinitely many "deciders".

And each HHH(DDD) gets the correct answer thus the standard proofs >>>>>>> do not correctly derive their undecidability result.

...for infinitely many different inputs.

It only takes one recursive emulation (two emulations)
for HHH(DDD) to detect a non-halting behavior pattern.
I showed ten recursive simulations because people could not see the
repeating pattern with only one recursive simulation.

The pattern does not repeat more than 10 times.

Of the infinite set of HHH that stops simulating and aborts after N
recursive simulations one of them is the above HHH.
What no one has acknowledged in three years is that when N instructions
of DDD are correctly emulated by some HHH that none of these DDD
instances ever reaches its own "return" statement final halt state.

Because they are all simulating different programs.

That is not relevant. The only relevant thing is that
DDD correctly simulated by HHH never reaches its final state.

But the HHH that correctly simulates ITS DDD never returns an answer.

You forget that every HHH gets a different DDD, as the program DDD
includes the code of that HHH in you setup.

That they are different is TOTALLY relevent, and denying it is a sign of insanity,

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

On 8/2/25 11:32 AM, olcott wrote:

On 8/2/2025 8:21 AM, Richard Damon wrote:

On 8/2/25 2:02 AM, olcott wrote:

On 8/2/2025 12:55 AM, joes wrote:

Am Fri, 01 Aug 2025 12:16:01 -0500 schrieb olcott:

On 8/1/2025 11:30 AM, joes wrote:

Am Fri, 01 Aug 2025 11:08:56 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 10:32:05 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 09:46:22 -0500 schrieb olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

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

And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>>
DDD halts if it weren't aborted.

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

Good thing that it does abort then! Making them halt.

HHH(DDD) is only accountable for the behavior of its input that >>>>>>>>> cannot possibly halt.

"HHH simulating DDD doesn't halt unless it aborts." Which it does. >>>>>>

DDD is not simulated forever by HHH.

I showed how after 10 recursive simulations that there really is a >>>>>>>>> non-halting repeating pattern.

The pattern does not repeat further.

Infinite_Loop correctly simulated by HHH stops running very quickly. >>>>>> Unlike DDD, Infinite_Loop *would* repeat the pattern.

When N instructions of DDD are correctly emulated by every HHH >>>>>>>>>>>>> that can possibly exist (technically this is an infinite >>>>>>>>>>>>> set of
HHH/DDD pairs) no emulated DDD can possibly halt and every >>>>>>>>>>>>> directly executed DDD() halts.

See, and I thought DDD was a concrete program filled in with >>>>>>>>>>>> HHH,
which aborts after two levels of simulation, not something that >>>>>>>>>>>> calls "HHH" symbolically, producing many different programs. >>>>>>>>>>> I had to turn it into an infinite set of HHH/DDD pairs so >>>>>>>>>>> that it

could be more easily understood that DDD simulated by HHH cannot >>>>>>>>>>> possibly halt.

Yes, you are talking about infinitely many counterexamples to >>>>>>>>>> infinitely many "deciders".

And each HHH(DDD) gets the correct answer thus the standard proofs >>>>>>>>> do not correctly derive their undecidability result.

...for infinitely many different inputs.

It only takes one recursive emulation (two emulations)
for HHH(DDD) to detect a non-halting behavior pattern.
I showed ten recursive simulations because people could not see the >>>>>>> repeating pattern with only one recursive simulation.

The pattern does not repeat more than 10 times.

Of the infinite set of HHH that stops simulating and aborts after N
recursive simulations one of them is the above HHH.
What no one has acknowledged in three years is that when N
instructions
of DDD are correctly emulated by some HHH that none of these DDD
instances ever reaches its own "return" statement final halt state.

Because they are all simulating different programs.

That is not relevant. The only relevant thing is that
DDD correctly simulated by HHH never reaches its final state.

But the HHH that correctly simulates ITS DDD never returns an answer.

When HHH correctly emulates 7 instructions of DDD
it has its proof of non-termination. HHH can see
the 8th instruction yet does not emulated it.

Since your traces don't show 7 instuctions of DDD simulated correcty,
you have lost you proof.

The *ONLY* correct simulation of the call HHH instruciton would be
followed by the instuction at 000015EE.

All you are doing is showing that your idea of "correct" is to lie.

If you want to say that DDD doesn't include that code, then you are just admitting to the category error of DDD not being a program, and that
blows up your whole argument.

Sorry, you are just caught in your lies.

Begin Local Halt Decider Simulation   Execution Trace Stored at:11391e [0000219e][0011390e][00113912] 55         push ebp [0000219f][0011390e][00113912] 8bec       mov ebp,esp [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55         push ebp [0000219f][0015e336][0015e33a] 8bec       mov ebp,esp [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

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

On 8/6/25 7:43 AM, olcott wrote:

On 8/6/2025 4:14 AM, Fred. Zwarts wrote:

Op 05.aug.2025 om 17:21 schreef olcott:

On 8/5/2025 3:12 AM, joes wrote:

Am Mon, 04 Aug 2025 21:05:47 -0500 schrieb olcott:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:

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

[snip le big]

Each pair has a different input for the simulator. Each >>>>>>>>>>>> simulator
fails for the input constructed with its own version. But >>>>>>>>>>>> many of
them prove that the input constructed with other HHH versions, >>>>>>>>>>>> which have less steps before the premature abort, have a final >>>>>>>>>>>> halt state that can be reached.

HHH correctly emulates DDD until this emulated DDD proves that it >>>>>>>>> cannot possibly reach its own emulated final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions of DDD you >>>>>>> are claiming that HHH did not correctly emulate N instructions of >>>>>>> DDD

It didn't simulate N+1 instructions.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

If this is your paraphrase, you won't understand.

I said that H didn't CORRCTLY EMULATE H, which means to have finished >>>>>> the job.

When HHH correctly emulates N instructions of DDD then HHH has
correctly
finished its job of correctly emulating N instructions of DDD.

Yes, that is something different.

Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern: abort simulation and
return 0.

Counter-factual. It sees only a finite recursion and world-class
simulators that do not abort show that for this input the final halt
state is reachable.

You are dishonestly changing the words that I said.
DDD correctly emulated by HHH cannot possibly reach
its own emulated final halt state.

A finite sample of the behavior of DDD correctly
emulated by HHH proves that an infinite simulation
DDD would never stop running.

Nope, that is just a lie.

Since a bigger finite sample of its actual behavior (after HHH stops its simulation) shows that it halts.

All you are doing is proving you think it ok to lie.

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

Op 06.aug.2025 om 13:43 schreef olcott:

On 8/6/2025 4:14 AM, Fred. Zwarts wrote:

Op 05.aug.2025 om 17:21 schreef olcott:

On 8/5/2025 3:12 AM, joes wrote:

Am Mon, 04 Aug 2025 21:05:47 -0500 schrieb olcott:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

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

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:

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

[snip le big]

Each pair has a different input for the simulator. Each >>>>>>>>>>>> simulator
fails for the input constructed with its own version. But >>>>>>>>>>>> many of
them prove that the input constructed with other HHH versions, >>>>>>>>>>>> which have less steps before the premature abort, have a final >>>>>>>>>>>> halt state that can be reached.

HHH correctly emulates DDD until this emulated DDD proves that it >>>>>>>>> cannot possibly reach its own emulated final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions of DDD you >>>>>>> are claiming that HHH did not correctly emulate N instructions of >>>>>>> DDD

It didn't simulate N+1 instructions.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

If this is your paraphrase, you won't understand.

I said that H didn't CORRCTLY EMULATE H, which means to have finished >>>>>> the job.

When HHH correctly emulates N instructions of DDD then HHH has
correctly
finished its job of correctly emulating N instructions of DDD.

Yes, that is something different.

Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern: abort simulation and
return 0.

Counter-factual. It sees only a finite recursion and world-class
simulators that do not abort show that for this input the final halt
state is reachable.

As usual irrelevant/incorerrect claims without evidence.

You are dishonestly changing the words that I said.
DDD correctly emulated by HHH cannot possibly reach
its own emulated final halt state.

I did not dishonestly change the words, I only told you where your words
are wrong, either because you change the meaning of the words, or
because you tell only half the truth, which could make it a lie.

A finite sample of the behavior of DDD correctly
emulated by HHH proves that an infinite simulation
DDD would never stop running.

Counter-factual. The finite recursion does not prove anything. It only
makes HHH blind for what follows this finite recursion. But is your
attitude, programmed in HHH, that when you do not see something you can
pretend that it does not exist.
Wold-class simulators, that do not stop at this finite recursion, prove
that the final halt state is reachable for the program specified in this
exact same input.
HHH simply fails to reach it, because it was made blind for the
condition branch instruction simulated during this finite recursion.

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

On 8/7/25 9:31 AM, olcott wrote:

On 8/7/2025 4:08 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 13:43 schreef olcott:

On 8/6/2025 4:14 AM, Fred. Zwarts wrote:

Op 05.aug.2025 om 17:21 schreef olcott:>>>>

Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.

Counter-factual. It sees only a finite recursion and world-class
simulators that do not abort show that for this input the final halt
state is reachable.

As usual irrelevant/incorerrect claims without evidence.

You are dishonestly changing the words that I said.
DDD correctly emulated by HHH cannot possibly reach
its own emulated final halt state.

I did not dishonestly change the words, I only told you where your
words are wrong, either because you change the meaning of the words,
or because you tell only half the truth, which could make it a lie.

A finite sample of the behavior of DDD correctly
emulated by HHH proves that an infinite simulation
DDD would never stop running.

Counter-factual. The finite recursion does not prove anything. It only
makes HHH blind for what follows this finite recursion. But is your
attitude, programmed in HHH, that when you do not see something you
can pretend that it does not exist.
Wold-class simulators, that do not stop at this finite recursion,
prove that the final halt state is reachable for the program specified
in this exact same input.
HHH simply fails to reach it, because it was made blind for the
condition branch instruction simulated during this finite recursion.

When 0 to infinity steps of DDD are correctly emulated
by HHH the emulated DDD does not reach its own emulated
final state.

Not "of DDD" as each HHH is simulating a DIFFERENT input DDD, or N can't
be greater than 4.

And for ALL of the ones that simulated a finite number of steps N, there
is a bigger number M which a simulation for that number of steps WILL
reach a final state.

That a partial simulation doesn't reach a final state is NOT
non-halting, and being different input, no

Some people may think that when HHH aborts its emulation
of DDD that the stack will unwind and the emulated DDD
will each its own emulated final state. This is incorrect.

Your problem is that when HHH aborts its emulation, the behavior of that
input doesn't stop but continues if HHH is a halt decider.

All you are doing is admitting that your HHH isn't even defined to be a
halt decider, and thus your whole argument is a category error and a lie.

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

On 2025-08-07 13:44:54 +0000, olcott said:

On 8/7/2025 4:14 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:24 schreef olcott:

On 8/6/2025 9:27 PM, Richard Damon wrote:

On 8/6/25 7:53 AM, olcott wrote:

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are programs. >>>>>>

    "The contradiction in Linz's (or Turing's) self-referential >>>>>>>      halting construction only appears if one insists that the >>>>>>>      machine can and must decide on its own behavior, which is >>>>>>>      neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior. >>>>> This is easily corrected:

But the existance of UTMs means that it IS possible to make a perfect
proxy, as the UTM can completely recreate the behavior of ANY machine
from its Turing Machine Description.

All you are doing is admitting that you think errors and lies are ok.

    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.

Indeed, that is the proof that such a simulation fails.
No simulator exists that is able to simulate correctly all halting
programs up to the end,because it fails to simulate correctly code that
resembles its own code.

*You are confusing two distinctly different notions*

Which two ?

--
Mikko

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

Op 07.aug.2025 om 15:31 schreef olcott:

On 8/7/2025 4:08 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 13:43 schreef olcott:

On 8/6/2025 4:14 AM, Fred. Zwarts wrote:

Op 05.aug.2025 om 17:21 schreef olcott:>>>>

Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.

Counter-factual. It sees only a finite recursion and world-class
simulators that do not abort show that for this input the final halt
state is reachable.

As usual irrelevant/incorerrect claims without evidence.

You are dishonestly changing the words that I said.
DDD correctly emulated by HHH cannot possibly reach
its own emulated final halt state.

I did not dishonestly change the words, I only told you where your
words are wrong, either because you change the meaning of the words,
or because you tell only half the truth, which could make it a lie.

A finite sample of the behavior of DDD correctly
emulated by HHH proves that an infinite simulation
DDD would never stop running.

Counter-factual. The finite recursion does not prove anything. It only
makes HHH blind for what follows this finite recursion. But is your
attitude, programmed in HHH, that when you do not see something you
can pretend that it does not exist.
Wold-class simulators, that do not stop at this finite recursion,
prove that the final halt state is reachable for the program specified
in this exact same input.
HHH simply fails to reach it, because it was made blind for the
condition branch instruction simulated during this finite recursion.

When 0 to infinity steps of DDD are correctly emulated
by HHH the emulated DDD does not reach its own emulated
final state.

As usual irrelevant claims.
Other simulators show that a finite number of steps is needed to reach
the final halt state. But your are cheating by changing the input when increasing the number of steps that HHH simulates.

Some people may think that when HHH aborts its emulation
of DDD that the stack will unwind and the emulated DDD
will each its own emulated final state. This is incorrect.

As usual another irrelevant claim.
Other simulators show that no stack unwinding is needed to reach the
final halt state. The final halt state as specified in the input, is
reachable, but HHH fails to reach it.
Such failure is not evidence that the halt state does not exists. But
that is your attitude, also programmed in HHH: Close your eyes and
pretend that thing you do not see do not exist.

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