On 7/27/25 1:04 AM, olcott wrote:

On 7/26/2025 11:56 PM, wij wrote:

On Sat, 2025-07-26 at 23:47 -0500, olcott wrote:

On 7/26/2025 11:39 PM, wij wrote:

On Sat, 2025-07-26 at 23:26 -0500, olcott wrote:

On 7/26/2025 11:14 PM, wij wrote:

On Sat, 2025-07-26 at 23:02 -0500, olcott wrote:

It is incorrect to have halt decider
H report on the behavior of machine M.
Directly executing Turing machines are
not in the domain of any halt decider.

Then, basically, it would be POO Problem, technically nothing to
do with HP.

I have now fully refuted all conventional proofs
of undecidability of the halting problem.

This supersedes everything else that I have ever said.

Hopping mode again.
POOP is Peter Olcott's Own Problem. It supersedes none.

Try FORMALLY specify POOP. It will be very difficult, because:

I have already done this and no one here
was bright enough to understand. Too much
learned by rote and not enough think things through.

1. you have shown again you don't understand basic logic (AND,IF,...)
2. You cannot construct a TM that compute the length of its input.
3. Your understanding of C/Assembly is shown very low, I never saw
anyone is lower.

Because it will be very difficult to communicate anything logically.
So, try again
the basic logic you failed and dodged.

YOu are just proving that you are an idiot.

Face it, you failed and proved your stupidity.

Are you looking to establish an insanity defense?

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

On 7/27/25 9:59 AM, olcott wrote:

On 7/27/2025 8:21 AM, wij wrote:

On Sun, 2025-07-27 at 07:57 -0500, olcott wrote:

On 7/27/2025 12:07 AM, wij wrote:

On Sun, 2025-07-27 at 00:04 -0500, olcott wrote:

On 7/26/2025 11:56 PM, wij wrote:

On Sat, 2025-07-26 at 23:47 -0500, olcott wrote:

On 7/26/2025 11:39 PM, wij wrote:

On Sat, 2025-07-26 at 23:26 -0500, olcott wrote:

On 7/26/2025 11:14 PM, wij wrote:

On Sat, 2025-07-26 at 23:02 -0500, olcott wrote:

It is incorrect to have halt decider
H report on the behavior of machine M.
Directly executing Turing machines are
not in the domain of any halt decider.

Then, basically, it would be POO Problem, technically nothing >>>>>>>>>> to do with HP.

I have now fully refuted all conventional proofs
of undecidability of the halting problem.

This supersedes everything else that I have ever said.

Hopping mode again.
POOP is Peter Olcott's Own Problem. It supersedes none.

Try FORMALLY specify POOP. It will be very difficult, because:

I have already done this and no one here
was bright enough to understand. Too much
learned by rote and not enough think things through.

Impossible, because:
1. you have shown again you don't understand basic logic (AND,IF,...)

That is counter-factual.
The truth is that you have shown that you don't
understand advanced logic: G := ⊬G

You don't even know what the symbols mean
when I give you the source of their definitions:
https://en.wikipedia.org/wiki/List_of_logic_symbols

2. You cannot construct a TM that compute the length of its input.
3. Your understanding of C/Assembly is shown very low, I never saw
anyone is lower.

*That is counter-factual*
I wrote the x86utm operating system in C++ that allows
one C function to emulate each x86 instruction of another
C function in debug step mode.

This C function is emulated in its own process context
having its own virtual stack and set of 16 virtual registers.

Because it will be very difficult to communicate anything logically.
So, try again
the basic logic you failed and dodged.

You have not used any reasoning you only provided the
ad hominem error of reasoning. That is very lame.

To save our troubles, let's run the basic logic again to ensure the
communication
is effective.

P1= A AND B
   P1 is true means A,B both are true, otherwise P1 is false.

P2= IF A THEN B
   P2 is true means
    1. A is true and B is true
    2. A is false and B is true
    3. A is false and B is false

P2 is only false when A is false and B is true
This is not the way that English "if" works.

No, P2 is only false if A is true and B is false.

If A is false, then the "if" doesn't "activate" and doesn't say anything
about B.

Where did you learn logic?

If the moon was made of green cheese, it would be tasty, is a true
statement.

The fact that the mood isn't made of green cheese, means we don't know
anyting about the taste of it.

What do ~P1,~P2 mean in terms of A,B? And why?

Implication does not have the same semantics of
English "if" therefore it is misleading.

Just a problem for people who don't understand the meaning of the words
as terms-of-art

Of course, since you just showed you don't know what IF means.



Your problem is that, you don't understand that you need to use words in
the context they are given, and thus you don't understand what you read
as you use the wrong defintions, and then LIE about what you thought you understood, as it was based on errors.

https://en.wikipedia.org/wiki/Paradoxes_of_material_implication

If A then B (In English) means that when A is
true then B is true otherwise we cannot know
the value of B.

Right, and that is how logic works too.

P2 ia true is A is true and B is true, or
if A is false, then B could be true of false, which is just saying we
don't know anything about it.

You are just showing how bad your sense of logic is.

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

On 7/27/25 5:13 PM, olcott wrote:

On 7/27/2025 4:06 PM, wij wrote:

On Sun, 2025-07-27 at 22:13 +0800, wij wrote:

On Sun, 2025-07-27 at 08:59 -0500, olcott wrote:

On 7/27/2025 8:21 AM, wij wrote:

On Sun, 2025-07-27 at 07:57 -0500, olcott wrote:

On 7/27/2025 12:07 AM, wij wrote:

On Sun, 2025-07-27 at 00:04 -0500, olcott wrote:

On 7/26/2025 11:56 PM, wij wrote:

On Sat, 2025-07-26 at 23:47 -0500, olcott wrote:

On 7/26/2025 11:39 PM, wij wrote:

On Sat, 2025-07-26 at 23:26 -0500, olcott wrote:

On 7/26/2025 11:14 PM, wij wrote:

On Sat, 2025-07-26 at 23:02 -0500, olcott wrote:

It is incorrect to have halt decider
H report on the behavior of machine M.
Directly executing Turing machines are
not in the domain of any halt decider.

Then, basically, it would be POO Problem, technically >>>>>>>>>>>>> nothing to do with HP.

I have now fully refuted all conventional proofs
of undecidability of the halting problem.

This supersedes everything else that I have ever said.

Hopping mode again.
POOP is Peter Olcott's Own Problem. It supersedes none.

Try FORMALLY specify POOP. It will be very difficult, because: >>>>>>>>

I have already done this and no one here
was bright enough to understand. Too much
learned by rote and not enough think things through.

Impossible, because:
1. you have shown again you don't understand basic logic
(AND,IF,...)

That is counter-factual.
The truth is that you have shown that you don't
understand advanced logic: G := ⊬G

You don't even know what the symbols mean
when I give you the source of their definitions:
https://en.wikipedia.org/wiki/List_of_logic_symbols

2. You cannot construct a TM that compute the length of its input. >>>>>>> 3. Your understanding of C/Assembly is shown very low, I never
saw anyone is lower.

*That is counter-factual*
I wrote the x86utm operating system in C++ that allows
one C function to emulate each x86 instruction of another
C function in debug step mode.

This C function is emulated in its own process context
having its own virtual stack and set of 16 virtual registers.

Because it will be very difficult to communicate anything
logically. So, try again
the basic logic you failed and dodged.

You have not used any reasoning you only provided the
ad hominem error of reasoning. That is very lame.

To save our troubles, let's run the basic logic again to ensure the
communication
is effective.

P1= A AND B
    P1 is true means A,B both are true, otherwise P1 is false.

P2= IF A THEN B
    P2 is true means
     1. A is true and B is true
     2. A is false and B is true
     3. A is false and B is false

P2 is only false when A is false and B is true
This is not the way that English "if" works.

Excellent, what about ~P1 And why?

No answer?  A professional programmer does not know ~P1? Are you kidding? >> How do you program the if-clause if you decide to negate the condition?

If a professional mathematician was
asked if they know how to do first
grade arithmetic the answer would probably be: "fuck off"

Seems people are getting under you skin by showing how ignorant you are
of what you are talking about.

The fact that you have shown how bad you logic is puts you into a bad state.

Assume some author of a book proves "A AND B" is true, you would like to
refute. What's the T/F combination that A,B should be?

What do ~P1,~P2 mean in terms of A,B? And why?

Implication does not have the same semantics of
English "if" therefore it is misleading.

https://en.wikipedia.org/wiki/Paradoxes_of_material_implication

If A then B (In English) means that when A is
true then B is true otherwise we cannot know
the value of B.

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

Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:

On 7/27/2025 9:48 PM, Richard Damon wrote:

On 7/27/25 8:20 PM, olcott wrote:

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

On 7/27/25 5:46 PM, olcott wrote:

On 7/27/2025 4:31 PM, Richard Damon wrote:

but anything said to the AI, has a chance of being recorded and
used for future training.

And you have been posting your lies on usenet, which is a source of
training, for awhile.

Just think, you might be the one responsible for providing the lies >>>>>> that future AIs have decided to accept ruining the chance of some
future breakthrough.

The above input that I provided has zero falsehoods.
ChatGPT figured out all of the reasoning from that basis.

But. not full definitions, like the fact that a given program on a
given input will always do the same thing.

When DDD is emulated by HHH1 it need not emulate itself at all.

But "itself" doesn't matter to x86 instructions,

By itself I mean the exact same machine code bytes at the exact same
machine address.

Yeah, so when you change HHH to abort later, you also change 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)

On 7/27/25 11:47 PM, olcott wrote:

On 7/27/2025 10:26 PM, wij wrote:

On Sun, 2025-07-27 at 22:12 -0500, olcott wrote:

On 7/27/2025 9:53 PM, wij wrote:

On Sun, 2025-07-27 at 19:20 -0500, olcott wrote:

Everyone here has pretended to be to fucking stupid
to see that for three fucking years thus providing
sufficient evidence that they are all damned liars.

olcott said: "You have not used any reasoning you only provided the
           ad hominem error of reasoning. That is very lame." >>>

*I have all of the correct reasoning right here*

https://www.researchgate.net/
publication/394042683_ChatGPT_analyzes_HHHDDD

I did not even need to come up with it myself.
I just told ChatGPT the problem and it came up
with my solution.

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

I have no problem with that. The problem is H is apparently not a
decider.

That people have denied that it is impossible
for DDD correctly simulated by HHH to reach
its own "return" instruction seems to prove
that they are liars.

You don't know logic, you cannot prove anything.

(1) Conventional symbolic logic has nothing to do with this.

(2) That DDD correctly simulated by HHH cannot possibly
reach its own simulated "return" instruction is a matter
of formal language semantics.

The problem here is that YOUR "HHH" isn't a program and neither is your
"DDD" so "Correct simulaton" is just a category error.

If HHH was a program, it would have specific behaivor, and if DDD was a program, it would include all of its code, including that of the
specific HHH it was built on.

A PROGRAM HHH, that correctly simulted its input, could not be a halt
decider, as if it was given the DDD built on itself, it would, as you
claim, continue to simulate its input forever, and thus never answer and
thus not be a decider.

If you changed that to a DIFFERENT program that tried to be a decider by detecting some pattern in its input and aborting its simulation, would
now be given a DIFFERENT input, the one based on this new HHH. Since HHH
aborts its simulaiton, its simulation is no longer determinative of
behavior, but the CORRECT simulation of this input (like with the first
HHH), which would now be given the DDD that uses the HHH that aborts and returns 0, would simulate this input, past the point that the aborting
one aborts at, to the point where the simulated new DDD's HHH does its
aborts, and then to the return 0 and final return from DDD, so the input
is HALTING.

Your problem is you LIE when you say the two different input are somehow
the same, or change when we change who simulates them.

This is partially due to the fact that your HHH and DDD aren't program,
because you think of both of the above as "your HHH" even though they
are two different programs, and all the various DDDS that are created as
being the same, as you don't have them include the code of the decider
they call, and thus are not programs.

All this proves is that you stupidly are ignoring the definitions in the problem, because you chose to never learn them, and that make you a pathological liar, as you removed your ability to tell right from wrong
by choosing to ignore the definitions.

How many people here are very interested in the
theory of computation that don't know the first
thing about programming?

You are not interested in the theory of computation.
All is shown that you are only interested in "I am correct".

Only only seems that way because (a) You don't know this stuff
very well. (b) You are so sure that I must be wrong that you
don't bother to even hear my reasoning much less verify it.

No, the problem is that YOU don't know what you are talking about, and
are misusing words. Like PROGRAM.

The Decider and the input need to be PROGRAMS in the Compuation Science meaning, which means they include ALL of the code they use, and ONLY
look at their input.

Thus, each HHH has specific behavior, and each DDD built from a
different HHH is different.

There are many more steps of my reasoning that cannot
be understood until the first step is understood.

How many medical doctors don't know anything about
bacterial infections?

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

Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:

On 7/28/2025 2:30 AM, joes wrote:

Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:

On 7/27/2025 9:48 PM, Richard Damon wrote:

On 7/27/25 8:20 PM, olcott wrote:

When DDD is emulated by HHH1 it need not emulate itself at all.

But "itself" doesn't matter to x86 instructions,

By itself I mean the exact same machine code bytes at the exact same
machine address.

Yeah, so when you change HHH to abort later, you also change DDD.

HHH is never changed.

It is changed in the hypothetical unaborted simulation. HHH is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the halting DDD,
and definitely not on HHH(DDD), itself.

--
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 Mon, 28 Jul 2025 08:54:46 -0500 schrieb olcott:

On 7/28/2025 8:21 AM, joes wrote:

Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:

On 7/28/2025 2:30 AM, joes wrote:

Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:

By itself I mean the exact same machine code bytes at the exact same >>>>> machine address.

Yeah, so when you change HHH to abort later, you also change DDD.

HHH is never changed.

It is changed in the hypothetical unaborted simulation. HHH is
reporting on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the
halting DDD, and definitely not on HHH(DDD), itself.

All halt deciders are required to predict the behavior of their input.

And not a hypothetical input calling a different simulator.

HHH does correctly predict that DDD correctly simulated by HHH cannot possibly reach its own simulated "return" instruction final halt state.

HHH predicts what DDD' calling UTM(DDD') would do, not DDD calling
HHH(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 Mon, 28 Jul 2025 09:53:58 -0500 schrieb olcott:

On 7/28/2025 9:25 AM, joes wrote:

Am Mon, 28 Jul 2025 08:54:46 -0500 schrieb olcott:

On 7/28/2025 8:21 AM, joes wrote:

Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:

On 7/28/2025 2:30 AM, joes wrote:

Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:

By itself I mean the exact same machine code bytes at the exact
same machine address.

Yeah, so when you change HHH to abort later, you also change DDD.

HHH is never changed.

It is changed in the hypothetical unaborted simulation. HHH is
reporting on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the
halting DDD, and definitely not on HHH(DDD), itself.

All halt deciders are required to predict the behavior of their input.

And not a hypothetical input calling a different simulator.

HHH remains the exact same byte sequence at the exact same machine
address.

Not when you imagine it not aborting, for the purpose determining the
halting status as per Sipser's misquote.

HHH does correctly predict that DDD correctly simulated by HHH cannot
possibly reach its own simulated "return" instruction final halt
state.

HHH predicts what DDD' calling UTM(DDD') would do, not DDD calling
HHH(DDD).

HHH correctly predicts that no DDD correctly simulated by any HHH can possibly reach its own simulated "return" instruction final halt state.

"no DDD" supposes the modification of the input.

What does HHH(HHH,HHH) return?

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,

That pattern is wrong, as HHH containing it clearly halts.

--
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 7/28/25 8:11 AM, olcott wrote:

On 7/28/2025 2:30 AM, joes wrote:

Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:

On 7/27/2025 9:48 PM, Richard Damon wrote:

On 7/27/25 8:20 PM, olcott wrote:

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

On 7/27/25 5:46 PM, olcott wrote:

On 7/27/2025 4:31 PM, Richard Damon wrote:

but anything said to the AI, has a chance of being recorded and >>>>>>>> used for future training.

And you have been posting your lies on usenet, which is a source of >>>>>> training, for awhile.

Just think, you might be the one responsible for providing the lies >>>>>>>> that future AIs have decided to accept ruining the chance of some >>>>>>>> future breakthrough.

The above input that I provided has zero falsehoods.
ChatGPT figured out all of the reasoning from that basis.

But. not full definitions, like the fact that a given program on a >>>>>> given input will always do the same thing.

When DDD is emulated by HHH1 it need not emulate itself at all.

But "itself" doesn't matter to x86 instructions,

By itself I mean the exact same machine code bytes at the exact same
machine address.

Yeah, so when you change HHH to abort later, you also change DDD.

HHH is never changed.

The it always does the same thing, and never actually correctly
simulates DDD, and always returns 0, even when called by DDD, and thus
DDD is halting.

Note, since HHH never does a correct simulation, which by definition is
a complete simulation, at least in this context, your criteria of
correct simulation by HHH is just nonsense.

https://www.researchgate.net/publication/394042683_ChatGPT_analyzes_HHHDDD

ChatGPT came up with my own reasoning on its own.
If you know anything about programming you will
be able to understand this. Its about a five
minute read.

https://www.researchgate.net/publication/394042683_ChatGPT_analyzes_HHHDDD

Which just shows that it is wrong, because you misled it.

It is easy enough to get AIs to say incorrect things.

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

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

On 7/28/2025 8:21 AM, joes wrote:

Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:

On 7/28/2025 2:30 AM, joes wrote:

Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:

On 7/27/2025 9:48 PM, Richard Damon wrote:

On 7/27/25 8:20 PM, olcott wrote:

When DDD is emulated by HHH1 it need not emulate itself at all.

But "itself" doesn't matter to x86 instructions,

By itself I mean the exact same machine code bytes at the exact same >>>>> machine address.

Yeah, so when you change HHH to abort later, you also change DDD.

HHH is never changed.

It is changed in the hypothetical unaborted simulation. HHH is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the halting DDD,
and definitely not on HHH(DDD), itself.

All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly
simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.

How is it a "correct prediction" if it sees something different than
what that DDD does.

Remember, to have simulated that DDD, it must have include the code of
the HHH that it was based on, which is the HHH that made the prediction,
and thus returns 0, so DDD will halt.

Simulationg a DIFFERENT DDD, and using that for this DDD, is just lying.

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

On 7/28/25 8:28 AM, olcott wrote:

On 7/28/2025 6:38 AM, Richard Damon wrote:

On 7/27/25 11:47 PM, olcott wrote:

On 7/27/2025 10:26 PM, wij wrote:

On Sun, 2025-07-27 at 22:12 -0500, olcott wrote:

On 7/27/2025 9:53 PM, wij wrote:

On Sun, 2025-07-27 at 19:20 -0500, olcott wrote:

Everyone here has pretended to be to fucking stupid
to see that for three fucking years thus providing
sufficient evidence that they are all damned liars.

olcott said: "You have not used any reasoning you only provided the >>>>>>            ad hominem error of reasoning. That is very lame." >>>>>

*I have all of the correct reasoning right here*

https://www.researchgate.net/
publication/394042683_ChatGPT_analyzes_HHHDDD

I did not even need to come up with it myself.
I just told ChatGPT the problem and it came up
with my solution.

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

I have no problem with that. The problem is H is apparently not a
decider.

That people have denied that it is impossible
for DDD correctly simulated by HHH to reach
its own "return" instruction seems to prove
that they are liars.

You don't know logic, you cannot prove anything.

(1) Conventional symbolic logic has nothing to do with this.

(2) That DDD correctly simulated by HHH cannot possibly
reach its own simulated "return" instruction is a matter
of formal language semantics.

The problem here is that YOUR "HHH" isn't a program and neither is
your "DDD" so "Correct simulaton" is just a category error.

If it was a program it would be wrong.
It must be a function computed from inputs.

But "Functions" in this context aren't restricted to being finite
algorithms.

Your problem is that the halting problem is about making a PROGRAM that computes the result of the Halting FUNCITON.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
   if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
   its simulated final halt state of ⟨Ĥ.qn⟩, and

Nope.

If Ĥ ⟨Ĥ⟩ reaches a final halting state.

PERIOD.

You don't get to change the condition.

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

Nope.

If Ĥ ⟨Ĥ⟩ can never reach a final halting state, even after an unbounded number of steps

PERIOD.

You don't get to change the condition.

You are just admitting that your proof is based on a strawman and a lie.

(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(h) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(i) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
never reaching its simulated final halt state of ⟨Ĥ.qn⟩

If that is true, then H can never answer either as H and embedded_H must
do the same thing since they are the same algorithm.

Since you seem to presume that your H WILL abort its simulation and go
to Qn, then the embedded_H started in (c) will also do that at the same
point in its simulation, (which will be after H has aborted the
simulation of this input, but we can look at its continuation as a
correct simulation, since that is a usable replacement for the direct execution) and then go to qn and Ĥ will halt.

Since Ĥ (Ĥ) will halt, as does UTM (Ĥ) (Ĥ), the correct answer for H
will be Qy, so it was just wrong.

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/28/25 7:20 PM, olcott wrote:

On 7/28/2025 5:57 PM, Richard Damon wrote:

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

On 7/28/2025 8:21 AM, joes wrote:

Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:

On 7/28/2025 2:30 AM, joes wrote:

Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:

On 7/27/2025 9:48 PM, Richard Damon wrote:

On 7/27/25 8:20 PM, olcott wrote:

When DDD is emulated by HHH1 it need not emulate itself at all. >>>>>>>> But "itself" doesn't matter to x86 instructions,

By itself I mean the exact same machine code bytes at the exact same >>>>>>> machine address.

Yeah, so when you change HHH to abort later, you also change DDD.

HHH is never changed.

It is changed in the hypothetical unaborted simulation. HHH is
reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the halting
DDD,
and definitely not on HHH(DDD), itself.

All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly
simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.

How is it a "correct prediction" if it sees something different than
what that DDD does.

What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.

But the behavior of the program continues past that (something you don't
seem to understand) and that behavior will also have its HHH terminate
the DDD it is simulating and return 0 to DDD and then Halt.

Your problem is you don't understand that the simulating HHH doesn't
define the behavior of DDD, it is the execution of DDD that defines what
a correct simulation of it is.

Remember, to have simulated that DDD, it must have include the code of
the HHH that it was based on, which is the HHH that made the
prediction, and thus returns 0, so DDD will halt.

We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.

No, that is EXACTLY the question.

I guess you are just admitting that you whole world is based on LYING
about what things are supposed to be.

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

Right, and HHH was given the equivalenet of (M) by being given the code
of *ALL* of DDD

I guess you don't understand that fact, even though you CLAIM the input
is the proper representation of DDD.

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

No, it is DEFINED to be the behavior of the direct execution of the
program it represent.

You are just proving that you are just an ignorant liar that doesn't
know the meaning of the words he is using.

When machine description ⟨M⟩ correctly simulated
by H cannot possibly reach its own simulated final
halt state this proves that the ⟨M⟩ input to H specifies
a non-terminating sequence of configurations.

Just because H doesn't correct simulate its input doesn't change the
meaning of the input.

UTM (M) when (M) is (DDD) will halt, and thus shows that it is halting.

You are just showing you don't know the meaning of the words you are using.

Simulationg a DIFFERENT DDD, and using that for this DDD, is just lying.

You might have to read those words a few times
to get all of their meaning.

No, I know what I said, it seems you don't.

You are just proving that you don't know what the words you use mean.

Since you admitted to not studying the field, out of a fear of being brainwashed by rote learning, just make you into an ignorant
pathological liar, that can't actualy defend any of his positions.

The problem is to actually try to prove anything, you have to start with quoting the accepted definitions and axioms you are going to use.

Since you don't know them, you can't use them.

You are just proving your ignorance by stating falsehood, which become
lies when repeated after correction, as it then become with knowledge of reckless disregard for the truth.

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

Am Wed, 30 Jul 2025 09:30:26 -0500 schrieb olcott:

On 7/30/2025 1:44 AM, joes wrote:

Am Tue, 29 Jul 2025 22:12:42 -0500 schrieb olcott:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the program
under test it is true that neither the simulated DDD nor the simulated
HHH cannot possibly reach their own final halt state.

You have been told that many times. Then HHH is not a decider.

HHH(DDD) does correctly decide thus proving that it is a decider for
DDD.

No, the simulated HHH does not return.

--
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 Wed, 30 Jul 2025 10:02:05 -0500 schrieb olcott:

On 7/30/2025 5:59 AM, Richard Damon wrote:

On 7/29/25 11:12 PM, olcott wrote:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the program
under test it is true that neither the simulated DDD nor the simulated
HHH cannot possibly reach their own final halt state.

Sure they do, when correctly simulated. What doens't happne is that the
PARTIAL simulation (and thus not correct) of HHH can't reach that
state.

We have been over this too many times. If DDD was incorrectly emulated
by HHH then you could show the exact x86 instruction of DDD that was
emulated incorrectly when DDD is emulated by HHH or when DDD is emulated
by the emulated HHH.

Yeah, we have. The second call to HHH is not simulated.

--
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 Wed, 30 Jul 2025 10:06:41 -0500 schrieb olcott:

On 7/30/2025 9:33 AM, joes wrote:

Am Wed, 30 Jul 2025 09:30:26 -0500 schrieb olcott:

On 7/30/2025 1:44 AM, joes wrote:

Am Tue, 29 Jul 2025 22:12:42 -0500 schrieb olcott:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the program
under test it is true that neither the simulated DDD nor the
simulated HHH cannot possibly reach their own final halt state.

You have been told that many times. Then HHH is not a decider.

HHH(DDD) does correctly decide thus proving that it is a decider for
DDD.

No, the simulated HHH does not return.

The fact that HHH(DDD) does correctly report that its simulated input
cannot possibly reach its own simulated final halt state is complete
proof that HHH(DDD)==0 is correct.

That HHH returns 0 proves that it is correct? Circular reasoning.

You cannot possibly derive any correct reasoning to the contrary.

I ask you again, what does HHH(HHH) return?

--
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 Wed, 30 Jul 2025 10:43:03 -0500 schrieb olcott:

On 7/30/2025 10:23 AM, joes wrote:

Am Wed, 30 Jul 2025 10:02:05 -0500 schrieb olcott:

On 7/30/2025 5:59 AM, Richard Damon wrote:

On 7/29/25 11:12 PM, olcott wrote:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the program
under test it is true that neither the simulated DDD nor the
simulated HHH cannot possibly reach their own final halt state.

Sure they do, when correctly simulated. What doens't happne is that
the PARTIAL simulation (and thus not correct) of HHH can't reach that
state.

We have been over this too many times. If DDD was incorrectly emulated
by HHH then you could show the exact x86 instruction of DDD that was
emulated incorrectly when DDD is emulated by HHH or when DDD is
emulated by the emulated HHH.

Yeah, we have. The second call to HHH is not simulated.

I proved that the emulated HHH does emulate DDD correctly and you simply ignored this proof.

No. The simulated HHH does not simulate HHH because it is aborted.

--
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 30.jul.2025 om 17:55 schreef olcott:

On 7/30/2025 10:27 AM, joes wrote:

Am Wed, 30 Jul 2025 10:06:41 -0500 schrieb olcott:

On 7/30/2025 9:33 AM, joes wrote:

Am Wed, 30 Jul 2025 09:30:26 -0500 schrieb olcott:

On 7/30/2025 1:44 AM, joes wrote:

Am Tue, 29 Jul 2025 22:12:42 -0500 schrieb olcott:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the program >>>>>>> under test it is true that neither the simulated DDD nor the
simulated HHH cannot possibly reach their own final halt state.

You have been told that many times. Then HHH is not a decider.

HHH(DDD) does correctly decide thus proving that it is a decider for >>>>> DDD.

No, the simulated HHH does not return.

The fact that HHH(DDD) does correctly report that its simulated input
cannot possibly reach its own simulated final halt state is complete
proof that HHH(DDD)==0 is correct.

That HHH returns 0 proves that it is correct? Circular reasoning.

*THIS IS THE PROOF. NO CIRCULARITY HERE*
its simulated input cannot possibly reach its own simulated
final halt state

Which is not a proof, because not reaching the halt state because the
simulator prevents it to reach the halt state is no evidence that the
final halt state is not specified.
Other simulators show that exactly the same input can be simulated up to
the final halts state. So, not being able to reach it, is a failure of
HHH,not a property of the program specified in the input.
This failure of HHH does not change the specification.

You cannot possibly derive any correct reasoning to the contrary.

I ask you again, what does HHH(HHH) return?

HHH(HHH) abnormally terminates because the inner
HHH is not given its required parameter.

int main() {
return HHH(main);
}


We have seen that here HHH halts but reports non-halting, proving that
HHH produces false negatives. The DDD is not needed to show the failure
of HHH, it is only olcott's way to distract the attention from HHH to
something else.

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

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

On 7/30/2025 11:07 AM, joes wrote:

Am Wed, 30 Jul 2025 10:43:03 -0500 schrieb olcott:

On 7/30/2025 10:23 AM, joes wrote:

Am Wed, 30 Jul 2025 10:02:05 -0500 schrieb olcott:

On 7/30/2025 5:59 AM, Richard Damon wrote:

On 7/29/25 11:12 PM, olcott wrote:

This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the program >>>>>>> under test it is true that neither the simulated DDD nor the
simulated HHH cannot possibly reach their own final halt state.

Sure they do, when correctly simulated. What doens't happne is that >>>>>> the PARTIAL simulation (and thus not correct) of HHH can't reach that >>>>>> state.

We have been over this too many times. If DDD was incorrectly emulated >>>>> by HHH then you could show the exact x86 instruction of DDD that was >>>>> emulated incorrectly when DDD is emulated by HHH or when DDD is
emulated by the emulated HHH.

Yeah, we have. The second call to HHH is not simulated.

I proved that the emulated HHH does emulate DDD correctly and you simply >>> ignored this proof.

No. The simulated HHH does not simulate HHH because it is aborted.

That I proved otherwise and you simply ignored this
proof is not any rebuttal and seems quite dishonest.

Counter factual. You proved that the simulation of the simulated HHH was aborted, before it could reach its final halt state.

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

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

On 8/1/2025 4:00 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 16:52 schreef olcott:

On 7/30/2025 4:23 AM, Fred. Zwarts wrote:

Op 30.jul.2025 om 05:12 schreef olcott:

Even if we construed the HHH that DDD calls a part of the program
under test it is true that neither the simulated DDD nor the
simulated HHH cannot possibly reach their own final halt state.

Indeed. But there are different reasons:
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,

This has been presented tro you many times, but you close your eyes for
it and pretend that it does not exist.

We have told you that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all function
called by DDD, directly or indirectly, including the HHH that aborts
after a few cycles.
This input specifies a halting program as other correct simulators and
direct execution prove.

We have been over this too many times. If it actually is a premature
abort then you could specify the number of N instructions of DDD that
must be correctly emulated by HHH such that DDD reaches its own final
halt state.

As usual a false claim.

Also already disproved.

If there is an actual *premature abort* then there is a specific point
in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third
recursive simulation.

--
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 10:44:59 -0500 schrieb olcott:

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

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

If there is an actual *premature abort* then there is a specific point
in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third
recursive simulation.

Everyone keeps dishonestly changing my words from (a) DDD correctly
simulated by HHH (can't possibly halt) (b) The directly executed DDD
(that halts).

I *am* talking about a (modified) HHH simulating 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 11:24:36 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 10:44:59 -0500 schrieb olcott:

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

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

If there is an actual *premature abort* then there is a specific
point in the execution trace where DDD correctly simulated by HHH
stops running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third
recursive simulation.

Everyone keeps dishonestly changing my words from (a) DDD correctly
simulated by HHH (can't possibly halt) (b) The directly executed DDD
(that halts).

I *am* talking about a (modified) HHH simulating DDD.

Like the price of tea in China, that is off topic.

Then shut up. You keep imagining modified versions of it.

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

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

Am Fri, 01 Aug 2025 10:44:59 -0500 schrieb olcott:

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

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

If there is an actual *premature abort* then there is a specific point >>>>> in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third
recursive simulation.

Everyone keeps dishonestly changing my words from (a) DDD correctly
simulated by HHH (can't possibly halt) (b) The directly executed DDD
(that halts).

I *am* talking about a (modified) HHH simulating DDD.

Like the price of tea in China, that is off topic.
I am only proving that the conventional proofs do
not derive their undecidability result.

Sure they do. as no decider can answer the Halting Question for all
inputs, and thus the problem is not computable.

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

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

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

Am Fri, 01 Aug 2025 11:24:36 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 10:44:59 -0500 schrieb olcott:

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

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

If there is an actual *premature abort* then there is a specific >>>>>>> point in the execution trace where DDD correctly simulated by HHH >>>>>>> stops running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third
recursive simulation.

Everyone keeps dishonestly changing my words from (a) DDD correctly
simulated by HHH (can't possibly halt) (b) The directly executed DDD >>>>> (that halts).

I *am* talking about a (modified) HHH simulating DDD.

Like the price of tea in China, that is off topic.

Then shut up. You keep imagining modified versions of it.

I am examining the exact same issue from different perspectives.
How the conventional HP proofs do not prove undecidability.
Your suggestion diverted from the conventional HP proofs.

Your "different perspectives" seems to be based on lies.

That seems to be how you look at everything, because that seems to be
your nature.

Just like you thinking you are god.

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

On 8/1/25 2:52 PM, olcott wrote:

On 8/1/2025 1:36 PM, Richard Damon wrote:

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

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

Am Fri, 01 Aug 2025 11:24:36 -0500 schrieb olcott:

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

Am Fri, 01 Aug 2025 10:44:59 -0500 schrieb olcott:

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

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

If there is an actual *premature abort* then there is a specific >>>>>>>>> point in the execution trace where DDD correctly simulated by HHH >>>>>>>>> stops running without ever being aborted.

Yes, after 12 instructions of DDD only or just before the third >>>>>>>> recursive simulation.

Everyone keeps dishonestly changing my words from (a) DDD correctly >>>>>>> simulated by HHH (can't possibly halt) (b) The directly executed DDD >>>>>>> (that halts).

I *am* talking about a (modified) HHH simulating DDD.

Like the price of tea in China, that is off topic.

Then shut up. You keep imagining modified versions of it.

I am examining the exact same issue from different perspectives.
How the conventional HP proofs do not prove undecidability.
Your suggestion diverted from the conventional HP proofs.

Your "different perspectives" seems to be based on lies.

Only because you cannot pay 100% complete attention to even
a single point that I make.

No, as I have pointed out all the errors in your words, you clearly
don't know what you are talking about.

Note, a "Different Perspective" still needs to use the same fundamental definitions, something you seem incapable of knowing.

If you want to make a new theory, you need to do that, and not confuse
it with trying to show something in the theory you don't understand.

I think your problem with me is that I can see TOO WELL what you are
doing, and cut off some of your lies before you can use them.

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

Am Sat, 02 Aug 2025 09:27:48 -0500 schrieb olcott:

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

It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.

*Not according to the leading author of theory of computation textbooks*

At least you acknowledge changing the input.

No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.

Prove your statement on this code.

It is very obvious. You can verify this by commenting out the abort.

What do you mean by premature abort?
The actual word "premature" means too early.
If the abort is too early then there is a point in the execution trace
that is not too early.

Yes. One level deeper.

It is exactly the premature abort that causes that the final halt state
is not reached. Of course, the trace of that prematurely aborted
simulation does not show the last part of a correct simulation.

In other words when DDD calls its own simulator HHH in recursive
simulation this is exactly the same thing as DDD never calling its own simulator HHH1 in recursive simulation?

Strawman. But yes, HHH is not HHH1.

But a comparison with a correct simulation done by e.g. HHH1, shows the
exact point where the final halt state is reached and where HHH does
the premature abort.

--
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/2/25 3:33 PM, olcott wrote:

On 8/2/2025 1:26 PM, joes wrote:

Am Sat, 02 Aug 2025 09:27:48 -0500 schrieb olcott:

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

It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.

*Not according to the leading author of theory of computation textbooks*

At least you acknowledge changing the input.

No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.

Prove your statement on this code.

It is very obvious. You can verify this by commenting out the abort.

What do you mean by premature abort?
The actual word "premature" means too early.
If the abort is too early then there is a point in the execution trace
that is not too early.

Yes. One level deeper.

Do you understand that when the executed HHH waits for
one more recursive emulation that each simulated HHH
also waits for one more recursive emulation because every
HHH has the exact same machine code bytes?

No, because when you imagine it changing, you don't actually change the
input, or the HHHs that are there.

Remember, the behavior of the input is based on the UNALTERED behavior
of that machine or simulation of it. If HHH aborts its simulation, you
need to look at the unaborted simulation that would have continued, but
that doesn't change the code of HHH.

It seems you don't understand that principle, because it is too abstract
for you.

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

On 8/2/25 2:49 PM, olcott wrote:

On 8/2/2025 1:26 PM, joes wrote:

Am Sat, 02 Aug 2025 09:27:48 -0500 schrieb olcott:

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

It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.

*Not according to the leading author of theory of computation textbooks*

At least you acknowledge changing the input.

Halt deciders never report on the actual complete
step-by-step behavior of any non-terminating input
or they would get stuck in non-halting behavior
themselves.

Do you understand this much?

Then you don't understand what you are talking about, because that is
what Halt Deciders are DEFINED to do.

You seem to confuse the deciders ability to determine what the input
does with them needing to create that behavior themselves.

Of course, that is because you LIED to yourself that the critera was
based on the simulation done by the decider, instead of the behavior the
input actually specifies.

Just shows your confusion between truth and knowledge.

If the correct simulation of the input would never halt, then the halt
decider, rather than doing a correct simulation, needs to try to detect
that and answer non-halting. Of course, if the input includes a version
of that decider, that version will also do that, so the decider needs to
take that into account in its analysis.

Your problem is you just don't understand how programs work, as you keep
on thinking of them as willfull and making choices, when they just do "mechanical" computations based on their algorithm, and do what they
were told to do.

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

On 8/2/25 4:05 PM, olcott wrote:

On 8/2/2025 2:59 PM, Richard Damon wrote:

On 8/2/25 2:49 PM, olcott wrote:

On 8/2/2025 1:26 PM, joes wrote:

Am Sat, 02 Aug 2025 09:27:48 -0500 schrieb olcott:

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

It is an irrelevant change of subject to imagine a hypothetical non- >>>>>> input that has no abort code.

*Not according to the leading author of theory of computation
textbooks*

At least you acknowledge changing the input.

Halt deciders never report on the actual complete
step-by-step behavior of any non-terminating input
or they would get stuck in non-halting behavior
themselves.

Do you understand this much?

Then you don't understand what you are talking about, because that is
what Halt Deciders are DEFINED to do.

No this is merely your attention deficit disorder
not paying attention to these words:
*complete step-by-step behavior of any non-terminating input*

Right. It must report on the behavior of the COMPLETE step-by-step
simulation of the input, which WILL exactly match the behavior of the
program it represents (or the simulation or representation is incorrect).

Reporting on the complete step-by-step behavior of an
infinite loop would take forever.

No, for infinite loop it takes simulating one step. The decider sees
after one step that it has returned to the IDENTICAL state it started
in. Thus ever step after will do the same, and never halt.

The decider doesn't need to DO the step-by-step behavior, just report if
that behavior will halt is something DID do the full step-by-step
simulation.

This is your fundamental problem, you don't understand the difference
between the decider determining what such a simulation would do if it
can't do it itself.

This just means you don't understand how you can reason about something
you can't directly sense.

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