From Newsgroup: comp.theory

On 8/26/25 10:56 AM, olcott wrote:

On 8/26/2025 1:39 AM, Kaz Kylheku wrote:

On 2025-08-26, olcott <polcott333@gmail.com> wrote:

On 8/26/2025 12:34 AM, Kaz Kylheku wrote:

On 2025-08-25, olcott <polcott333@gmail.com> wrote:

On 8/25/2025 6:03 PM, Kaz Kylheku wrote:

I agree that if we take any decider H from the special subset of
deciders which blindly simulate their input, and then if we build the
counterexample test case against such an H, that test case will have
runway recursion (via nested simulation levels). In none of the DD
invocation does the H(DDD) expression terminate; so the "opposite
behavior" doesn't even kick in.

Thus, halt-deciding by simulation is a non-starter.

Great, so what?

That by itself seems to be more progress than anyone else has ever made. >>> The counter-example input actually does have a correct non-contradicted
halt status.

But we know that absolutely Every Turing Machine has a halt status:
either it halts or does not.

As soon as HHH(DD) can return 0 as a pure function
of its input the HP proofs have been defeated.

Nope, because if it does, DD will halt, so that answer is wrong.

Maybe you have shown that POOP deciders might exist, but not halt deciders.

The decider has not halted and so has not calculated that status.

You are assigning an importance to this degenerate case which it doesn't
have.

A decider that doesn't halt on non-terminating inputs is of worse
quality sophisticated one which is defeated by the actual contradictory
behavior in the test case.

Next is to transform HHH so that it can recognize the repeating state as >>> a pure function of its input. If I can do this that will complete my
work. Then I will have refuted the HP proofs.

The problem is that you cannot be transforming HHH without
simultaneously be transforming the DD which is based on HHH.

*Ultimately is is just the adapted Linz proof*
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

By changing the criteria, and thus solving a different problem, making
you claims about Halting just lies.

Turing Machine Linz -n applied to its own machine description rf?-nrf-
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
-a-a reach its simulated final halt state of rf?-n.qnrf-.

Repeats until aborted
(a) -n copies its input rf?-nrf-
(b) -n invokes embedded_H rf?-nrf- rf?-nrf-
(c) embedded_H simulates rf?-nrf- rf?-nrf-

If you split things so that DD retains its original HHH decider, while
you transform a copy of it to another one, then you have two deciders.

The two-decider arrangement doesn't refute anything.

A decider that must have a dry run to be initialized
before its performs its analysis is not two deciders.

Nope. There is no "dry run" or it can't have been pure.

You've already tried that with the static data. Any other means of
doing it is just as invalid.

FIVE LLM systems were able to do a pseudo execution
trace of DD correctly simulated by HHH and derive
my same conclusion.

You can easily have two different deciders HHH1 and HHH2 with no static
data trickery.-a Have DDD call HHH2(DD), and use HHH1(DD) to decide the
halting of DD. That totally works; HHH1(DD) can produce the correct
value.-a It doesn't disprove anything.

So I won't do it that way.
Five LLM systems could do this on the basis of a text file
thus as a pure function of their input.

The easiest way is to rename HHH to HHH1. Then make an exact copy HHH2
and fix DD to call HHH2(DD). Next, edit HHH1 to eliminate all the static
data stuff, and have it unconditionally behave as the abort-checking
simulator. Similarly, edit HHH2 to get rid of the static data stuff, and
have it unconditionally be a pure simulator.

Since you said that won't prove anything that it no good.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/26/25 11:34 AM, olcott wrote:

On 8/26/2025 2:32 AM, Richard Heathfield wrote:

On 26/08/2025 06:48, olcott wrote:

On 8/26/2025 12:36 AM, Kaz Kylheku wrote:

On 2025-08-25, olcott <polcott333@gmail.com> wrote:

<snip>

DD correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state is proven by the fact that
when the abort code is disabled that DD() never
stops running.

Again, this is obvious and uninteresting: so what?

The counter-example input finally has a halt status that is not
contradicted.

Make sure you carefully overlook all the people who contradict you.
(And reality, which is the hardest contradictor of all.)

Everyone that directly contradicts me only does
this on the basis of directly contradicting
verified facts.

As soon as HHH(DD) correctly rejects DD as a
pure function of its input the HP proofs are
proven to not derive their conclusion.

No, your argument is directly contradicted by the verified facts that
the wording of the Halting problem talks about the behavior of the
directly executed program, which halts when you decider claims it doesn't.

Everything else is just your lies and stupidity.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 26.aug.2025 om 18:53 schreef olcott:

On 8/26/2025 11:37 AM, Kaz Kylheku wrote:

On 2025-08-26, olcott <polcott333@gmail.com> wrote:

On 8/26/2025 1:39 AM, Kaz Kylheku wrote:

On 2025-08-26, olcott <polcott333@gmail.com> wrote:

On 8/26/2025 12:34 AM, Kaz Kylheku wrote:

On 2025-08-25, olcott <polcott333@gmail.com> wrote:

On 8/25/2025 6:03 PM, Kaz Kylheku wrote:

I agree that if we take any decider H from the special subset of
deciders which blindly simulate their input, and then if we build the >>>>>> counterexample test case against such an H, that test case will have >>>>>> runway recursion (via nested simulation levels). In none of the DD >>>>>> invocation does the H(DDD) expression terminate; so the "opposite
behavior" doesn't even kick in.

Thus, halt-deciding by simulation is a non-starter.

Great, so what?

That by itself seems to be more progress than anyone else has ever
made.
The counter-example input actually does have a correct non-
contradicted
halt status.

But we know that absolutely Every Turing Machine has a halt status:
either it halts or does not.

As soon as HHH(DD) can return 0 as a pure function
of its input the HP proofs have been defeated.

The problem is that here is what it means for HHH to be a pure function:
all uses of HHH are identical, denoting the same computation. If HHH(DD)
returns 0, and is a pure function call (as required) it means that every
instance of that expression HHH(DD) everywhere returns 0.-a One such
instance is inside the test case DD.

Those instances of HHH that are themselves stuck
in recursive emulation cannot possibly return.

If you split things so that DD retains its original HHH decider, while >>>> you transform a copy of it to another one, then you have two deciders. >>>>
The two-decider arrangement doesn't refute anything.

A decider that must have a dry run to be initialized
before its performs its analysis is not two deciders.

If we have a procedure that behaves in various inconsistent ways when it
is invoked the first N time, modifying its state, but after N calls
settles into a consistent behavior in which all subsequent calls denote
the same computation, we can allow ourselves to model those subsequent
calls as a pure function call.

This is an easy fix.

If our experiment relies on any of the first N calls though, then we
have impurity in the experiment which amounts to multiple functions
where we crucially need there to be one function.

I have proven that DD correctly simulated by HHH
cannot possibly reach its own simulated "return"
statement final halt state by the fact that disabling
the abort causes DD() to never stop.

In other words: you have proven that the HHH that aborts as well as the
HHH that does not abort both fail to reach the final halt state.
The only difference is that the input based on the HHH that aborts has a
final halt state and the input based on the HHH that does not abort does
not terminate.
In both cases, however, HHH fails. The HHH hat aborts fails because it
does not reach the final halt state specified in the input and returns
an incorrect result. The HHH that does not abort fails because it does
not report.
The premature abort of HHH, which makes that it cannot reach the final
halt state, does not change the specification of only a finite recursion.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/27/2025 2:57 AM, Fred. Zwarts wrote:

Op 26.aug.2025 om 18:53 schreef olcott:

On 8/26/2025 11:37 AM, Kaz Kylheku wrote:

On 2025-08-26, olcott <polcott333@gmail.com> wrote:

On 8/26/2025 1:39 AM, Kaz Kylheku wrote:

On 2025-08-26, olcott <polcott333@gmail.com> wrote:

On 8/26/2025 12:34 AM, Kaz Kylheku wrote:

On 2025-08-25, olcott <polcott333@gmail.com> wrote:

On 8/25/2025 6:03 PM, Kaz Kylheku wrote:

I agree that if we take any decider H from the special subset of >>>>>>> deciders which blindly simulate their input, and then if we build >>>>>>> the
counterexample test case against such an H, that test case will have >>>>>>> runway recursion (via nested simulation levels). In none of the DD >>>>>>> invocation does the H(DDD) expression terminate; so the "opposite >>>>>>> behavior" doesn't even kick in.

Thus, halt-deciding by simulation is a non-starter.

Great, so what?

That by itself seems to be more progress than anyone else has ever >>>>>> made.
The counter-example input actually does have a correct non-
contradicted
halt status.

But we know that absolutely Every Turing Machine has a halt status:
either it halts or does not.

As soon as HHH(DD) can return 0 as a pure function
of its input the HP proofs have been defeated.

The problem is that here is what it means for HHH to be a pure function: >>> all uses of HHH are identical, denoting the same computation. If HHH(DD) >>> returns 0, and is a pure function call (as required) it means that every >>> instance of that expression HHH(DD) everywhere returns 0.-a One such
instance is inside the test case DD.

Those instances of HHH that are themselves stuck
in recursive emulation cannot possibly return.

If you split things so that DD retains its original HHH decider, while >>>>> you transform a copy of it to another one, then you have two deciders. >>>>>
The two-decider arrangement doesn't refute anything.

A decider that must have a dry run to be initialized
before its performs its analysis is not two deciders.

If we have a procedure that behaves in various inconsistent ways when it >>> is invoked the first N time, modifying its state, but after N calls
settles into a consistent behavior in which all subsequent calls denote
the same computation, we can allow ourselves to model those subsequent
calls as a pure function call.

This is an easy fix.

If our experiment relies on any of the first N calls though, then we
have impurity in the experiment which amounts to multiple functions
where we crucially need there to be one function.

I have proven that DD correctly simulated by HHH
cannot possibly reach its own simulated "return"
statement final halt state by the fact that disabling
the abort causes DD() to never stop.

In other words: you have proven that the HHH that aborts as well as the
HHH that does not abort both fail to reach the final halt state.

I have proven that DD correctly simulated by HHH
specifies the non-halting behavior pattern of
recursive simulation.

Until you understand this you will lack the mandatory
prerequisite to understand the rest.

The only difference is that the input based on the HHH that aborts has a final halt state and the input based on the HHH that does not abort does
not terminate.
In both cases, however, HHH fails. The HHH hat aborts fails because it
does not reach the final halt state specified in the input and returns
an incorrect result. The HHH that does not abort fails because it does
not report.
The premature abort of HHH, which makes that it cannot reach the final
halt state, does not change the specification of only a finite recursion.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/27/25 10:35 AM, olcott wrote:

On 8/27/2025 2:57 AM, Fred. Zwarts wrote:

Op 26.aug.2025 om 18:53 schreef olcott:

On 8/26/2025 11:37 AM, Kaz Kylheku wrote:

On 2025-08-26, olcott <polcott333@gmail.com> wrote:

On 8/26/2025 1:39 AM, Kaz Kylheku wrote:

On 2025-08-26, olcott <polcott333@gmail.com> wrote:

On 8/26/2025 12:34 AM, Kaz Kylheku wrote:

On 2025-08-25, olcott <polcott333@gmail.com> wrote:

On 8/25/2025 6:03 PM, Kaz Kylheku wrote:

I agree that if we take any decider H from the special subset of >>>>>>>> deciders which blindly simulate their input, and then if we
build the
counterexample test case against such an H, that test case will >>>>>>>> have
runway recursion (via nested simulation levels). In none of the DD >>>>>>>> invocation does the H(DDD) expression terminate; so the "opposite >>>>>>>> behavior" doesn't even kick in.

Thus, halt-deciding by simulation is a non-starter.

Great, so what?

That by itself seems to be more progress than anyone else has
ever made.
The counter-example input actually does have a correct non-
contradicted
halt status.

But we know that absolutely Every Turing Machine has a halt status: >>>>>> either it halts or does not.

As soon as HHH(DD) can return 0 as a pure function
of its input the HP proofs have been defeated.

The problem is that here is what it means for HHH to be a pure
function:
all uses of HHH are identical, denoting the same computation. If
HHH(DD)
returns 0, and is a pure function call (as required) it means that
every
instance of that expression HHH(DD) everywhere returns 0.-a One such
instance is inside the test case DD.

Those instances of HHH that are themselves stuck
in recursive emulation cannot possibly return.

If you split things so that DD retains its original HHH decider,
while
you transform a copy of it to another one, then you have two
deciders.

The two-decider arrangement doesn't refute anything.

A decider that must have a dry run to be initialized
before its performs its analysis is not two deciders.

If we have a procedure that behaves in various inconsistent ways
when it
is invoked the first N time, modifying its state, but after N calls
settles into a consistent behavior in which all subsequent calls denote >>>> the same computation, we can allow ourselves to model those subsequent >>>> calls as a pure function call.

This is an easy fix.

If our experiment relies on any of the first N calls though, then we
have impurity in the experiment which amounts to multiple functions
where we crucially need there to be one function.

I have proven that DD correctly simulated by HHH
cannot possibly reach its own simulated "return"
statement final halt state by the fact that disabling
the abort causes DD() to never stop.

In other words: you have proven that the HHH that aborts as well as
the HHH that does not abort both fail to reach the final halt state.

I have proven that DD correctly simulated by HHH
specifies the non-halting behavior pattern of
recursive simulation.

But *ONLY* for the DD built on an HHH that does a correct simulation of
its input, and thus doesn't answer.

Since a given HHH has exactly one behavior for a given input, any HHH
that gives the non-halting answer didn't do a correct simulation, and by
the rules of pairing, its DD wasn't built on the HHH that does, so it
isn't correct.

Until you understand this you will lack the mandatory
prerequisite to understand the rest.

Until you understand that you need to be talking about programs per the
field, you won't understand that you are lying by just building an
argument on a category error.

All you are doing is proving that you are a pathological liar that
doesn't know the proper meaning of the words he is using, and doesn't care

The only difference is that the input based on the HHH that aborts has
a final halt state and the input based on the HHH that does not abort
does not terminate.
In both cases, however, HHH fails. The HHH hat aborts fails because it
does not reach the final halt state specified in the input and returns
an incorrect result. The HHH that does not abort fails because it does
not report.
The premature abort of HHH, which makes that it cannot reach the final
halt state, does not change the specification of only a finite recursion.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 27.aug.2025 om 16:35 schreef olcott:

On 8/27/2025 2:57 AM, Fred. Zwarts wrote:

Op 26.aug.2025 om 18:53 schreef olcott:

On 8/26/2025 11:37 AM, Kaz Kylheku wrote:

On 2025-08-26, olcott <polcott333@gmail.com> wrote:

On 8/26/2025 1:39 AM, Kaz Kylheku wrote:

On 2025-08-26, olcott <polcott333@gmail.com> wrote:

On 8/26/2025 12:34 AM, Kaz Kylheku wrote:

On 2025-08-25, olcott <polcott333@gmail.com> wrote:

On 8/25/2025 6:03 PM, Kaz Kylheku wrote:

I agree that if we take any decider H from the special subset of >>>>>>>> deciders which blindly simulate their input, and then if we
build the
counterexample test case against such an H, that test case will >>>>>>>> have
runway recursion (via nested simulation levels). In none of the DD >>>>>>>> invocation does the H(DDD) expression terminate; so the "opposite >>>>>>>> behavior" doesn't even kick in.

Thus, halt-deciding by simulation is a non-starter.

Great, so what?

That by itself seems to be more progress than anyone else has
ever made.
The counter-example input actually does have a correct non-
contradicted
halt status.

But we know that absolutely Every Turing Machine has a halt status: >>>>>> either it halts or does not.

As soon as HHH(DD) can return 0 as a pure function
of its input the HP proofs have been defeated.

The problem is that here is what it means for HHH to be a pure
function:
all uses of HHH are identical, denoting the same computation. If
HHH(DD)
returns 0, and is a pure function call (as required) it means that
every
instance of that expression HHH(DD) everywhere returns 0.-a One such
instance is inside the test case DD.

Those instances of HHH that are themselves stuck
in recursive emulation cannot possibly return.

If you split things so that DD retains its original HHH decider,
while
you transform a copy of it to another one, then you have two
deciders.

The two-decider arrangement doesn't refute anything.

A decider that must have a dry run to be initialized
before its performs its analysis is not two deciders.

If we have a procedure that behaves in various inconsistent ways
when it
is invoked the first N time, modifying its state, but after N calls
settles into a consistent behavior in which all subsequent calls denote >>>> the same computation, we can allow ourselves to model those subsequent >>>> calls as a pure function call.

This is an easy fix.

If our experiment relies on any of the first N calls though, then we
have impurity in the experiment which amounts to multiple functions
where we crucially need there to be one function.

I have proven that DD correctly simulated by HHH
cannot possibly reach its own simulated "return"
statement final halt state by the fact that disabling
the abort causes DD() to never stop.

In other words: you have proven that the HHH that aborts as well as
the HHH that does not abort both fail to reach the final halt state.

I have proven that DD correctly simulated by HHH
specifies the non-halting behavior pattern of
recursive simulation.

As usual incorrect claims without evidence.
You have exposed the failure of HHH. HHH has a bug, which makes that it
thinks that a finite recursion is a non-termination behaviour pattern,
but there is no such pattern in the input.
HHH does not analyse the conditional branch instructions encountered
during the simulation. It just stops the simulation, without a proof
that the alternate branches are not followed in a correct continuation
of the simulation. Other simulators using the exact same input, that do
not abort, prove that these alternate branches are followed when the simulation is correctly continued.
That HHH, due to this bug, does not correctly interpret the input, does
not change the fact that the input specifies a program with halting
behaviour.

Until you understand this you will lack the mandatory
prerequisite to understand the rest.

Taking the claim that you need to prove as a prerequisite is an invalid circular reasoning.
We know that this prerequisite exists only in your dreams and not in
reality, but you are too stubborn to even think about the possibility
that your dreams could be wrong. You close your eyes and pretend that
these facts do not exist.
That seems to be also the reason why you never try to find a counter
argument, but only keep repeating your debunked claims without any new evidence.

The only difference is that the input based on the HHH that aborts has
a final halt state and the input based on the HHH that does not abort
does not terminate.
In both cases, however, HHH fails. The HHH hat aborts fails because it
does not reach the final halt state specified in the input and returns
an incorrect result. The HHH that does not abort fails because it does
not report.
The premature abort of HHH, which makes that it cannot reach the final
halt state, does not change the specification of only a finite recursion.

--- Synchronet 3.21a-Linux NewsLink 1.2