From Newsgroup: comp.theory

On 9/6/25 1:05 PM, olcott wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55             push ebp
[00002184] 8bec           mov ebp,esp
[00002186] 6883210000     push 00002183 ; push DDD
[0000218b] e833f4ffff     call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404         add esp,+04
[00002193] 5d             pop ebp
[00002194] c3             ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55             push ebp
[000021a4] 8bec           mov ebp,esp
[000021a6] 6883210000     push 00002183 ; push DDD
[000021ab] e843f3ffff     call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

So where is that simulation?

Note that should be a continuation of the currect simulation, not the
creating of a new simulation environment.

This causes Decide_Halting() to consider HHH and HHH1 to be different,
so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But if the recursive simulation actually makes DD non-halting then HHH1
should be able to detect that and show it never halting.

The fact that HHH1 can show how DD halts shows that HHH is wrong to say
it doesn't

The problem is you are trying to define that FINITE recursive simulation
is an INFINITE behavior when it isn't

25% of all of the posts on comp.theory since 2004
are my posts.

And probably 99% of the Noise in its SNR.

Contrary to your naive belief and insistance, HHH and HHH1 are not the
same function, because Decide_Halting is telling them apart by adddress.

*I never said they were the same function*
WTF did you think that I meant by DD calls HH(DD)
in recursive simulation and DD does not call
HHH1(DD) at all?

You claim them to be "Identical"

Being so sure that I must be wrong that you don't
pay enough attention is the systematic error of bias.

The fact that DD Halts when HHH(DD) says it doesn't is enough to show
you are wrong about HHH correctly answering the halting question for
that input.

Decide_Halting examines the instruction stream, and looks at what
addresses are being called by a CALL instruction and compares them
to the Address_Of_HHH parameter.

Not at all. Decide_Halting is called from HHH and called
from HHH1.

And uses incorrect logic, which can sometimes accedentially get the
right answer.

Pure functions cannot be looking at the name/address of their caller.

Can you now see that their is no actual bug causing
the difference in behavior of DD simulated by HHH
and DD simulated by HHH1?

Sure there is. The specification that you imply HHH is following is the halting problem, and thus it gives the wrong answer.

That can be traces to a bug in the defintion of a non-halting pattern to included a pattern that exists in inputs that halt.

The fact that you try to define that you aren't actually working on the problem you claim to be working on, but that you had the right to change
it, is just a bug in the specifications you rewrote.

In all, all you are doing is proving you don't have any idea what many
of the words you use acutlly mean, and just don't care about that,
making you just an ignorant pathological liar.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be different,
so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

If (1) and (2 are true, then it must be true that any call to HHH(X) can
be replaced by HHH1(X) and vice versa without making any difference.

Your traces show that this is false. HHH(DD) has a different
execution trace from HHH1(DD).

Therefore at least one of the above conditions (1) and (2) do not hold.

HHH and HHH1 are not identical or else there is impurity, or both.

Contrary to your naive belief and insistance, HHH and HHH1 are not the
same function, because Decide_Halting is telling them apart by adddress.

*I never said they were the same function*

Then what is the point?

WTF did you think that I meant by DD calls HH(DD)
in recursive simulation and DD does not call
HHH1(DD) at all?

Probably that DD's source code doesn't reference the
function using its HHH1 name.

Being so sure that I must be wrong that you don't
pay enough attention is the systematic error of bias.

What is the purpose of having two functions that are copy-paste
of each other, except that the name HHH is replaced by HHH1
everywhere?

You acknowledge that they are different functions; so then
what are you trying to show?

Decide_Halting examines the instruction stream, and looks at what
addresses are being called by a CALL instruction and compares them
to the Address_Of_HHH parameter.

Not at all. Decide_Halting is called from HHH and called
from HHH1.

I know that and my above remarks do not contradict it whatsoever.
What are you talkin gbout?

Do you not know that you have a parameter called Address_Of_H
(or something very similar) in your own code?

When HHH1 calls Decide_Halting, that parameter points to HHH1;
When HHH calls it, the parameter points to HHH.

Thus HHH and HHH1 are different deciders. Each one looks for evidence of
itself in recursive simulation, and treats the other as an ordinary
function.

Pure functions cannot be looking at the name/address of their caller.

Can you now see that their is no actual bug causing
the difference in behavior of DD simulated by HHH
and DD simulated by HHH1?

I can see that the difference isn't a bug if you actually intend for
those functions to be different.

But, you cannot disprove the Halting Proof using two deciders.

The Halting Proof doesn't say that the diagonal DD case, built on a
decider HHH, cannot be resolved by a different decider HHH1.

The only way HHH and HHH1 could be relevant to the Halting Proof is if
you intend for them to be understood as the same function; (but then
being mistaken due to them not actually being the same).

So it's a "head scratcher" as to where you are going with this, if you
know the functions are different and intend that.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/25 3:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be different,
so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

He claims it, and then admits that they are not, but that it doesn't matter.

Actually, they are fundamentally impure, as there algorithm is based on
an impurity, they access the address that they are at, information that
is NOT provided to them as an input.

That this is an impurity seems to be beyond Peter's ability to understand.

He wants them to be "the same" and be pure functions, so that his idea
that context affects the behavior of a pure function can be shown, which
is needed for his proof.

If (1) and (2 are true, then it must be true that any call to HHH(X) can
be replaced by HHH1(X) and vice versa without making any difference.

Your traces show that this is false. HHH(DD) has a different
execution trace from HHH1(DD).

Therefore at least one of the above conditions (1) and (2) do not hold.

HHH and HHH1 are not identical or else there is impurity, or both.

Contrary to your naive belief and insistance, HHH and HHH1 are not the
same function, because Decide_Halting is telling them apart by adddress. >>>

*I never said they were the same function*

Then what is the point?

WTF did you think that I meant by DD calls HH(DD)
in recursive simulation and DD does not call
HHH1(DD) at all?

Probably that DD's source code doesn't reference the
function using its HHH1 name.

Being so sure that I must be wrong that you don't
pay enough attention is the systematic error of bias.

What is the purpose of having two functions that are copy-paste
of each other, except that the name HHH is replaced by HHH1
everywhere?

You acknowledge that they are different functions; so then
what are you trying to show?

Decide_Halting examines the instruction stream, and looks at what
addresses are being called by a CALL instruction and compares them
to the Address_Of_HHH parameter.

Not at all. Decide_Halting is called from HHH and called
from HHH1.

I know that and my above remarks do not contradict it whatsoever.
What are you talkin gbout?

Do you not know that you have a parameter called Address_Of_H
(or something very similar) in your own code?

When HHH1 calls Decide_Halting, that parameter points to HHH1;
When HHH calls it, the parameter points to HHH.

Thus HHH and HHH1 are different deciders. Each one looks for evidence of itself in recursive simulation, and treats the other as an ordinary
function.

Pure functions cannot be looking at the name/address of their caller.

Can you now see that their is no actual bug causing
the difference in behavior of DD simulated by HHH
and DD simulated by HHH1?

I can see that the difference isn't a bug if you actually intend for
those functions to be different.

But, you cannot disprove the Halting Proof using two deciders.

The Halting Proof doesn't say that the diagonal DD case, built on a
decider HHH, cannot be resolved by a different decider HHH1.

The only way HHH and HHH1 could be relevant to the Halting Proof is if
you intend for them to be understood as the same function; (but then
being mistaken due to them not actually being the same).

So it's a "head scratcher" as to where you are going with this, if you
know the functions are different and intend that.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 2:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be different,
so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

I had forgotten that HHH is not a pure function
until you first mentioned this recently.

Richard Heathfield's recent idea of defining HHH
as a parser seems to be the best alternative.

I have written the parser for C "if" statements
that generates jump-code for expressions of
arbitrary complexity and "if" statements of arbitrary
nesting depth using YACC and LEX, so this should
be easy.

It took me ten years to find out that abstract syntax
trees are the key. I never noticed this in the Dragon
book.

If (1) and (2 are true, then it must be true that any call to HHH(X) can
be replaced by HHH1(X) and vice versa without making any difference.

NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO
NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO
NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO
NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO
NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO
NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO

DD calls HHH(DD) in recursive simulation
THIS CHANGES THE BEHAVIOR OF DD
THIS CHANGES THE BEHAVIOR OF DD
THIS CHANGES THE BEHAVIOR OF DD
THIS CHANGES THE BEHAVIOR OF DD
THIS CHANGES THE BEHAVIOR OF DD

Your traces show that this is false. HHH(DD) has a different
execution trace from HHH1(DD).

DD calls HHH(DD) in recursive simulation
DD calls HHH(DD) in recursive simulation
DD calls HHH(DD) in recursive simulation
DD calls HHH(DD) in recursive simulation
DD calls HHH(DD) in recursive simulation

Therefore at least one of the above conditions (1) and (2) do not hold.

I NEVER SAID THEY ARE IDENTICAL FUNCTIONS
I NEVER SAID THEY ARE IDENTICAL FUNCTIONS
I NEVER SAID THEY ARE IDENTICAL FUNCTIONS
I NEVER SAID THEY ARE IDENTICAL FUNCTIONS
I NEVER SAID THEY ARE IDENTICAL FUNCTIONS

I said that they had identical source code except
for their name.

HHH and HHH1 are not identical or else there is impurity, or both.

Contrary to your naive belief and insistance, HHH and HHH1 are not the
same function, because Decide_Halting is telling them apart by adddress. >>>

*I never said they were the same function*

Then what is the point?

WTF did you think that I meant by DD calls HH(DD)
in recursive simulation and DD does not call
HHH1(DD) at all?

Probably that DD's source code doesn't reference the
function using its HHH1 name.

THIS MAKES THEM HAVE DIFFERENT BEHAVIOR

Being so sure that I must be wrong that you don't
pay enough attention is the systematic error of bias.

What is the purpose of having two functions that are copy-paste
of each other, except that the name HHH is replaced by HHH1
everywhere?

TO CONCLUSIVELY PROVE THAT THE FACT THAT
DD CALLS HHH(DD) IN RECURSIVE EMULATION
CHANGES THE BEHAVIOR THAT HHH SEES

You acknowledge that they are different functions; so then
what are you trying to show?

TO CONCLUSIVELY PROVE THAT THE FACT THAT
DD CALLS HHH(DD) IN RECURSIVE EMULATION
CHANGES THE BEHAVIOR THAT HHH SEES

Decide_Halting examines the instruction stream, and looks at what
addresses are being called by a CALL instruction and compares them
to the Address_Of_HHH parameter.

COUNTER FACTUAL Decide_Halting is not even called.

Not at all. Decide_Halting is called from HHH and called
from HHH1.

I know that and my above remarks do not contradict it whatsoever.
What are you talkin gbout?

see above.

Do you not know that you have a parameter called Address_Of_H
(or something very similar) in your own code?

Not the code that is being used.

When HHH1 calls Decide_Halting, that parameter points to HHH1;
When HHH calls it, the parameter points to HHH.

Those don't ever exist in HHH and HHH1 https://github.com/plolcott/x86utm/blob/master/Halt7.c

if (Decide_Halting_HH(&Aborted, &execution_trace, &decoded,
code_end, End_Of_Code, &master_state,
&slave_state, &slave_stack, Root))
goto END_OF_CODE;

Thus HHH and HHH1 are different deciders. Each one looks for evidence of itself in recursive simulation, and treats the other as an ordinary
function.

Pure functions cannot be looking at the name/address of their caller.

Can you now see that their is no actual bug causing
the difference in behavior of DD simulated by HHH
and DD simulated by HHH1?

I can see that the difference isn't a bug if you actually intend for
those functions to be different.

But, you cannot disprove the Halting Proof using two deciders.

DD simulated by HHH1 has the same behavior as DD()
DD simulated by HHH has different behavior.

HHH is supposed to report on the behavior that it
does see and not supposed to report on the behavior
that it does not see.

The Halting Proof doesn't say that the diagonal DD case, built on a
decider HHH, cannot be resolved by a different decider HHH1.

The only way HHH and HHH1 could be relevant to the Halting Proof is if
you intend for them to be understood as the same function; (but then
being mistaken due to them not actually being the same).

So it's a "head scratcher" as to where you are going with this, if you
know the functions are different and intend that.

I already just addressed this.
--
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 2025-09-06, Richard Damon <Richard@Damon-Family.org> wrote:

On 9/6/25 3:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:
But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

He claims it, and then admits that they are not, but that it doesn't matter. >
Actually, they are fundamentally impure, as there algorithm is based on
an impurity, they access the address that they are at, information that
is NOT provided to them as an input.

We can imagine a framework in which function work with names/addresses
yet are pure.

(However, that would confuse Olcotto even more; he doesn't have a
grip on run-of-the mill pure functions; and secondly, it is not
fully realizable.)

When a function refers to a name/address as an operand indicating
function identity, essentially, that is a kind of constant.
Sof or instance

fun x() { return x }

fun y() { return y }

We can regard these as pure functions denoting different constants.
The call x() produces x, and y() produces y.

They are similar functions in that we can convert one to the other just
with a renaming. Since they return different constants, they are not
the same.

The problem is that the following two functions /are/ the same:
the are the same function known by different names:

fun y() { return y }

fun z() { return y }

We cannot conclude that z is not y because z != y. When comparing
these function symbols, we need:

compare_function(x, y) -> false
compare_function(z, y) -> true

No algorithm exists for this; determining function equivalence runs into
the undecidability of halting.

If we substitute naive symbol/pointer equality for compare_function,
then the impurity arises: an inappropriately used low-level
implementation concept has destroyed the abstraction.:

x == y -> false
z == y -> false

I mean, functions are just values; just because we are juggling those
values doesn't mean we have impurity. If we pass functions around by name/pointer, but do not do anythinng with them other than call them to
evoke the computation that they represent, then we are okay.

But when we start asking the question: are these two functions the same?
And instead of using compare_function, we substitute an inappropriate
low-level operator that is concerned with impelmentation details that
are not part of the functional abstraction. That's the impurity.

So anyway, Olcott's idea of deciding halting by making use of
function equality is bunk, because function equality involves a
decision as difficult as halting.

Deciding halting by relying on an operator that is as difficult as
halting is a form of begging the question.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 3:51 PM, Kaz Kylheku wrote:

On 2025-09-06, Richard Damon <Richard@Damon-Family.org> wrote:

On 9/6/25 3:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:
But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

He claims it, and then admits that they are not, but that it doesn't matter. >
Actually, they are fundamentally impure, as there algorithm is based on
an impurity, they access the address that they are at, information that
is NOT provided to them as an input.

We can imagine a framework in which function work with names/addresses
yet are pure.

(However, that would confuse Olcotto even more; he doesn't have a
grip on run-of-the mill pure functions; and secondly, it is not
fully realizable.)

I have investigated pure functions very thoroughly
for several years. Most computer science people
do not understand that mapping between pure functions
written in C and functions computed by Turing machines.

Pure functions are as simple as this. https://en.wikipedia.org/wiki/Pure_function

Richard Heathfield's idea of making HHH into a parser
would make it into a pure function. I would have to
extend his idea and translate the parsed C functions
into a directed graph of control flow. A cycle in this
directed graph would prove my point.
--
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 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 2:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be different, >>>> so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

I had forgotten that HHH is not a pure function
until you first mentioned this recently.

That's a pretty important thing to forget.

It tends to points to cognitive decline, I'm afraid.

Richard Heathfield's recent idea of defining HHH
as a parser seems to be the best alternative.

I have written the parser for C "if" statements
that generates jump-code for expressions of
arbitrary complexity and "if" statements of arbitrary
nesting depth using YACC and LEX, so this should
be easy.

This kind of work is a waste of time, especially if the purpose is
exploring theory rather than providing some piece of tooling to people
who expect a certain syntax.

In a dialect of the Lisp language, you can do all the above
as an afternoon exercise.

Famously, a Lisp interpreter can be written in a page of Lisp, without
having to write any lexer or parser.

If you're exploring towers of nested interpreters, that is your
playground.

DD calls HHH(DD) in recursive simulation
THIS CHANGES THE BEHAVIOR OF DD

Sure, but that's not exactly allowed, so as far as meting the
requirements for being able to arguing aginst the Halting Theorem, a DD
that changes behavior is a bug.

You not accepting the requirements, and therefore not seeing a bug,
doesn't make the requirements go away.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 2:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be different, >>>>> so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

I had forgotten that HHH is not a pure function
until you first mentioned this recently.

That's a pretty important thing to forget.

When not one of many many dozens of people could
understand that DD correctly simulated by any HHH
cannot possibly reach its own simulated "return"
statement in several years, not a being a pure
function is as little as a mere implementation detail.

(1) That a correct *RETURN VALUE* exists by itself
is brand new. Notice that I said *RETURN VALUE*.
This is not the same as every TM halts or fails to
halt. This is a return value from the halting
problem's decider to its pathological input.

(2) That this correct *RETURN VALUE* is reject
is much farther than anyone else has ever gotten.

(3) How to implement HHH as a pure function is
mere implementation details unless impossible.

Your gross disrespect is ignored.
--
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 9/6/2025 5:42 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 2:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be different, >>>>> so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

I had forgotten that HHH is not a pure function
until you first mentioned this recently.

That's a pretty important thing to forget.

It tends to points to cognitive decline, I'm afraid.

Richard Heathfield's recent idea of defining HHH
as a parser seems to be the best alternative.

I have written the parser for C "if" statements
that generates jump-code for expressions of
arbitrary complexity and "if" statements of arbitrary
nesting depth using YACC and LEX, so this should
be easy.

This kind of work is a waste of time, especially if the purpose is
exploring theory rather than providing some piece of tooling to people
who expect a certain syntax.

In a dialect of the Lisp language, you can do all the above
as an afternoon exercise.

Famously, a Lisp interpreter can be written in a page of Lisp, without
having to write any lexer or parser.

If you're exploring towers of nested interpreters, that is your
playground.

DD calls HHH(DD) in recursive simulation
THIS CHANGES THE BEHAVIOR OF DD

Sure, but that's not exactly allowed,

Its not allowed for HHH. It is allowed for
DD. DD could merely repeat the F-word 100
times. In the case DD would not represent a TM
that halts.
--
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 9/6/2025 5:42 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 2:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be different, >>>>> so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

I had forgotten that HHH is not a pure function
until you first mentioned this recently.

That's a pretty important thing to forget.

It tends to points to cognitive decline, I'm afraid.

Richard Heathfield's recent idea of defining HHH
as a parser seems to be the best alternative.

I have written the parser for C "if" statements
that generates jump-code for expressions of
arbitrary complexity and "if" statements of arbitrary
nesting depth using YACC and LEX, so this should
be easy.

This kind of work is a waste of time, especially if the purpose is
exploring theory rather than providing some piece of tooling to people
who expect a certain syntax.

In a dialect of the Lisp language, you can do all the above
as an afternoon exercise.

Famously, a Lisp interpreter can be written in a page of Lisp, without
having to write any lexer or parser.

If you're exploring towers of nested interpreters, that is your
playground.

DD calls HHH(DD) in recursive simulation
THIS CHANGES THE BEHAVIOR OF DD

Sure, but that's not exactly allowed, so as far as meting the
requirements for being able to arguing aginst the Halting Theorem, a DD
that changes behavior is a bug.

You not accepting the requirements, and therefore not seeing a bug,
doesn't make the requirements go away.

Machine M contains simulating halt decider H based on a UTM
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state

*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩

IT *IS* THE CASE THAT THE INPUT TO M.H ⟨M⟩ ⟨M⟩
DOES SPECIFY BEHAVIOR THAT CANNOT POSSIBLY
REACH ITS OWN SIMULATED FINAL HALT STATE OF ⟨M.qn⟩

That you don't want to bother to pay attention
to this is no actual rebuttal WHAT-SO-EVER.
--
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 9/6/2025 7:10 PM, olcott wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

I had forgotten that HHH is not a pure function
until you first mentioned this recently.

That's a pretty important thing to forget.

When not one of many many dozens of people could
understand that DD correctly simulated by any HHH
cannot possibly reach its own simulated "return"
statement in several years, not a being a pure
function

DISQUALIFIES it from being a halt decider / termination analyzer, so
it's dead before it even starts.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 2:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55 push ebp
[00002184] 8bec mov ebp,esp
[00002186] 6883210000 push 00002183 ; push DDD
[0000218b] e833f4ffff call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404 add esp,+04
[00002193] 5d pop ebp
[00002194] c3 ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55 push ebp
[000021a4] 8bec mov ebp,esp
[000021a6] 6883210000 push 00002183 ; push DDD
[000021ab] e843f3ffff call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be different, >>>>>> so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

I had forgotten that HHH is not a pure function
until you first mentioned this recently.

That's a pretty important thing to forget.

When not one of many many dozens of people could
understand that DD correctly simulated by any HHH
cannot possibly reach its own simulated "return"
statement in several years, not a being a pure

This is false; simulations that use the Decide_Halting machinery to stop simulating are able to give rise to a terminating DD.

You simply don't understand your own shit.

function is as little as a mere implementation detail.

It's a required detail, and it is not implementable
such that all your funny results persist.

(1) That a correct *RETURN VALUE* exists by itself
is brand new.

The observation that for every Turing Machine there
is a correct halting decision is not new at all.

New *to you* is not new.
t least Turing.

(3) How to implement HHH as a pure function is
mere implementation details unless impossible.

Door #2, Monty.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 9:49 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

When not one of many many dozens of people could
understand that DD correctly simulated by any HHH
cannot possibly reach its own simulated "return"
statement in several years, not a being a pure

This is false; simulations that use the Decide_Halting machinery to stop simulating are able to give rise to a terminating DD.

I think that issue here might be that you still don't
understand the difference between stopping running
and reaching a final halt state.
--
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 2025-09-07, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 9:49 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

When not one of many many dozens of people could
understand that DD correctly simulated by any HHH
cannot possibly reach its own simulated "return"
statement in several years, not a being a pure

This is false; simulations that use the Decide_Halting machinery to stop
simulating are able to give rise to a terminating DD.

I think that issue here might be that you still don't
understand the difference between stopping running
and reaching a final halt state.

No, it's because /you/ don't understand that difference that you are
blind to the fact that DD can terminate inside an infinitely recursive simulation.

Even though you stop the simulation of DD when an infinitelly recursive
patern is detected (like three PUSH instructions preceding a HHH call or whatever bullshit) DD is halting.

You believe that stopping the simulation of DD makes is non-halting.

Or, well, you half-understand the difference.

You know that aborting the simulation is not the same as what
is inside that simulation halting. You've articulated that
more than once. That is well and good.

What you're missing is the flipside: aborting the simulation
is also not the same thing as what is inside the simulation
*not* halting.

In other words, the correct version of your remark which tells
the complete truth is this: aborting the simulation is not related to
*whether or not* the simulated machine halts.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 10:36 PM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 9:49 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

When not one of many many dozens of people could
understand that DD correctly simulated by any HHH
cannot possibly reach its own simulated "return"
statement in several years, not a being a pure

This is false; simulations that use the Decide_Halting machinery to stop >>> simulating are able to give rise to a terminating DD.

I think that issue here might be that you still don't
understand the difference between stopping running
and reaching a final halt state.

No, it's because /you/ don't understand that difference that you are
blind to the fact that DD can terminate inside an infinitely recursive simulation.

Even though you stop the simulation of DD when an infinitelly recursive patern is detected (like three PUSH instructions preceding a HHH call or whatever bullshit) DD is halting.

You believe that stopping the simulation of DD makes is non-halting.

Or, well, you half-understand the difference.

You know that aborting the simulation is not the same as what
is inside that simulation halting. You've articulated that
more than once. That is well and good.

What you're missing is the flipside: aborting the simulation
is also not the same thing as what is inside the simulation
*not* halting.

In other words, the correct version of your remark which tells
the complete truth is this: aborting the simulation is not related to *whether or not* the simulated machine halts.

So like I said you conflate termination with
reaching a final halt state. They are not the same.
--
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 9/6/2025 10:36 PM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 9:49 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

When not one of many many dozens of people could
understand that DD correctly simulated by any HHH
cannot possibly reach its own simulated "return"
statement in several years, not a being a pure

This is false; simulations that use the Decide_Halting machinery to stop >>> simulating are able to give rise to a terminating DD.

I think that issue here might be that you still don't
understand the difference between stopping running
and reaching a final halt state.

No, it's because /you/ don't understand that difference that you are
blind to the fact that DD can terminate inside an infinitely recursive simulation.

So like I said you conflate termination with
reaching a final halt state. They are not the same.
--
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 07/09/2025 04:41, olcott wrote:

On 9/6/2025 10:36 PM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 9:49 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

When not one of many many dozens of people could
understand that DD correctly simulated by any HHH
cannot possibly reach its own simulated "return"
statement in several years, not a being a pure

This is false; simulations that use the Decide_Halting
machinery to stop
simulating are able to give rise to a terminating DD.

I think that issue here might be that you still don't
understand the difference between stopping running
and reaching a final halt state.

No, it's because /you/ don't understand that difference that
you are
blind to the fact that DD can terminate inside an infinitely
recursive
simulation.

Even though you stop the simulation of DD when an infinitelly
recursive
patern is detected (like three PUSH instructions preceding a
HHH call or
whatever bullshit) DD is halting.

You believe that stopping the simulation of DD makes is non-
halting.

Or, well, you half-understand the difference.

You know that aborting the simulation is not the same as what
is inside that simulation halting. You've articulated that
more than once. That is well and good.

What you're missing is the flipside: aborting the simulation
is also not the same thing as what is inside the simulation
*not* halting.

In other words, the correct version of your remark which tells
the complete truth is this: aborting the simulation is not
related to
*whether or not* the simulated machine halts.

So like I said you conflate termination with
reaching a final halt state. They are not the same.

He just drew a very careful distinction: "aborting the simulation
is not related to *whether or not* the simulated machine halts."

In fact we can draw up a table:

+-------------+------------+-------------------+
| | HHH aborts | HHH doesn't abort | +-------------+------------+-------------------+
| HHH accepts | DD loops | DD loops | +-------------+------------+-------------------+
| HHH rejects | DD halts | DD halts | +-------------+------------+-------------------+

The only way aborting can equate to termination is if aborting is
linked directly to the decision HHH makes. Whether HHH aborts or
not may affect HHH's decision, but as the table shows, aborting
doesn't do anything to stop HHH from getting the decision wrong.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

I do understand that you would like to be able to call a machine that
reaches its final halt state non-terminating, because it suits certain narratives of yours revolving around your unsubstantiated opinions,
but there is no logical basis for that.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 07/09/2025 06:49, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

Well, but there is. We know that DD terminates, right? We've all
seen it.

But Olcott's genius lies in removing the "final halt state".

Let's take a closer look at the source:

int DD()
{
int Halt_Status = HHH(DD);

This is the only part of DD that Olcott's simulator acknowledges.
It doesn't /have/ a final halt state, and therefore DD can't
reach it.

Since DD clearly terminates but never reaches a final halt state
that it just doesn't have, termination and reaching the final
halt state can't possibly be the same thi
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Sat, 06 Sep 2025 18:10:07 -0500 schrieb olcott:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 2:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

This call kicks a simulation with Adddress_Of_HH = HHH.

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be
different, so of course you get different traces.

HHH and HHH1 are at different machine addresses so that DD does call >>>>> HHH(DD) in recursive simulation and DD does not call HHH1(DD) at
all. I have said that thousands of times in the last three years AND >>>>> NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions and (2)
identical functions, are you not?

I had forgotten that HHH is not a pure function until you first
mentioned this recently.

That's a pretty important thing to forget.

When not one of many many dozens of people could understand that DD
correctly simulated by any HHH cannot possibly reach its own simulated "return" statement in several years, not a being a pure function is as
little as a mere implementation detail.

(1) That a correct *RETURN VALUE* exists by itself is brand new. Notice
that I said *RETURN VALUE*.
This is not the same as every TM halts or fails to halt. This is a
return value from the halting problem's decider to its pathological
input.
(2) That this correct *RETURN VALUE* is reject is much farther than
anyone else has ever gotten.
(3) How to implement HHH as a pure function is mere implementation
details unless impossible.

I think we all understand that HHH cannot simulate itself to completion.
The correct return value is the opposite of what is returned.
It is impossible for HHH to be pure.
--
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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/25 11:45 PM, olcott wrote:

On 9/6/2025 10:36 PM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 9:49 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

When not one of many many dozens of people could
understand that DD correctly simulated by any HHH
cannot possibly reach its own simulated "return"
statement in several years, not a being a pure

This is false; simulations that use the Decide_Halting machinery to
stop
simulating are able to give rise to a terminating DD.

I think that issue here might be that you still don't
understand the difference between stopping running
and reaching a final halt state.

No, it's because /you/ don't understand that difference that you are
blind to the fact that DD can terminate inside an infinitely recursive
simulation.

So like I said you conflate termination with
reaching a final halt state. They are not the same.

But you CAN'T "terminate" the actual behavior of a program, as BY
DEFINITION, it is the undistrubed operation of it.

The aborting of the simulation by HHH doesn't stop its behavior, and
since when HHH(DD) returns 0, that DD, when simulated to completion will
reach its final halt state in finite steps, is halting, and thus HHH is
just wrong.

This happens whether it is HHH or HHH1 doing the simulation, as "correct simulation" is an OBJECTIVE measure, not stopped by HHHs erroneous
aborting, thus showing that HHH just gets the wrong answer.

The problem is you don't understand that in any one case, HHH is just a
single version of your set, as you can't put "an infinite set" of them
into a machine at once, thus your logic is based on a stupid category error. --- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 12:19 AM, Richard Heathfield wrote:

On 07/09/2025 04:41, olcott wrote:>>

So like I said you conflate termination with
reaching a final halt state. They are not the same.

He just drew a very careful distinction: "aborting the simulation is not related to *whether or not* the simulated machine halts."

That is not quite even the correct question.

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

In fact we can draw up a table:

+-------------+------------+-------------------+
|             | HHH aborts | HHH doesn't abort | +-------------+------------+-------------------+
| HHH accepts |  DD loops  |    DD loops       | +-------------+------------+-------------------+
| HHH rejects |  DD halts  |    DD halts       | +-------------+------------+-------------------+

The only way aborting can equate to termination is if aborting is linked directly to the decision HHH makes. Whether HHH aborts or not may affect HHH's decision, but as the table shows, aborting doesn't do anything to
stop HHH from getting the decision wrong.

--
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 07/09/2025 14:31, olcott wrote:

On 9/7/2025 12:19 AM, Richard Heathfield wrote:

On 07/09/2025 04:41, olcott wrote:>>

So like I said you conflate termination with
reaching a final halt state. They are not the same.

He just drew a very careful distinction: "aborting the
simulation is not related to *whether or not* the simulated
machine halts."

That is not quite even the correct question.

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

That's a question about emulation. You are fully within your
rights to ask it, but it isn't a very interesting question, and
it isn't the question the Halting Problem poses.

The question that the Halting Problem poses (and that Turing has
answered) is whether a universal decider can be written.

Answer: no. (We have a proof.)

Does DD halt? Yes. Run it and see.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 12:49 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

It can be defined that way, or it can be defined
that when the simulated input is aborted then this
simulated machine stops running and terminates.

I do understand that you would like to be able to call a machine that
reaches its final halt state non-terminating,

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

because it suits certain
narratives of yours revolving around your unsubstantiated opinions,
but there is no logical basis for that.

All deciders only report on the syntactic or
semantic property specified by their input
finite string.

This is very much related to Rice's Theorem.

The *ACTUAL INPUT* to HHH(DD) *ACTUALLY SPECIFIES*
the semantic property of recursive simulation that
cannot possibly reach the simulated final halt state.
--
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

Am Sun, 07 Sep 2025 09:31:00 -0500 schrieb olcott:

On 9/7/2025 12:49 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with reaching a final halt
state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

It can be defined that way, or it can be defined that when the simulated input is aborted then this simulated machine stops running and
terminates.

That's too easy. Then every machine would be halting.

I do understand that you would like to be able to call a machine that
reaches its final halt state non-terminating,

because it suits certain narratives of yours revolving around your
unsubstantiated opinions, but there is no logical basis for that.

All deciders only report on the syntactic or semantic property specified
by their input finite string.
This is very much related to Rice's Theorem.
The *ACTUAL INPUT* to HHH(DD) *ACTUALLY SPECIFIES* the semantic property
of recursive simulation that cannot possibly reach the simulated final
halt state.

Nah, it's not related. The code of DD that is the input to HHH does
not specify that whatever simulates DD should simulate a call to itself.
It specifies that DD calls HHH. If you choose to simulate DD with HHH,
then that is recursive, but DD by itself doesn't specify that. (Well,
it does, but one level further down.)
--
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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

On 9/7/2025 12:49 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

It can be defined that way, or it can be defined

It is not defined in any other way.

that when the simulated input is aborted then this
simulated machine stops running and terminates.

Rather, you are conflating the simualTING mafchine with the simulatED
machine.

The simulating machine deciding to stop (and return zero, for instance)
does not determine the halting status of the simulated machine.

I do understand that you would like to be able to call a machine that
reaches its final halt state non-terminating,

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

The answer is yes, such a simulating HHH can be found; for instance a
HHH that launches a thread to complete the rest of the simulation of DD,
and then returns 0. Returning 0 causes DD to be terminating, and the
thread will demonstrate it by completing the simulation right through
DD's ret instruction, and reporting that fact on the console output.

I don't know what you mean by "correct question"; any question
that is well-formed and makes sense is a good question.

The above question does not coincide with any question posed under the umbrellal of the Halting Problem; it is not a pertinent question.

because it suits certain
narratives of yours revolving around your unsubstantiated opinions,
but there is no logical basis for that.

All deciders only report on the syntactic or
semantic property specified by their input
finite string.

Ah, speaking of which; I asked you to completely identify everything
that you believe comprises that input string; the full bill of
materials.

This is very much related to Rice's Theorem.

The *ACTUAL INPUT* to HHH(DD) *ACTUALLY SPECIFIES*
the semantic property of recursive simulation that
cannot possibly reach the simulated final halt state.

OK, but you distinuish "reach simulated final halt state" from
"terminate", so you are not saying "cannot possibly terminate".

As a halting decider, HHH(DD) is being asked whether DD terminates, not
whether or not HHH(DD) pulls the plug on the simulation of DD before DD
is stepped to a ret instrution. By returning 0, HHH(DD) is giving
an answer to an impertinent question that is not being asked.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-07, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 07/09/2025 06:49, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

Well, but there is. We know that DD terminates, right? We've all
seen it.

But Olcott's genius lies in removing the "final halt state".

Just pull the plug on the terminal patient and that proves
they are immortal.

The actual life-supported patient that was input to the hospital
never reaches his terminal breath.

Those who continue to ignore what I'm saying are too ignorant
to begin understanding "dying" and "reaching the terminal breath while
on life support" are not the same, in spite of me repeating
it thousands of times for three years.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-07, joes <noreply@example.org> wrote:

I think we all understand that HHH cannot simulate itself to completion.

When he has it returning 0, HHH itself is obviously completing.
It doesn't simulate its input to completion.

But it can, and Peter Olcott might even have the software skills to
pull that off within his apparatus.

The problem is he would never code anything that disagrees with his
narrative. He's looking for ways to confirm he is right, rather
than, like a proper scientist, looking for for ways he might be wrong.

HHH can return the 0 value that causes the simulation to be
terminatng, and just before returning 0, farm out the completion
of the simulation to an asynchronous thread which will demonstrate
that DD terminates.

The correct return value is the opposite of what is returned.
It is impossible for HHH to be pure.

It is certainly possible for HHH to be pure. For instance, it
can step thorugh some set number of instrutions of its input,
and then unconditionally return 0. Then all the impure crap
about comparing function addresses is gone. We still have
a terminating DD, and an incorrect 0 return value as before,
yet HHH is pure. We can also show that the abandoned simulation
of DD is one of a terminating function call.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

DD calls HHH(DD) in recursive simulation
THIS CHANGES THE BEHAVIOR OF DD

Sure, but that's not exactly allowed,

Its not allowed for HHH. It is allowed for
DD.

Again, you are forgetting that HHH is built almost entirely out of DD.

The change in behavior of DD is the result of HHH changing is
behavior, which you are now admitting is not allowed.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

On 9/7/2025 12:19 AM, Richard Heathfield wrote:

On 07/09/2025 04:41, olcott wrote:>>

So like I said you conflate termination with
reaching a final halt state. They are not the same.

He just drew a very careful distinction: "aborting the simulation is
not related to *whether or not* the simulated machine halts."

That is not quite even the correct question.

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

Which since that ISN'T the Halting Quesiton, just shows that you have
been lying and trying to push your POOP onto people as the Halting Problem.

Halting is DEFINED as the behaivor of the PROGRAM the input represents.

Any other criteria is just a LIE.

Your claim that it can't mean that just shows you don't undertstand what "semantics" actually are.

In fact we can draw up a table:

+-------------+------------+-------------------+
|             | HHH aborts | HHH doesn't abort |
+-------------+------------+-------------------+
| HHH accepts |  DD loops  |    DD loops       |
+-------------+------------+-------------------+
| HHH rejects |  DD halts  |    DD halts       |
+-------------+------------+-------------------+

The only way aborting can equate to termination is if aborting is
linked directly to the decision HHH makes. Whether HHH aborts or not
may affect HHH's decision, but as the table shows, aborting doesn't do
anything to stop HHH from getting the decision wrong.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 8:06 AM, Kaz Kylheku wrote:

On 2025-09-07, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 07/09/2025 06:49, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

Well, but there is. We know that DD terminates, right? We've all
seen it.

But Olcott's genius lies in removing the "final halt state".

Just pull the plug on the terminal patient and that proves
they are immortal.

Yikes!

Chop off runners legs and say see, it halted. Or is that on the flip
side? The "zombie" runner continues on? So, non halting?

Chop off runners legs and say see, he would not have halted. The runner
with no legs said I could run forever you ass! You cut my fucking legs off!

Humm...

The actual life-supported patient that was input to the hospital
never reaches his terminal breath.

Those who continue to ignore what I'm saying are too ignorant
to begin understanding "dying" and "reaching the terminal breath while
on life support" are not the same, in spite of me repeating
it thousands of times for three years.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 2:28 PM, Chris M. Thomasson wrote:

On 9/7/2025 8:06 AM, Kaz Kylheku wrote:

On 2025-09-07, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 07/09/2025 06:49, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state" >>>> and that machine terminating.

Well, but there is. We know that DD terminates, right? We've all
seen it.

But Olcott's genius lies in removing the "final halt state".

Just pull the plug on the terminal patient and that proves
they are immortal.

Yikes!

Chop off runners legs and say see, it halted. Or is that on the flip
side? The "zombie" runner continues on? So, non halting?

Chop off runners legs and say see, he would not have halted. The runner
with no legs said I could run forever you ass! You cut my fucking legs off!

Humm...

Or, the runner could have said, well, I would have rested, ate
something, drink water, then start running again for a while... But this simulator cut my damn legs off. olcott reasoning is odd to me. He thinks
he solved the halting program or not? Thinks he found a flaw? Shit man.

Or is it more like this: The runner could say I was going to halt up the road... But my damn legs got cut off before I could get there, and the
bastard says I am non-halting? Humm...

The actual life-supported patient that was input to the hospital
never reaches his terminal breath.

Those who continue to ignore what I'm saying are too ignorant
to begin understanding "dying" and "reaching the terminal breath while
on life support" are not the same, in spite of me repeating
it thousands of times for three years.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 7:57 AM, joes wrote:

Am Sun, 07 Sep 2025 09:31:00 -0500 schrieb olcott:

On 9/7/2025 12:49 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with reaching a final halt
state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

It can be defined that way, or it can be defined that when the simulated
input is aborted then this simulated machine stops running and
terminates.

That's too easy. Then every machine would be halting.

I think that what he might mean. As a potential ultrafinite, he thinks
they all halt?

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 4:13 PM, olcott wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 2:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55             push ebp
[00002184] 8bec           mov ebp,esp
[00002186] 6883210000     push 00002183 ; push DDD
[0000218b] e833f4ffff     call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404         add esp,+04
[00002193] 5d             pop ebp
[00002194] c3             ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55             push ebp
[000021a4] 8bec           mov ebp,esp
[000021a6] 6883210000     push 00002183 ; push DDD
[000021ab] e843f3ffff     call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be
different,
so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

I had forgotten that HHH is not a pure function
until you first mentioned this recently.

That's a pretty important thing to forget.

It tends to points to cognitive decline, I'm afraid.

Richard Heathfield's recent idea of defining HHH
as a parser seems to be the best alternative.

I have written the parser for C "if" statements
that generates jump-code for expressions of
arbitrary complexity and "if" statements of arbitrary
nesting depth using YACC and LEX, so this should
be easy.

This kind of work is a waste of time, especially if the purpose is
exploring theory rather than providing some piece of tooling to people
who expect a certain syntax.

In a dialect of the Lisp language, you can do all the above
as an afternoon exercise.

Famously, a Lisp interpreter can be written in a page of Lisp, without
having to write any lexer or parser.

If you're exploring towers of nested interpreters, that is your
playground.

DD calls HHH(DD) in recursive simulation
THIS CHANGES THE BEHAVIOR OF DD

Sure, but that's not exactly allowed,

Its not allowed for HHH. It is allowed for
DD. DD could merely repeat the F-word 100
times. In the case DD would not represent a TM
that halts.

Huh? DD prints the F-word 100 times, then does what? Halts? Your decider should report halt. If it printed the F-word infinite times, then your
decider can say does not halt. lol.

10 PRINT "Infinite... " : GOTO 10


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-06 14:32:41 +0000, olcott said:

On 9/6/2025 3:56 AM, Mikko wrote:

On 2025-09-05 15:29:57 +0000, olcott said:

HHH and HHH1 have identical source code except
for their name. The DDD of HHH1(DDD) has identical
behavior to the directly executed DDD().

DDD calls HHH(DDD) in recursive emulation. DDD does
not call HHH1 at all. This is why the behavior
of DDD.HHH1 is different than the behavior of DDD.HHH

_DDD()
[00002183] 55             push ebp
[00002184] 8bec           mov ebp,esp
[00002186] 6883210000     push 00002183 ; push DDD
[0000218b] e833f4ffff     call 000015c3 ; call HHH
[00002190] 83c404         add esp,+04
[00002193] 5d             pop ebp
[00002194] c3             ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55             push ebp
[000021a4] 8bec           mov ebp,esp
[000021a6] 6883210000     push 00002183 ; push DDD
[000021ab] e843f3ffff     call 000014f3 ; call HHH1
[000021b0] 83c404         add esp,+04
[000021b3] 33c0           xor eax,eax
[000021b5] 5d             pop ebp
[000021b6] c3             ret
Size in bytes:(0020) [000021b6]

  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  ========== =============
[000021a3][0010382d][00000000] 55         push ebp      ; main()
[000021a4][0010382d][00000000] 8bec       mov ebp,esp   ; main() >>> [000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD
[000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1

Begin Local Halt Decider Simulation   Execution Trace Stored at:1138d9 >>> [00002183][001138c9][001138cd] 55         push ebp      ; DDD of HHH1
[00002184][001138c9][001138cd] 8bec       mov ebp,esp   ; DDD of HHH1
[00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9

Begin Local Halt Decider Simulation   Execution Trace Stored at:15e301 >>> [00002183][0015e2f1][0015e2f5] 55         push ebp      ; DDD of HHH[0]
[00002184][0015e2f1][0015e2f5] 8bec       mov ebp,esp   ; DDD of HHH[0]
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:198d21

*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*

[00002183][001a8d19][001a8d1d] 55         push ebp      ; DDD of HHH[1]
[00002184][001a8d19][001a8d1d] 8bec       mov ebp,esp   ; DDD of HHH[1]
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[00002190][001138c9][001138cd] 83c404     add esp,+04 ; DDD of HHH1
[00002193][001138cd][000015a8] 5d         pop ebp     ; DDD of HHH1
[00002194][001138d1][0003a980] c3         ret         ; DDD of HHH1
[000021b0][0010382d][00000000] 83c404     add esp,+04 ; main()
[000021b3][0010382d][00000000] 33c0       xor eax,eax ; main()
[000021b5][00103831][00000018] 5d         pop ebp     ; main() >>> [000021b6][00103835][00000000] c3         ret         ; main()
Number of Instructions Executed(352831) == 5266 Pages

That the behaviour or HHH(DDD) is different from the bahavour of
HHH1(DDD) is irrelevant to the question whether DDD halts.

"correctly emulated" means emulating according to the
semantics of the x86 language.

Irrelevant when the expression "correctly emulated" is not used.
Also irrelevant to the question where DDD halts.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 8:39 AM, Richard Heathfield wrote:

On 07/09/2025 14:31, olcott wrote:

On 9/7/2025 12:19 AM, Richard Heathfield wrote:

On 07/09/2025 04:41, olcott wrote:>>

So like I said you conflate termination with
reaching a final halt state. They are not the same.

He just drew a very careful distinction: "aborting the simulation is
not related to *whether or not* the simulated machine halts."

That is not quite even the correct question.

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

That's a question about emulation. You are fully within your rights to
ask it, but it isn't a very interesting question, and it isn't the
question the Halting Problem poses.

The question that the Halting Problem poses (and that Turing has
answered) is whether a universal decider can be written.

All deciders only decide on the basis of the semantic
or syntactic property of their input. This is related
Rice's theorem.

When we ask that question we obtain the relevant
semantic property of *THE ACTUAL INPUT*.

Not doing it this way has been the mistake of
every proof since 1936.

Answer: no. (We have a proof.)

Does DD halt? Yes. Run it and see.

--
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 9/8/2025 11:06 AM, olcott wrote:

On 9/7/2025 8:39 AM, Richard Heathfield wrote:

On 07/09/2025 14:31, olcott wrote:

On 9/7/2025 12:19 AM, Richard Heathfield wrote:

On 07/09/2025 04:41, olcott wrote:>>

So like I said you conflate termination with
reaching a final halt state. They are not the same.

He just drew a very careful distinction: "aborting the simulation is
not related to *whether or not* the simulated machine halts."

That is not quite even the correct question.

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

That's a question about emulation. You are fully within your rights to
ask it, but it isn't a very interesting question, and it isn't the
question the Halting Problem poses.

The question that the Halting Problem poses (and that Turing has
answered) is whether a universal decider can be written.

All deciders only decide on the basis of the semantic
or syntactic property of their input. This is related
Rice's theorem.

And the semantic property of finite string DD is that of algorithm DD consisting of the fixed immutable code of the function DD, the function
HHH, and everything that HHH calls down to the OS level.

That algorithm halts, so the semantic property of finite string DD to be reported on is that of algorithm DD which halts.

When we ask that question we obtain the relevant
semantic property of *THE ACTUAL INPUT*.

i.e. finite string DD whose semantic property is that of algorithm DD
which halts.

Not doing it this way has been the mistake of
every proof since 1936.

Answer: no. (We have a proof.)

Does DD halt? Yes. Run it and see.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 08/09/2025 16:06, olcott wrote:

On 9/7/2025 8:39 AM, Richard Heathfield wrote:

On 07/09/2025 14:31, olcott wrote:

On 9/7/2025 12:19 AM, Richard Heathfield wrote:

On 07/09/2025 04:41, olcott wrote:>>

So like I said you conflate termination with
reaching a final halt state. They are not the same.

He just drew a very careful distinction: "aborting the
simulation is not related to *whether or not* the simulated
machine halts."

That is not quite even the correct question.

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

That's a question about emulation. You are fully within your
rights to ask it, but it isn't a very interesting question, and
it isn't the question the Halting Problem poses.

The question that the Halting Problem poses (and that Turing
has answered) is whether a universal decider can be written.

All deciders only decide on the basis of the semantic
or syntactic property of their input.

They decide on the basis of the program and input tape presented
to them. See Turing 1936. At no point does Turing mention
simulation or emulation.

Simulation is certainly a valid approach to the problem, but it
is not the only valid approach and it is not definitive. You
don't get to re-couch the problem in terms sympathetic to simulation.

This is related
Rice's theorem.

If you accept Rice's Theorem, you accept that the Halting Problem
is undecidable.

When we ask that question we obtain the relevant
semantic property of *THE ACTUAL INPUT*.

In your case, this:

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

Not just the first two lines and then sticking your head in the
sand to pretend that you can't see the rest.

Not doing it this way has been the mistake of
every proof since 1936.

Except that doing it your way produces the wrong answer.

Does DD halt? Yes. Run it and see.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

All deciders only decide on the basis of the semantic
or syntactic property of their input.

That means they must definitely not be peforming tests like, "is the
input executing an x86 CALL instruction whose target address points to
the decider?"
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On Mon, 08 Sep 2025 10:06:13 -0500, olcott wrote:

On 9/7/2025 8:39 AM, Richard Heathfield wrote:

On 07/09/2025 14:31, olcott wrote:

On 9/7/2025 12:19 AM, Richard Heathfield wrote:

On 07/09/2025 04:41, olcott wrote:>>

So like I said you conflate termination with reaching a final halt
state. They are not the same.

He just drew a very careful distinction: "aborting the simulation is
not related to *whether or not* the simulated machine halts."

That is not quite even the correct question.

*Here is the correct question*
Can DD emulated by any HHH according to the semantics of the x86
language possibly reach its own emulated "ret" instruction final halt
state?

That's a question about emulation. You are fully within your rights to
ask it, but it isn't a very interesting question, and it isn't the
question the Halting Problem poses.

The question that the Halting Problem poses (and that Turing has
answered) is whether a universal decider can be written.

All deciders only decide on the basis of the semantic or syntactic
property of their input. This is related Rice's theorem.

When we ask that question we obtain the relevant semantic property of
*THE ACTUAL INPUT*.

Not doing it this way has been the mistake of every proof since 1936.

The mistake is yours: HHH says DDD doesn't halt, DDD halts, ergo HHH is incorrect.

Pink is not a physical colour.

/Flibble
--
meet ever shorter deadlines, known as "beat the clock"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-08, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 08/09/2025 16:06, olcott wrote:

All deciders only decide on the basis of the semantic
or syntactic property of their input.

They decide on the basis of the program and input tape presented
to them. See Turing 1936. At no point does Turing mention
simulation or emulation.

Therefore it goes without saying that at no point does Turing mention
that the Turing machine may contain a reference to the machine which is simulating it, and the simulating machine may detect that reference.

Simulation is certainly a valid approach to the problem, but it
is not the only valid approach and it is not definitive. You
don't get to re-couch the problem in terms sympathetic to simulation.

You do, if you do it properly, such that your simulator is pure, and
doesn't look for itself in its input /by address/.

If a simulator is so inclined as to look for itself in its input, it
must do so by analyzing the structure of the input: it must detect that something in the input is a precise copy of itself.

And that is begging the question: because detecting equivalent
procedures is a difficulty equal to the halting problem! You can't
decide halting by deferring to an operation that itself has to decide
halting, and you don't have that procedure correctly implemented.

Olcott doesn't understand what it means for two functions to be the
same. His contraption contains a Decide_Halting function which relies on
an incorrect notion of function equivalence. You cannot use name or
pointer equivalence to detect whether two functions are identical, as
Olcott is doing.

It yields false negatives, because identical functions can exist
under different names/addresses.

int add1(int x, int y) { return x + y; }
int add2(int x, int y) { return x + y; }

add1 == add2 is not a correct test of "are these the same function",
because it yields a false negative.

Since the number of functions in Olcott's contraption is finite, they
can all be manually enumerated and partitioned into an equivalence
class. Then an accurate same_function(a, b) function can be written
which yields the correct ansewr for any pair of functions a and b
that exist in the apparatus. The function must be correctly maintained
whenever functions are added or changed.

When Olcott's Decide_Halting is modified to use
same_function(addr_from_opcode, Address_Of_H) then HHH and HHH1 will not
yield different results.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/8/2025 1:07 PM, Kaz Kylheku wrote:

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

All deciders only decide on the basis of the semantic
or syntactic property of their input.

That means they must definitely not be peforming tests like, "is the
input executing an x86 CALL instruction whose target address points to
the decider?"

That would definitely be a property of the input.
Whether or not this property is Turing computable
is a different issue.
--
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 9/8/2025 3:26 AM, Mikko wrote:

On 2025-09-06 14:32:41 +0000, olcott said:

On 9/6/2025 3:56 AM, Mikko wrote:

On 2025-09-05 15:29:57 +0000, olcott said:

HHH and HHH1 have identical source code except
for their name. The DDD of HHH1(DDD) has identical
behavior to the directly executed DDD().

DDD calls HHH(DDD) in recursive emulation. DDD does
not call HHH1 at all. This is why the behavior
of DDD.HHH1 is different than the behavior of DDD.HHH

_DDD()
[00002183] 55             push ebp
[00002184] 8bec           mov ebp,esp
[00002186] 6883210000     push 00002183 ; push DDD
[0000218b] e833f4ffff     call 000015c3 ; call HHH
[00002190] 83c404         add esp,+04
[00002193] 5d             pop ebp
[00002194] c3             ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55             push ebp
[000021a4] 8bec           mov ebp,esp
[000021a6] 6883210000     push 00002183 ; push DDD
[000021ab] e843f3ffff     call 000014f3 ; call HHH1
[000021b0] 83c404         add esp,+04
[000021b3] 33c0           xor eax,eax
[000021b5] 5d             pop ebp
[000021b6] c3             ret
Size in bytes:(0020) [000021b6]

  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  ========== =============
[000021a3][0010382d][00000000] 55         push ebp      ; main()
[000021a4][0010382d][00000000] 8bec       mov ebp,esp   ; main() >>>> [000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD
[000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1

Begin Local Halt Decider Simulation   Execution Trace Stored at:1138d9 >>>> [00002183][001138c9][001138cd] 55         push ebp      ; DDD of HHH1
[00002184][001138c9][001138cd] 8bec       mov ebp,esp   ; DDD of HHH1
[00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9

Begin Local Halt Decider Simulation   Execution Trace Stored at:15e301 >>>> [00002183][0015e2f1][0015e2f5] 55         push ebp      ; DDD of HHH[0]
[00002184][0015e2f1][0015e2f5] 8bec       mov ebp,esp   ; DDD of HHH[0]
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:198d21

*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*

[00002183][001a8d19][001a8d1d] 55         push ebp      ; DDD of HHH[1]
[00002184][001a8d19][001a8d1d] 8bec       mov ebp,esp   ; DDD of HHH[1]
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[00002190][001138c9][001138cd] 83c404     add esp,+04 ; DDD of HHH1 >>>> [00002193][001138cd][000015a8] 5d         pop ebp     ; DDD of HHH1
[00002194][001138d1][0003a980] c3         ret         ; DDD of HHH1
[000021b0][0010382d][00000000] 83c404     add esp,+04 ; main()
[000021b3][0010382d][00000000] 33c0       xor eax,eax ; main()
[000021b5][00103831][00000018] 5d         pop ebp     ; main() >>>> [000021b6][00103835][00000000] c3         ret         ; main()
Number of Instructions Executed(352831) == 5266 Pages

That the behaviour or HHH(DDD) is different from the bahavour of
HHH1(DDD) is irrelevant to the question whether DDD halts.

"correctly emulated" means emulating according to the
semantics of the x86 language.

Irrelevant when the expression "correctly emulated" is not used.
Also irrelevant to the question where DDD halts.

If we do not restrict this to correctly emulated
then some joker here might suggest "interpreting"
the instruction at address 00002183 to mean "jmp 00002194"
--
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 9/8/2025 7:23 PM, olcott wrote:

On 9/8/2025 1:07 PM, Kaz Kylheku wrote:

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

All deciders only decide on the basis of the semantic
or syntactic property of their input.

That means they must definitely not be peforming tests like, "is the
input executing an x86 CALL instruction whose target address points to
the decider?"

That would definitely be a property of the input.
Whether or not this property is Turing computable
is a different issue.

Another property of the input, the one we care about, is whether the
described algorithm reaches a final state when executed directly, or equivalently when simulated by UTM.

That property has been proven to not be computable by Turing and Linz,
and you have *explicitly* agreed that this is the case.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 10:22 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

DD calls HHH(DD) in recursive simulation
THIS CHANGES THE BEHAVIOR OF DD

Sure, but that's not exactly allowed,

Its not allowed for HHH. It is allowed for
DD.

Again, you are forgetting that HHH is built almost entirely out of DD.

The classic "do the opposite" Counter-example input
has always been anchored in the (semantically unsound)
Liar Paradox like structure.

The change in behavior of DD is the result of HHH changing is
behavior, which you are now admitting is not allowed.

--
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 9/7/2025 10:22 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

DD calls HHH(DD) in recursive simulation
THIS CHANGES THE BEHAVIOR OF DD

Sure, but that's not exactly allowed,

Its not allowed for HHH. It is allowed for
DD.

Again, you are forgetting that HHH is built almost entirely out of DD.

The change in behavior of DD is the result of HHH changing is
behavior, which you are now admitting is not allowed.

I never said it is not allowed.

I said that the current implementation detail
of the method that it uses to detect recursive
simulation is not a computable function.
--
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 08/09/2025 20:07, Kaz Kylheku wrote:

On 2025-09-08, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 08/09/2025 16:06, olcott wrote:

All deciders only decide on the basis of the semantic
or syntactic property of their input.

They decide on the basis of the program and input tape presented
to them. See Turing 1936. At no point does Turing mention
simulation or emulation.

Therefore it goes without saying that at no point does Turing mention
that the Turing machine may contain a reference to the machine which is simulating it, and the simulating machine may detect that reference.

Simulation is certainly a valid approach to the problem, but it
is not the only valid approach and it is not definitive. You
don't get to re-couch the problem in terms sympathetic to simulation.

You do, if you do it properly, such that your simulator is pure, and
doesn't look for itself in its input /by address/.

If a simulator is so inclined as to look for itself in its input, it
must do so by analyzing the structure of the input: it must detect that something in the input is a precise copy of itself.

And that is begging the question: because detecting equivalent
procedures is a difficulty equal to the halting problem! You can't
decide halting by deferring to an operation that itself has to decide halting, and you don't have that procedure correctly implemented.

Olcott doesn't understand what it means for two functions to be the
same. His contraption contains a Decide_Halting function which relies on
an incorrect notion of function equivalence. You cannot use name or
pointer equivalence to detect whether two functions are identical, as
Olcott is doing.

It yields false negatives, because identical functions can exist
under different names/addresses.

int add1(int x, int y) { return x + y; }
int add2(int x, int y) { return x + y; }

add1 == add2 is not a correct test of "are these the same function",
because it yields a false negative.

Since the number of functions in Olcott's contraption is finite, they
can all be manually enumerated and partitioned into an equivalence
class. Then an accurate same_function(a, b) function can be written
which yields the correct ansewr for any pair of functions a and b
that exist in the apparatus. The function must be correctly maintained whenever functions are added or changed.

When Olcott's Decide_Halting is modified to use same_function(addr_from_opcode, Address_Of_H) then HHH and HHH1 will not yield different results.

HHH/HHH1 do not use "their own addresses" in Decide_Halting. If they do in your halt7.c, what date
is that from? (My copy is from around July 2024).

If HHH/HHH1 were amended to eliminate the mutable static variables (e.g. for the static trace table)
and made so that all simulation levels of HHH have their own local trace table and behave
identically, then HHH/HHH1 would behave identically. (For what that's worth. So, we've made a
genuine clone of HHH; now what?)

I don't believe PO needs to or relies on reliably identifying when two functions (such as HHH/HHH1)
represent the same algorithm. What he /does/ need to do is recognise when the "physically same"
piece of code is /emulated/ at different points of an emulation, including across nested emulations
/of the same computation/. [Emulated TM code /does/ have an equivalent of instruction address,
namely the TM-description offset. And it doesn't matter if the same cloned function appears at
different TM-desc offsets - PO would be fine just treating them as distinct routines for his abort
tests.

But we're getting into delicate issues which in the end are dependent on what PO is trying to argue
and specifically /how/ he intends to relate any results he obtains on x86utm to results about TMs.
Since PO can't even recognise issues like that, it's probably not worth spending much time on this.
(Unless posters find such issues more interesting than refuting PO over and over...) There are
soooo many other more basic problems to pick on first if we're just refuting PO's claims - like HHH
decides DD never halts, when DD halts.


Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 10:14 AM, Kaz Kylheku wrote:

On 2025-09-07, joes <noreply@example.org> wrote:

I think we all understand that HHH cannot simulate itself to completion.

When he has it returning 0, HHH itself is obviously completing.
It doesn't simulate its input to completion.

But it can, and Peter Olcott might even have the software skills to
pull that off within his apparatus.

The problem is he would never code anything that disagrees with his narrative. He's looking for ways to confirm he is right, rather
than, like a proper scientist, looking for for ways he might be wrong.

It just the opposite. You and others are so indoctrinated
into the received view that you fail to understand that:

(A) The input finite string to HHH(DD) specifies non-terminating
recursive simulation AND

(B) ALL halt deciders ARE ONLY CONCERNED WITH the
ACTUAL BEHAVIOR that the ACTUAL INPUT ACTUALLY SPECIFIES

HHH can return the 0 value that causes the simulation to be
terminatng, and just before returning 0, farm out the completion
of the simulation to an asynchronous thread which will demonstrate
that DD terminates.

The correct return value is the opposite of what is returned.
It is impossible for HHH to be pure.

It is certainly possible for HHH to be pure. For instance, it
can step thorugh some set number of instrutions of its input,
and then unconditionally return 0.

Although the technical terms of the art define
a Turing machine that only halts as a decider
that has accepted its input that it not what
a decider means everywhere else.

What good would such a "decider" be to its
primary intended purpose of total proof of
program correctness?

Then all the impure crap
about comparing function addresses is gone. We still have
a terminating DD, and an incorrect 0 return value as before,
yet HHH is pure. We can also show that the abandoned simulation
of DD is one of a terminating function call.

--
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 9/8/2025 7:47 PM, olcott wrote:

On 9/7/2025 10:14 AM, Kaz Kylheku wrote:

On 2025-09-07, joes <noreply@example.org> wrote:

I think we all understand that HHH cannot simulate itself to completion.

When he has it returning 0, HHH itself is obviously completing.
It doesn't simulate its input to completion.

But it can, and Peter Olcott might even have the software skills to
pull that off within his apparatus.

The problem is he would never code anything that disagrees with his
narrative. He's looking for ways to confirm he is right, rather
than, like a proper scientist, looking for for ways he might be wrong.

It just the opposite. You and others are so indoctrinated
into the received view that you fail to understand that:

(A) The input finite string to HHH(DD) specifies non-terminating
recursive simulation AND

(B) ALL halt deciders ARE ONLY CONCERNED WITH the
ACTUAL BEHAVIOR that the ACTUAL INPUT ACTUALLY SPECIFIES

ALL you people as so indoctrinated that you expect
a halt decider to report on behavior THAT IT CANNOT
POSSIBLY SEE and you then blame the decider for not
having psychic ability.

Deciders ONLY compute the mapping from their input
finite strings to the ACTUAL BEHAVIOR that these finite
strings ACTUALLY SPECIFY, no psychic ability required.
--
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 Tue, 2025-09-09 at 01:25 +0100, Mike Terry wrote:

On 08/09/2025 20:07, Kaz Kylheku wrote:

On 2025-09-08, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 08/09/2025 16:06, olcott wrote:

All deciders only decide on the basis of the semantic
or syntactic property of their input.

They decide on the basis of the program and input tape presented
to them. See Turing 1936. At no point does Turing mention
simulation or emulation.

Therefore it goes without saying that at no point does Turing mention
that the Turing machine may contain a reference to the machine which is simulating it, and the simulating machine may detect that reference.

Simulation is certainly a valid approach to the problem, but it
is not the only valid approach and it is not definitive. You
don't get to re-couch the problem in terms sympathetic to simulation.

You do, if you do it properly, such that your simulator is pure, and doesn't look for itself in its input /by address/.

If a simulator is so inclined as to look for itself in its input, it
must do so by analyzing the structure of the input: it must detect that something in the input is a precise copy of itself.

And that is begging the question: because detecting equivalent
procedures is a difficulty equal to the halting problem!  You can't
decide halting by deferring to an operation that itself has to decide halting, and you don't have that procedure correctly implemented.

Olcott doesn't understand what it means for two functions to be the
same. His contraption contains a Decide_Halting function which relies on
an incorrect notion of function equivalence.  You cannot use name or pointer equivalence to detect whether two functions are identical, as Olcott is doing.

It yields false negatives, because identical functions can exist
under different names/addresses.

   int add1(int x, int y) { return x + y; }
   int add2(int x, int y) { return x + y; }

add1 == add2 is not a correct test of "are these the same function", because it yields a false negative.

Since the number of functions in Olcott's contraption is finite, they
can all be manually enumerated and partitioned into an equivalence
class. Then an accurate same_function(a, b) function can be written
which yields the correct ansewr for any pair of functions a and b
that exist in the apparatus. The function must be correctly maintained whenever functions are added or changed.

When Olcott's Decide_Halting is modified to use same_function(addr_from_opcode, Address_Of_H) then HHH and HHH1 will not yield different results.

HHH/HHH1 do not use "their own addresses" in Decide_Halting.  If they do in your halt7.c, what date
is that from?  (My copy is from around July 2024).

If HHH/HHH1 were amended to eliminate the mutable static variables (e.g. for the static trace table)
and made so that all simulation levels of HHH have their own local trace table and behave
identically, then HHH/HHH1 would behave identically.  (For what that's worth.  So, we've made a
genuine clone of HHH; now what?)

I don't believe PO needs to or relies on reliably identifying when two functions (such as HHH/HHH1)
represent the same algorithm.  What he /does/ need to do is recognise when the "physically same"
piece of code is /emulated/ at different points of an emulation, including across nested emulations
/of the same computation/.  [Emulated TM code /does/ have an equivalent of instruction address,
namely the TM-description offset.  And it doesn't matter if the same cloned function appears at
different TM-desc offsets - PO would be fine just treating them as distinct routines for his abort
tests.

But we're getting into delicate issues which in the end are dependent on what PO is trying to argue
and specifically /how/ he intends to relate any results he obtains on x86utm to results about TMs.
Since PO can't even recognise issues like that, it's probably not worth spending much time on this.
(Unless posters find such issues more interesting than refuting PO over and over...) 
There are
soooo many other more basic problems to pick on first if we're just refuting PO's claims - like HHH
decides DD never halts, when DD halts.

Mike.

IMO, in POOH case, since HHH is the halt decider (a TM), reaching final halt state should be defined like:
int main() {
int final_stat= HHH(DD); // "halt at the final state" when HHH returns here
// and the variable final_stat is initialized.
}
That also means:
1. DD halts means:
int main() {
DD();
} // DD halts means the real *TM* DD reaches here
2. The DD 'input simulated' by HHH is not real, it can never really reach
the real final halt state but a data/string analyzed/decided to reach its
final state.
And, so, I think 'pure' function or not (and others) should not be important (so far).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 10:06 AM, Kaz Kylheku wrote:

On 2025-09-07, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 07/09/2025 06:49, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

Well, but there is. We know that DD terminates, right? We've all
seen it.

But Olcott's genius lies in removing the "final halt state".

Just pull the plug on the terminal patient and that proves
they are immortal.

*He is the best selling author of theory of computation textbooks*

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

I conclusively proved that DD correctly simulated by
HHH would never stop running unless aborted.

You seem to have disagreement as your highest priority
with an honest dialogue taking no better than second place.

The actual life-supported patient that was input to the hospital
never reaches his terminal breath.

Those who continue to ignore what I'm saying are too ignorant
to begin understanding "dying" and "reaching the terminal breath while
on life support" are not the same, in spite of me repeating
it thousands of times for three years.

--
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 9/7/2025 10:02 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

On 9/7/2025 12:49 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

It can be defined that way, or it can be defined

It is not defined in any other way.

That many be correct yet newbies would get
confused by that.

that when the simulated input is aborted then this
simulated machine stops running and terminates.

Rather, you are conflating the simualTING mafchine with the simulatED machine.

The definition of the proof does that.

Tarski "proved" that no consistent True(L,E) predicate
can be defined in the same language using this same
screwy pathological self-reference basis.

*Gödel 1931:39-41 admits that he did the same thing*
"We are therefore confronted with a proposition which
asserts its own unprovability."

The simulating machine deciding to stop (and return zero, for instance)
does not determine the halting status of the simulated machine.

I do understand that you would like to be able to call a machine that
reaches its final halt state non-terminating,

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

The answer is yes,

I am excluding cheating

such a simulating HHH can be found; for instance a
HHH that launches a thread to complete the rest of the simulation of DD,

That is not DD emulated by HHH according to the
semantics of the x86 language.

and then returns 0. Returning 0 causes DD to be terminating, and the
thread will demonstrate it by completing the simulation right through
DD's ret instruction, and reporting that fact on the console output.

I don't know what you mean by "correct question"; any question
that is well-formed and makes sense is a good question.

The above question does not coincide with any question posed under the umbrellal of the Halting Problem; it is not a pertinent question.

because it suits certain
narratives of yours revolving around your unsubstantiated opinions,
but there is no logical basis for that.

All deciders only report on the syntactic or
semantic property specified by their input
finite string.

Ah, speaking of which; I asked you to completely identify everything
that you believe comprises that input string; the full bill of
materials.

The program under test is DD.
The test program is HHH.

The dishonest Liar Paradox structure of the
relationship between DD and HHH was
intentionally defined to try to fool HHH.

This is very much related to Rice's Theorem.

The *ACTUAL INPUT* to HHH(DD) *ACTUALLY SPECIFIES*
the semantic property of recursive simulation that
cannot possibly reach the simulated final halt state.

OK, but you distinuish "reach simulated final halt state" from
"terminate", so you are not saying "cannot possibly terminate".

Out-of-memory error does not count because we are
using the C functions as a model for Turing machines.

We measure the ACTUAL BEHAVIOR of the ACTUAL INPUT by
DD simulated by HHH. Any other behavior of anything
else has always been out-of-scope even if the creator
of computer science and everyone after him didn't
notice this.

As a halting decider, HHH(DD) is being asked whether DD terminates,

This has never actually been the case.
It has always been: Does the input machine
description specify specify a sequence of
moves that terminate on their own.

not
whether or not HHH(DD) pulls the plug on the simulation of DD before DD
is stepped to a ret instrution. By returning 0, HHH(DD) is giving
an answer to an impertinent question that is not being asked.

I figured out how to make the decision of HHH a pure
function of its inputs. We must use human brain power
to stipulate the control flow equivalence of simulating
a function to calling a function as a new axiom of
computer science. *This is only the gist of the answer*

When we do that then HHH need not be as smart as
a human nor as smart as each of the five LLMs.
--
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 9/7/2025 9:57 AM, joes wrote:

Am Sun, 07 Sep 2025 09:31:00 -0500 schrieb olcott:

On 9/7/2025 12:49 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with reaching a final halt
state. They are not the same.

There is no difference between a machine reaching a "final halt state"
and that machine terminating.

It can be defined that way, or it can be defined that when the simulated
input is aborted then this simulated machine stops running and
terminates.

That's too easy. Then every machine would be halting.

I do understand that you would like to be able to call a machine that
reaches its final halt state non-terminating,

because it suits certain narratives of yours revolving around your
unsubstantiated opinions, but there is no logical basis for that.

All deciders only report on the syntactic or semantic property specified
by their input finite string.
This is very much related to Rice's Theorem.
The *ACTUAL INPUT* to HHH(DD) *ACTUALLY SPECIFIES* the semantic property
of recursive simulation that cannot possibly reach the simulated final
halt state.

Nah, it's not related. The code of DD that is the input to HHH does
not specify that whatever simulates DD should simulate a call to itself.

DD does call HHH(DD) in recursive simulation
when-so-ever HHH is the notion of simulating
halt decider that I created in 2016.

It specifies that DD calls HHH. If you choose to simulate DD with HHH,
then that is recursive, but DD by itself doesn't specify that. (Well,
it does, but one level further down.)

--
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 9/8/2025 8:52 PM, olcott wrote:

On 9/8/2025 7:47 PM, olcott wrote:

On 9/7/2025 10:14 AM, Kaz Kylheku wrote:

On 2025-09-07, joes <noreply@example.org> wrote:

I think we all understand that HHH cannot simulate itself to
completion.

When he has it returning 0, HHH itself is obviously completing.
It doesn't simulate its input to completion.

But it can, and Peter Olcott might even have the software skills to
pull that off within his apparatus.

The problem is he would never code anything that disagrees with his
narrative. He's looking for ways to confirm he is right, rather
than, like a proper scientist, looking for for ways he might be wrong.

It just the opposite. You and others are so indoctrinated
into the received view that you fail to understand that:

(A) The input finite string to HHH(DD) specifies non-terminating
recursive simulation AND

(B) ALL halt deciders ARE ONLY CONCERNED WITH the
ACTUAL BEHAVIOR that the ACTUAL INPUT ACTUALLY SPECIFIES

ALL you people as so indoctrinated that you expect
a halt decider to report on behavior THAT IT CANNOT
POSSIBLY SEE and you then blame the decider for not
having psychic ability.

In other words, you agree with Turing and Linz that a total halt decider
does not exist.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 09/09/2025 00:30, olcott wrote:

On 9/8/2025 3:26 AM, Mikko wrote:

On 2025-09-06 14:32:41 +0000, olcott said:

<snip>

"correctly emulated" means emulating according to the
semantics of the x86 language.

Irrelevant when the expression "correctly emulated" is not used.
Also irrelevant to the question where DDD halts.

If we do not restrict this to correctly emulated
then some joker here might suggest "interpreting"
the instruction at address 00002183 to mean "jmp 00002194"

Restricting it to "correctly emulated" doesn't seem to stop some
joker from suggesting that a halting process like DD never halts.

You need to look up "correctly" in a dictionary.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 09/09/2025 01:52, olcott wrote:

<snip>

ALL you people as so indoctrinated that you expect
a halt decider to report on behavior THAT IT CANNOT
POSSIBLY SEE

We covered that. It can see its input's behaviour if you give it
the source.

Claiming that it's impossible (when it clearly isn't) is what you
like to call 'counter-factual'.

and you then blame the decider for not
having psychic ability.

No, I blame the programmer for complaining that the decider can't
see relevant behaviour that he doesn't bother passing in, or for
failing to use knowledge of his decider's behaviour that would
enable his (broken but at least predictable) decider to do a
better job.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 09/09/2025 02:04, olcott wrote:

<snip>

I conclusively proved that DD correctly simulated by
HHH would never stop running unless aborted.

So what? The question isn't whether DD halts under a clearly
broken simulation. The question is whether DD halts.

It does.

If the simulation claims otherwise, the simulation is mistaken.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 09/09/2025 03:03, dbush wrote:

On 9/8/2025 8:52 PM, olcott wrote:

<snip>

ALL you people as so indoctrinated that you expect
a halt decider to report on behavior THAT IT CANNOT
POSSIBLY SEE and you then blame the decider for not
having psychic ability.

In other words, you agree with Turing and Linz that a total halt
decider does not exist.

He also betrays, in language like "blame the decider" and
"psychic ability", an emotional investment in his position.

Nobody, but *nobody*, blames the decider for getting the answer
wrong. How can it do anything else? After all, the test case is
*designed* to befuddle the decider. Nor does anyone expect the
decider to have psychic ability.

What people expect is for the decider to fail, which of course it
does. It is not the decider's 'fault' that it fails; it's
reality's fault. That's just how it is.

It's a bit like dividing by zero. I can imagine someone investing
themselves in the idea that if you could only count and subtract
*fast enough*, you could divide 1 by 0. I can even imagine
someone insisting on a recursive argument based on simulating the
process and spending 30 years defending their corner.

But the bottom line of 1/0 is that you Just Can't, and the bottom
line of HHH(DD) is that you Just Can't.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 09/09/2025 02:03, wij wrote:

On Tue, 2025-09-09 at 01:25 +0100, Mike Terry wrote:

[..snip..]

There are
soooo many other more basic problems to pick on first if we're just refuting PO's claims - like HHH
decides DD never halts, when DD halts.


Mike.

IMO, in POOH case, since HHH is the halt decider (a TM), reaching final halt state should be defined like:

int main() {
int final_stat= HHH(DD); // "halt at the final state" when HHH returns here
// and the variable final_stat is initialized.
}

Yes. In x86utm world, the equivalent of a TM machine is something like HHH, but x86utm is written
to locate and run a function called "main" which calls HHH, and HHH subsequently returns to main.

So main here isn't part of "TM" (HHH) being executed. It's part of the paraphernalia PO uses to get
the x86utm virtual address space (particularly the stack) into the right state to start the TM
(HHH). And when HHH returns, the "TM machine" ends like you say when it returns its final state.
The rest of main isn't part of the TM.

But it's useful and quite flexible to have main there, and the coding for x86utm is simplified.

There are other ways it might have been done, e.g. eliminating main() and have x86utm itself set up
the stack to run HHH. Or other ways of indicating halting might have been used like calling a
primitive operation with signature "void Halt(int code)". But given we all like "structured
programming" concepts like strictly nested code blocks, returning from HHH seems like the most
natural way to do it.

That also means:
1. DD halts means:
int main() {
DD();
} // DD halts means the real *TM* DD reaches here

Yes.

2. The DD 'input simulated' by HHH is not real, it can never really reach
the real final halt state but a data/string analyzed/decided to reach its
final state.

Well, HHH could analyse some other halting function like say SomeFunc(). It can do its simulation
and simulate right up to SomeFunc's return. HHH will see that, and conclude that SomeFunc() is
halting. That's ok, but simulation is just one kind of analysis a halt decider can perform to reach
its decision. Like you say in this case SomeFunc() is not "real" in the way HHH is - it's part of
the calculation HHH is performing.

HHH can simulate /some/ functions to their final state, but not DD, because of the specific way DD
and HHH are related.

And, so, I think 'pure' function or not (and others) should not be important (so far).

Probably not. (so far).

But... PO wants to argue about his simulations and what they're doing. His x86utm is written so
that the original HHH and all its nested simulations run in the same address space. When a
simulation changes something in memory every simulation and outer HHH has visibility of that change,
at least in principle! (The simulations might try to avoid looking at those changes, but that takes
discipline through coding rules.)

Also PO talks about HHH and DD() which calls HHH because that corresponds to what the Linz proof
does: the Linz proof (using TMs) embeds the functionality of HHH inside DD and the key point is that
HHH inside DD must do exactly what HHH did.

It's easy to make HHH (the decider) and HHH (embedded in DD) behave differently if impure functions
e.g. misusing global variables are allowed: just set a global flag which modifies HHH behaviour
according to how deep it is in the simulation stack. So we could make HHH decide DD's halting
correctly with such "cheating"!

But with this cheating PO would be breaking the correspondence with the Linz proof, and for such a
cheat there would be no contradiction with that proof! So for PO's argument he needs to follow
coding rules to guarantee no such cheating - and when using one address space for all the code
(decider HHH, and all its nested simulations) those rules mean pure functions or something that
amounts to that.

### That is the point which makes it clearest that HHH/DD need to following coding rules such as
being pure functions (or something very like this) so that there can be no such cheating. That way,
if PO's HHH/DD pair are correctly coded to reflect the relationship they have in Linz proof, and if
HHH /still/ correctly decides DD()'s halting status, that would be a problem for the Linz proof.

Anyway that's why the talk of pure functions comes up - it's not relevant if we simply want to use
x86utm to execute one program in isolation, but PO must follow the code restrictions if he wants his
arguments about HHH and DD to hold. He's made his own life more complicated by his design. If he
had created his simulations each in their own address space the use of global data would not really
matter - it would just be "part of the computation" happening in that address space, and could not
influence other simulation levels in a cheating manner. So there would be no requirement for "pure"
functions to prevent that cheating... (I think! maybe more thought is needed.)


Not sure if that is useful or the sort of response you were looking for. It seems to me that you
were in effect asking "why do people talk about pure functions?"


Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 2:28 PM, Chris M. Thomasson wrote:

On 9/7/2025 8:06 AM, Kaz Kylheku wrote:

On 2025-09-07, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 07/09/2025 06:49, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state" >>>> and that machine terminating.

Well, but there is. We know that DD terminates, right? We've all
seen it.

But Olcott's genius lies in removing the "final halt state".

Just pull the plug on the terminal patient and that proves
they are immortal.

Yikes!

Chop off runners legs and say see, it halted. Or is that on the flip
side? The "zombie" runner continues on? So, non halting?

A zombie runner with head phones to the Thriller on loop! lol.

https://youtu.be/Z85lxckrtzg?list=RDeQNI1KfGXBA

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 4:24 PM, olcott wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 2:33 PM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 11:34 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

_DDD()
[00002183] 55             push ebp
[00002184] 8bec           mov ebp,esp
[00002186] 6883210000     push 00002183 ; push DDD
[0000218b] e833f4ffff     call 000015c3 ; call HHH

This call kicks a simulation with Adddress_Of_HH = HHH.

[00002190] 83c404         add esp,+04
[00002193] 5d             pop ebp
[00002194] c3             ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55             push ebp
[000021a4] 8bec           mov ebp,esp
[000021a6] 6883210000     push 00002183 ; push DDD
[000021ab] e843f3ffff     call 000014f3 ; call HHH1

This call begins a simulation with Adddress_Of_HH = HHH1.

Yes.

This causes Decide_Halting() to consider HHH and HHH1 to be
different,
so of course you get different traces.

HHH and HHH1 are at different machine addresses so that
DD does call HHH(DD) in recursive simulation and DD
does not call HHH1(DD) at all. I have said that thousands
of times in the last three years AND NO ONE GOT IT.

But you're claiming that HHH and HHH1 are (1) pure functions
and (2) identical functions, are you not?

I had forgotten that HHH is not a pure function
until you first mentioned this recently.

That's a pretty important thing to forget.

It tends to points to cognitive decline, I'm afraid.

Richard Heathfield's recent idea of defining HHH
as a parser seems to be the best alternative.

I have written the parser for C "if" statements
that generates jump-code for expressions of
arbitrary complexity and "if" statements of arbitrary
nesting depth using YACC and LEX, so this should
be easy.

This kind of work is a waste of time, especially if the purpose is
exploring theory rather than providing some piece of tooling to people
who expect a certain syntax.

In a dialect of the Lisp language, you can do all the above
as an afternoon exercise.

Famously, a Lisp interpreter can be written in a page of Lisp, without
having to write any lexer or parser.

If you're exploring towers of nested interpreters, that is your
playground.

DD calls HHH(DD) in recursive simulation
THIS CHANGES THE BEHAVIOR OF DD

Sure, but that's not exactly allowed, so as far as meting the
requirements for being able to arguing aginst the Halting Theorem, a DD
that changes behavior is a bug.

You not accepting the requirements, and therefore not seeing a bug,
doesn't make the requirements go away.

Machine M contains simulating halt decider H based on a UTM
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞  // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state

*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩

IT *IS* THE CASE THAT THE INPUT TO M.H ⟨M⟩ ⟨M⟩
DOES SPECIFY BEHAVIOR THAT CANNOT POSSIBLY
REACH ITS OWN SIMULATED FINAL HALT STATE OF ⟨M.qn⟩

That you don't want to bother to pay attention
to this is no actual rebuttal WHAT-SO-EVER.

You are the Halting problem? When will you realize certain things? Never?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/8/2025 8:13 PM, Richard Heathfield wrote:

On 09/09/2025 03:03, dbush wrote:

On 9/8/2025 8:52 PM, olcott wrote:

<snip>

ALL you people as so indoctrinated that you expect
a halt decider to report on behavior THAT IT CANNOT
POSSIBLY SEE and you then blame the decider for not
having psychic ability.

In other words, you agree with Turing and Linz that a total halt
decider does not exist.

He also betrays, in language like "blame the decider" and "psychic
ability", an emotional investment in his position.

Nobody, but *nobody*, blames the decider for getting the answer wrong.
How can it do anything else? After all, the test case is *designed* to befuddle the decider. Nor does anyone expect the decider to have psychic ability.

What people expect is for the decider to fail, which of course it does.
It is not the decider's 'fault' that it fails; it's reality's fault.
That's just how it is.

It's a bit like dividing by zero. I can imagine someone investing
themselves in the idea that if you could only count and subtract *fast enough*, you could divide 1 by 0. I can even imagine someone insisting
on a recursive argument based on simulating the process and spending 30 years defending their corner.

But the bottom line of 1/0 is that you Just Can't, and the bottom line
of HHH(DD) is that you Just Can't.

The fun part about undefined is that we can shoot the breeze and try to
define it for fun. Fair enough?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-08 23:30:18 +0000, olcott said:

On 9/8/2025 3:26 AM, Mikko wrote:

On 2025-09-06 14:32:41 +0000, olcott said:

On 9/6/2025 3:56 AM, Mikko wrote:

On 2025-09-05 15:29:57 +0000, olcott said:

HHH and HHH1 have identical source code except
for their name. The DDD of HHH1(DDD) has identical
behavior to the directly executed DDD().

DDD calls HHH(DDD) in recursive emulation. DDD does
not call HHH1 at all. This is why the behavior
of DDD.HHH1 is different than the behavior of DDD.HHH

_DDD()
[00002183] 55             push ebp
[00002184] 8bec           mov ebp,esp
[00002186] 6883210000     push 00002183 ; push DDD
[0000218b] e833f4ffff     call 000015c3 ; call HHH
[00002190] 83c404         add esp,+04
[00002193] 5d             pop ebp
[00002194] c3             ret
Size in bytes:(0018) [00002194]

_main()
[000021a3] 55             push ebp
[000021a4] 8bec           mov ebp,esp
[000021a6] 6883210000     push 00002183 ; push DDD
[000021ab] e843f3ffff     call 000014f3 ; call HHH1
[000021b0] 83c404         add esp,+04
[000021b3] 33c0           xor eax,eax
[000021b5] 5d             pop ebp
[000021b6] c3             ret
Size in bytes:(0020) [000021b6]

  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  ========== =============
[000021a3][0010382d][00000000] 55         push ebp      ; main()
[000021a4][0010382d][00000000] 8bec       mov ebp,esp   ; main() >>>>> [000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD
[000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1

Begin Local Halt Decider Simulation   Execution Trace Stored at:1138d9 >>>>> [00002183][001138c9][001138cd] 55         push ebp      ; DDD of HHH1
[00002184][001138c9][001138cd] 8bec       mov ebp,esp   ; DDD of HHH1
[00002186][001138c5][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001138c1][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:14e2f9

Begin Local Halt Decider Simulation   Execution Trace Stored at:15e301 >>>>> [00002183][0015e2f1][0015e2f5] 55         push ebp      ; DDD of HHH[0]
[00002184][0015e2f1][0015e2f5] 8bec       mov ebp,esp   ; DDD of HHH[0]
[00002186][0015e2ed][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][0015e2e9][00002190] e833f4ffff call 000015c3 ; call HHH
New slave_stack at:198d21

*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*

[00002183][001a8d19][001a8d1d] 55         push ebp      ; DDD of HHH[1]
[00002184][001a8d19][001a8d1d] 8bec       mov ebp,esp   ; DDD of HHH[1]
[00002186][001a8d15][00002183] 6883210000 push 00002183 ; push DDD
[0000218b][001a8d11][00002190] e833f4ffff call 000015c3 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[00002190][001138c9][001138cd] 83c404     add esp,+04 ; DDD of HHH1 >>>>> [00002193][001138cd][000015a8] 5d         pop ebp     ; DDD of HHH1
[00002194][001138d1][0003a980] c3         ret         ; DDD of HHH1
[000021b0][0010382d][00000000] 83c404     add esp,+04 ; main()
[000021b3][0010382d][00000000] 33c0       xor eax,eax ; main() >>>>> [000021b5][00103831][00000018] 5d         pop ebp     ; main()
[000021b6][00103835][00000000] c3         ret         ; main()
Number of Instructions Executed(352831) == 5266 Pages

That the behaviour or HHH(DDD) is different from the bahavour of
HHH1(DDD) is irrelevant to the question whether DDD halts.

"correctly emulated" means emulating according to the
semantics of the x86 language.

Irrelevant when the expression "correctly emulated" is not used.
Also irrelevant to the question where DDD halts.

If we do not restrict this to correctly emulated
then some joker here might suggest "interpreting"
the instruction at address 00002183 to mean "jmp 00002194"

Irrelevant to the question whether DDD halts.

Also irrelevant whether we use the words "correctly emulated" to
express the intended semantics. The C standard does not.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Mon, 08 Sep 2025 20:33:20 -0500 schrieb olcott:

On 9/7/2025 9:57 AM, joes wrote:

Am Sun, 07 Sep 2025 09:31:00 -0500 schrieb olcott:

On 9/7/2025 12:49 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

It can be defined that way, or it can be defined that when the
simulated input is aborted then this simulated machine stops running
and terminates.

That's too easy. Then every machine would be halting.

All deciders only report on the syntactic or semantic property
specified by their input finite string.
This is very much related to Rice's Theorem.
The *ACTUAL INPUT* to HHH(DD) *ACTUALLY SPECIFIES* the semantic
property of recursive simulation that cannot possibly reach the
simulated final halt state.

Nah, it's not related. The code of DD that is the input to HHH does not
specify that whatever simulates DD should simulate a call to itself.

DD does call HHH(DD) in recursive simulation when-so-ever HHH is the
notion of simulating halt decider that I created in 2016.

That's what I said below:

It specifies that DD calls HHH. If you choose to simulate DD with HHH,
then that is recursive, but DD by itself doesn't specify that. (Well,
it does, but one level further down.)

--
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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-08 15:06:13 +0000, olcott said:

On 9/7/2025 8:39 AM, Richard Heathfield wrote:

On 07/09/2025 14:31, olcott wrote:

On 9/7/2025 12:19 AM, Richard Heathfield wrote:

On 07/09/2025 04:41, olcott wrote:>>

So like I said you conflate termination with
reaching a final halt state. They are not the same.

He just drew a very careful distinction: "aborting the simulation is
not related to *whether or not* the simulated machine halts."

That is not quite even the correct question.

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

That's a question about emulation. You are fully within your rights to
ask it, but it isn't a very interesting question, and it isn't the
question the Halting Problem poses.

The question that the Halting Problem poses (and that Turing has
answered) is whether a universal decider can be written.

All deciders only decide on the basis of the semantic
or syntactic property of their input. This is related
Rice's theorem.

Ultimately a decider can only decide on the basis of the syntactic
properties of the input. Semantic properites that cannot be inferred
from the syntactic properties are not visible to the decidee.

When we ask that question we obtain the relevant
semantic property of *THE ACTUAL INPUT*.

No, we don't obtain it unless the question is answered.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 09/09/2025 08:45, Mikko wrote:

On 2025-09-08 15:06:13 +0000, olcott said:

On 9/7/2025 8:39 AM, Richard Heathfield wrote:

On 07/09/2025 14:31, olcott wrote:

On 9/7/2025 12:19 AM, Richard Heathfield wrote:

On 07/09/2025 04:41, olcott wrote:>>

So like I said you conflate termination with
reaching a final halt state. They are not the same.

He just drew a very careful distinction: "aborting the
simulation is not related to *whether or not* the simulated
machine halts."

That is not quite even the correct question.

*Here is the correct question*
Can DD emulated by any HHH according to the semantics
of the x86 language possibly reach its own emulated
"ret" instruction final halt state?

That's a question about emulation. You are fully within your
rights to ask it, but it isn't a very interesting question,
and it isn't the question the Halting Problem poses.

The question that the Halting Problem poses (and that Turing
has answered) is whether a universal decider can be written.

All deciders only decide on the basis of the semantic
or syntactic property of their input. This is related
Rice's theorem.

Ultimately a decider can only decide on the basis of the syntactic
properties of the input. Semantic properites that cannot be inferred
from the syntactic properties are not visible to the decidee.

When we ask that question we obtain the relevant
semantic property of *THE ACTUAL INPUT*.

No, we don't obtain it unless the question is answered.

In this case, it is.

THE ACTUAL INPUT is:

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

We know from Mr Olcott that HHH(DD) yields 0 (rejecting DD as
being non-halting), so the if fails, and the return kicks in,
yielding a 0 result to main, which then halts.

So HHH does indeed answer the question. Wrongly, admittedly, but
then we knew that would happen, right?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Mon, 08 Sep 2025 20:31:13 -0500 schrieb olcott:

On 9/7/2025 10:02 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

On 9/7/2025 12:49 AM, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

There is no difference between a machine reaching a "final halt
state" and that machine terminating.

It can be defined that way, or it can be defined

It is not defined in any other way.

That many be correct yet newbies would get confused by that.

that when the simulated input is aborted then this simulated machine
stops running and terminates.

Rather, you are conflating the simualTING mafchine with the simulatED
machine.

The definition of the proof does that.

It does not. It doesn't even mention simulation.

The simulating machine deciding to stop (and return zero, for instance)
does not determine the halting status of the simulated machine.

I do understand that you would like to be able to call a machine that
reaches its final halt state non-terminating,

*Here is the correct question*
Can DD emulated by any HHH according to the semantics of the x86
language possibly reach its own emulated "ret" instruction final halt
state?

The answer is yes,

I am excluding cheating

such a simulating HHH can be found; for instance a HHH that launches a
thread to complete the rest of the simulation of DD,

That is not DD emulated by HHH according to the semantics of the x86 language.

Yes it is. The simulation thread is of course not cheating by deviating
from x86 semantics (although I'd contend that you can't return with the
promise of halting later, but it works in this case).

and then returns 0. Returning 0 causes DD to be terminating, and the
thread will demonstrate it by completing the simulation right through
DD's ret instruction, and reporting that fact on the console output.
I don't know what you mean by "correct question"; any question that is
well-formed and makes sense is a good question.
The above question does not coincide with any question posed under the
umbrellal of the Halting Problem; it is not a pertinent question.

Ah, speaking of which; I asked you to completely identify everything
that you believe comprises that input string; the full bill of
materials.

The program under test is DD.
The test program is HHH.
The dishonest Liar Paradox structure of the relationship between DD and
HHH was intentionally defined to try to fool HHH.

HHH is also the program under test, that's the whole idea of diagon-
alisation. DD does nothing else but call HHH, so could be replaced
with that. Then we have HHH(HHH). The proof is built on the question
whether a supposed decider can decide its (modified) self.
If you leave HHH out of the input, you don't have a program but an
empty template, because DD references the nonexisting HHH.
There is nothing dishonest about using HHH as part of another program.

This is very much related to Rice's Theorem.
The *ACTUAL INPUT* to HHH(DD) *ACTUALLY SPECIFIES* the semantic
property of recursive simulation that cannot possibly reach the
simulated final halt state.

OK, but you distinguish "reach simulated final halt state" from
"terminate", so you are not saying "cannot possibly terminate".

Out-of-memory error does not count because we are using the C functions
as a model for Turing machines.

But does DD terminate, as opposed to reaching the return?

We measure the ACTUAL BEHAVIOR of the ACTUAL INPUT by DD simulated by
HHH. Any other behavior of anything else has always been out-of-scope
even if the creator of computer science and everyone after him didn't
notice this.

The Creator is very much aware that your HHH does not decide the HP.

As a halting decider, HHH(DD) is being asked whether DD terminates,

This has never actually been the case.
It has always been: Does the input machine description specify specify a sequence of moves that terminate on their own.

Exactly wrong. You may define a new problem, but this is the HP.

not whether or not HHH(DD) pulls the plug on the simulation of DD
before DD is stepped to a ret instrution. By returning 0, HHH(DD) is
giving an answer to an impertinent question that is not being asked.

I figured out how to make the decision of HHH a pure function of its
inputs. We must use human brain power to stipulate the control flow equivalence of simulating a function to calling a function as a new
axiom of computer science. *This is only the gist of the answer*
When we do that then HHH need not be as smart as a human nor as smart as
each of the five LLMs.

You can't define your way out of a problem. Russell's paradox still
exists in naive set theory.
--
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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Mon, 08 Sep 2025 19:47:51 -0500 schrieb olcott:

On 9/7/2025 10:14 AM, Kaz Kylheku wrote:

On 2025-09-07, joes <noreply@example.org> wrote:

I think we all understand that HHH cannot simulate itself to
completion.

When he has it returning 0, HHH itself is obviously completing.
It doesn't simulate its input to completion.
But it can, and Peter Olcott might even have the software skills to
pull that off within his apparatus.
The problem is he would never code anything that disagrees with his
narrative. He's looking for ways to confirm he is right, rather than,
like a proper scientist, looking for for ways he might be wrong.

It just the opposite. You and others are so indoctrinated into the
received view that you fail to understand that:
(A) The input finite string to HHH(DD) specifies non-terminating
recursive simulation AND
(B) ALL halt deciders ARE ONLY CONCERNED WITH the ACTUAL BEHAVIOR that
the ACTUAL INPUT ACTUALLY SPECIFIES

DD specifies a call to an aborting(!), therefore terminating simulator.

Although the technical terms of the art define a Turing machine that
only halts as a decider that has accepted its input that it not what a decider means everywhere else.

A decider can also halt in a non-accepting state.
--
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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Mon, 08 Sep 2025 19:00:42 -0500 schrieb olcott:

On 9/7/2025 10:22 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

DD calls HHH(DD) in recursive simulation THIS CHANGES THE BEHAVIOR
OF DD

Sure, but that's not exactly allowed,

Its not allowed for HHH. It is allowed for DD.

Again, you are forgetting that HHH is built almost entirely out of DD.
The change in behavior of DD is the result of HHH changing is behavior,
which you are now admitting is not allowed.

I never said it is not allowed.

What did you mean above by "changing the behaviour of DD is allowed
for DD by calling HHH(DD)"?

I said that the current implementation detail of the method that it uses
to detect recursive simulation is not a computable function.

That's not what I read, but you couldn't have coded your abort check
if it were uncomputable.
--
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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Mon, 08 Sep 2025 18:53:52 -0500 schrieb olcott:

On 9/7/2025 10:22 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

DD calls HHH(DD) in recursive simulation THIS CHANGES THE BEHAVIOR
OF DD

Sure, but that's not exactly allowed,

Its not allowed for HHH. It is allowed for DD.

Again, you are forgetting that HHH is built almost entirely out of DD.

The classic "do the opposite" Counter-example input has always been
anchored in the (semantically unsound) Liar Paradox like structure.

It is perfectly sound: DDD has the semantics of calling HHH, and then
entering a loop or return depending on the result, and HHH demonstrably
gives a result (otherwise DDD loops as well).

The change in behavior of DD is the result of HHH changing is behavior,
which you are now admitting is not allowed.

--
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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Mon, 08 Sep 2025 18:23:49 -0500 schrieb olcott:

On 9/8/2025 1:07 PM, Kaz Kylheku wrote:

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

All deciders only decide on the basis of the semantic or syntactic
property of their input.

That means they must definitely not be peforming tests like, "is the
input executing an x86 CALL instruction whose target address points to
the decider?"

That would definitely be a property of the input.
Whether or not this property is Turing computable is a different issue.

Whether the input contains the address of the decider is not a property
of the input, because it changes with the decider. A property of the
input would be whether it contains the address of one specific decider.
--
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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 09.sep.2025 om 03:04 schreef olcott:

On 9/7/2025 10:06 AM, Kaz Kylheku wrote:

On 2025-09-07, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 07/09/2025 06:49, Kaz Kylheku wrote:

On 2025-09-07, olcott <polcott333@gmail.com> wrote:

So like I said you conflate termination with
reaching a final halt state. They are not the same.

There is no difference between a machine reaching a "final halt state" >>>> and that machine terminating.

Well, but there is. We know that DD terminates, right? We've all
seen it.

But Olcott's genius lies in removing the "final halt state".

Just pull the plug on the terminal patient and that proves
they are immortal.

*He is the best selling author of theory of computation textbooks*

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

I conclusively proved that DD correctly simulated by
HHH would never stop running unless aborted.

It does abort, as does the emulated program when not prematurely
aborted, as proven by world-class simulators.
So, talking about a HHH that does not abort is irrelevant.
This also makes that Sipser agrees with a vacuous statement, because the assumptions for the conclusion are not met.

This has been pointed out to you many times, so read and understand the
next sentence. It seems to apply to you:

You seem to have disagreement as your highest priority
with an honest dialogue taking no better than second place.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 09.sep.2025 om 02:52 schreef olcott:

On 9/8/2025 7:47 PM, olcott wrote:

On 9/7/2025 10:14 AM, Kaz Kylheku wrote:

On 2025-09-07, joes <noreply@example.org> wrote:

I think we all understand that HHH cannot simulate itself to
completion.

When he has it returning 0, HHH itself is obviously completing.
It doesn't simulate its input to completion.

But it can, and Peter Olcott might even have the software skills to
pull that off within his apparatus.

The problem is he would never code anything that disagrees with his
narrative. He's looking for ways to confirm he is right, rather
than, like a proper scientist, looking for for ways he might be wrong.

It just the opposite. You and others are so indoctrinated
into the received view that you fail to understand that:

(A) The input finite string to HHH(DD) specifies non-terminating
recursive simulation AND

Counter-factual, because the program specifies code to abort and halt,
which it does when not prematurely aborted as proven by world-class
simulators and direct execution of exactly the same input.

(B) ALL halt deciders ARE ONLY CONCERNED WITH the
ACTUAL BEHAVIOR that the ACTUAL INPUT ACTUALLY SPECIFIES

In this case the input specifies a halting program, not a DD based on a hypothetical HHH that does not abort.

ALL you people as so indoctrinated that you expect
a halt decider to report on behavior THAT IT CANNOT
POSSIBLY SEE and you then blame the decider for not
having psychic ability.

If a decider cannot see the full specification of the input, then the
decider fails. It is as simple as that. No psychic ability needed.
You have the wrong attitude to close your eyes and pretend that what you cannot see does not exist.
You programmed this incorrect attitude in your decider. It has been
programmed to prematurely abort and therefore it does not reach the
final halt state. Then you think that things that are not seen do not
exists. That is a serious mistake.
Any error in HHH to miss the full specification does not change the specification.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/8/2025 7:25 PM, Mike Terry wrote:

On 08/09/2025 20:07, Kaz Kylheku wrote:

On 2025-09-08, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 08/09/2025 16:06, olcott wrote:

All deciders only decide on the basis of the semantic
or syntactic property of their input.

They decide on the basis of the program and input tape presented
to them. See Turing 1936. At no point does Turing mention
simulation or emulation.

Therefore it goes without saying that at no point does Turing mention
that the Turing machine may contain a reference to the machine which is
simulating it, and the simulating machine may detect that reference.

Simulation is certainly a valid approach to the problem, but it
is not the only valid approach and it is not definitive. You
don't get to re-couch the problem in terms sympathetic to simulation.

You do, if you do it properly, such that your simulator is pure, and
doesn't look for itself in its input /by address/.

If a simulator is so inclined as to look for itself in its input, it
must do so by analyzing the structure of the input: it must detect that
something in the input is a precise copy of itself.

And that is begging the question: because detecting equivalent
procedures is a difficulty equal to the halting problem!  You can't
decide halting by deferring to an operation that itself has to decide
halting, and you don't have that procedure correctly implemented.

Olcott doesn't understand what it means for two functions to be the
same. His contraption contains a Decide_Halting function which relies on
an incorrect notion of function equivalence.  You cannot use name or
pointer equivalence to detect whether two functions are identical, as
Olcott is doing.

It yields false negatives, because identical functions can exist
under different names/addresses.

   int add1(int x, int y) { return x + y; }
   int add2(int x, int y) { return x + y; }

add1 == add2 is not a correct test of "are these the same function",
because it yields a false negative.

Since the number of functions in Olcott's contraption is finite, they
can all be manually enumerated and partitioned into an equivalence
class. Then an accurate same_function(a, b) function can be written
which yields the correct ansewr for any pair of functions a and b
that exist in the apparatus. The function must be correctly maintained
whenever functions are added or changed.

When Olcott's Decide_Halting is modified to use
same_function(addr_from_opcode, Address_Of_H) then HHH and HHH1 will not
yield different results.

HHH/HHH1 do not use "their own addresses" in Decide_Halting.  If they do
in your halt7.c, what date is that from?  (My copy is from around July 2024).

February 15, 2025 is the last commit https://github.com/plolcott/x86utm/blob/master/Halt7.c

If HHH/HHH1 were amended to eliminate the mutable static variables (e.g.
for the static trace table) and made so that all simulation levels of
HHH have their own local trace table and behave identically, then HHH/
HHH1 would behave identically.  (For what that's worth.  So, we've made
a genuine clone of HHH; now what?)

Then DD emulated by HHH according to the semantics of the
x86 language would never stop running. Likewise for DD
emulated by HHH1. We can't stop there. We must find the
best way for HHH to recognize the repeating state of its
simulated input as a pure function of this input. This way
must be applicable to the halting problem proofs.

If my memory is correct Mike had the idea that the outer
HHH instances could somehow look into the data of their
slave instances.

Kaz had the idea of running HHH to run twice, the first
time to initialize its static data.

I don't believe PO needs to or relies on reliably identifying when two functions (such as HHH/HHH1) represent the same algorithm.  What he /
does/ need to do is recognise when the "physically same" piece of code
is /emulated/ at different points of an emulation, including across
nested emulations /of the same computation/.  [Emulated TM code /does/
have an equivalent of instruction address, namely the TM-description offset.  And it doesn't matter if the same cloned function appears at different TM-desc offsets - PO would be fine just treating them as
distinct routines for his abort tests.

A correct simulation is defined as DD is emulated by
HHH according to the semantics of the x86 language.

DD correctly simulated by HHH1 has the exact same
behavior as the directly executed DD().

The key point made by the HHH and HHH1 versions is to
show exactly how and why the behavior of DD() is not the
same as the behavior of DD correctly simulated by HHH.

DD() is essentially the same as if itself specifies
infinite recursion that is aborted after its second
recursive call.

The directly executed DD() itself would never stop
running unless aborted at some point. Because of
this we cannot say that DD() would stop running on
its own without intervention. That this intervention
is required indicates that even DD() cannot be said
to actually halt.

But we're getting into delicate issues which in the end are dependent on what PO is trying to argue and specifically /how/ he intends to relate
any results he obtains on x86utm to results about TMs. Since PO can't
even recognise issues like that, it's probably not worth spending much
time on this. (Unless posters find such issues more interesting than refuting PO over and over...)  There are soooo many other more basic problems to pick on first if we're just refuting PO's claims - like HHH decides DD never halts, when DD halts.

Mike.

You are not paying close enough attention to the
key nuances of my position.
--
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 Tue, 2025-09-09 at 04:31 +0100, Mike Terry wrote:

On 09/09/2025 02:03, wij wrote:

On Tue, 2025-09-09 at 01:25 +0100, Mike Terry wrote:

[..snip..]

  There are
soooo many other more basic problems to pick on first if we're just refuting PO's claims - like
HHH
decides DD never halts, when DD halts.

Mike.

IMO, in POOH case, since HHH is the halt decider (a TM), reaching final halt
state should be defined like:

int main() {
   int final_stat= HHH(DD);  // "halt at the final state" when HHH returns here
                             // and the variable final_stat is initialized.
}

Yes.  In x86utm world, the equivalent of a TM machine is something like HHH, but x86utm is written
to locate and run a function called "main" which calls HHH, and HHH subsequently returns to main.

So main here isn't part of "TM" (HHH) being executed.  It's part of the paraphernalia PO uses to get
the x86utm virtual address space (particularly the stack) into the right state to start the TM
(HHH).  And when HHH returns, the "TM machine" ends like you say when it returns its final state.
The rest of main isn't part of the TM.

But it's useful and quite flexible to have main there, and the coding for x86utm is simplified.

There are other ways it might have been done, e.g. eliminating main() and have x86utm itself set up
the stack to run HHH.  Or other ways of indicating halting might have been used like calling a
primitive operation with signature "void Halt(int code)".  But given we all like "structured
programming" concepts like strictly nested code blocks, returning from HHH seems like the most
natural way to do it.

That also means:
   1. DD halts means:
      int main() {
        DD();
      } // DD halts means the real *TM* DD reaches here

Yes.

   2. The DD 'input simulated' by HHH is not real, it can never really reach
      the real final halt state but a data/string analyzed/decided to reach its
      final state.

Well, HHH could analyse some other halting function like say SomeFunc().  It can do its simulation
and simulate right up to SomeFunc's return.  HHH will see that, and conclude that SomeFunc() is
halting.  That's ok, but simulation is just one kind of analysis a halt decider can perform to reach
its decision.  Like you say in this case SomeFunc() is not "real" in the way HHH is - it's part of
the calculation HHH is performing.

HHH can simulate /some/ functions to their final state, but not DD, because of the specific way DD
and HHH are related.

And, so, I think 'pure' function or not (and others) should not be important (so far).

Probably not. (so far).

But... PO wants to argue about his simulations and what they're doing.  His x86utm is written so
that the original HHH and all its nested simulations run in the same address space.  When a
simulation changes something in memory every simulation and outer HHH has visibility of that change,
at least in principle!  (The simulations might try to avoid looking at those changes, but that takes
discipline through coding rules.)

Also PO talks about HHH and DD() which calls HHH because that corresponds to what the Linz proof
does: the Linz proof (using TMs) embeds the functionality of HHH inside DD and the key point is that
HHH inside DD must do exactly what HHH did.

It's easy to make HHH (the decider) and HHH (embedded in DD) behave differently if impure functions
e.g. misusing global variables are allowed: just set a global flag which modifies HHH behaviour
according to how deep it is in the simulation stack.  So we could make HHH decide DD's halting
correctly with such "cheating"!

But with this cheating PO would be breaking the correspondence with the Linz proof, and for such a
cheat there would be no contradiction with that proof!  So for PO's argument he needs to follow
coding rules to guarantee no such cheating - and when using one address space for all the code
(decider HHH, and all its nested simulations) those rules mean pure functions or something that
amounts to that.

###  That is the point which makes it clearest that HHH/DD need to following coding rules such as
being pure functions (or something very like this) so that there can be no such cheating.  That way,
if PO's HHH/DD pair are correctly coded to reflect the relationship they have in Linz proof, and if
HHH /still/ correctly decides DD()'s halting status, that would be a problem for the Linz proof.

Anyway that's why the talk of pure functions comes up - it's not relevant if we simply want to use
x86utm to execute one program in isolation, but PO must follow the code restrictions if he wants his
arguments about HHH and DD to hold.  He's made his own life more complicated by his design.  If he
had created his simulations each in their own address space the use of global data would not really
matter - it would just be "part of the computation" happening in that address space, and could not
influence other simulation levels in a cheating manner.  So there would be no requirement for "pure"
functions to prevent that cheating...  (I think! maybe more thought is needed.)

Not sure if that is useful or the sort of response you were looking for.  It seems to me that you
were in effect asking "why do people talk about pure functions?"

Mike.

Thanks for the long explanation.
In my view, pure function (or other rules) may also work, but a restricted case of TM (restricted by
the coding rule).
It seems you are trying to make olcott understand.
I would first making olcott understand what contradiction is. He cannot even understand what proposition X&~X means !!!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/8/2025 10:31 PM, Mike Terry wrote:

On 09/09/2025 02:03, wij wrote:

On Tue, 2025-09-09 at 01:25 +0100, Mike Terry wrote:

[..snip..]

  There are
soooo many other more basic problems to pick on first if we're just
refuting PO's claims - like HHH
decides DD never halts, when DD halts.


Mike.

IMO, in POOH case, since HHH is the halt decider (a TM), reaching
final halt
state should be defined like:

int main() {
   int final_stat= HHH(DD);  // "halt at the final state" when HHH
returns here
                             // and the variable final_stat is
initialized.
}

Yes.  In x86utm world, the equivalent of a TM machine is something like HHH, but x86utm is written to locate and run a function called "main"
which calls HHH, and HHH subsequently returns to main.

So main here isn't part of "TM" (HHH) being executed.  It's part of the paraphernalia PO uses to get the x86utm virtual address space
(particularly the stack) into the right state to start the TM (HHH).
And when HHH returns, the "TM machine" ends like you say when it returns
its final state. The rest of main isn't part of the TM.

But it's useful and quite flexible to have main there, and the coding
for x86utm is simplified.

There are other ways it might have been done, e.g. eliminating main()
and have x86utm itself set up the stack to run HHH.  Or other ways of indicating halting might have been used like calling a primitive
operation with signature "void Halt(int code)".  But given we all like "structured programming" concepts like strictly nested code blocks, returning from HHH seems like the most natural way to do it.

That also means:
   1. DD halts means:
      int main() {
        DD();
      } // DD halts means the real *TM* DD reaches here

Yes.

   2. The DD 'input simulated' by HHH is not real, it can never really
reach
      the real final halt state but a data/string analyzed/decided to >> reach its
      final state.

Well, HHH could analyse some other halting function like say
SomeFunc().  It can do its simulation and simulate right up to
SomeFunc's return.  HHH will see that, and conclude that SomeFunc() is halting.  That's ok, but simulation is just one kind of analysis a halt decider can perform to reach its decision.  Like you say in this case SomeFunc() is not "real" in the way HHH is - it's part of the
calculation HHH is performing.

HHH can simulate /some/ functions to their final state, but not DD,
because of the specific way DD and HHH are related.

And, so, I think 'pure' function or not (and others) should not be
important (so far).

Probably not. (so far).

But... PO wants to argue about his simulations and what they're doing.
His x86utm is written so that the original HHH and all its nested simulations run in the same address space.  When a simulation changes something in memory every simulation and outer HHH has visibility of
that change, at least in principle!  (The simulations might try to avoid looking at those changes, but that takes discipline through coding rules.)

Also PO talks about HHH and DD() which calls HHH because that
corresponds to what the Linz proof does: the Linz proof (using TMs)
embeds the functionality of HHH inside DD and the key point is that HHH inside DD must do exactly what HHH did.

It's easy to make HHH (the decider) and HHH (embedded in DD) behave differently if impure functions e.g. misusing global variables are
allowed: just set a global flag which modifies HHH behaviour according
to how deep it is in the simulation stack.  So we could make HHH decide DD's halting correctly with such "cheating"!

But with this cheating PO would be breaking the correspondence with the
Linz proof, and for such a cheat there would be no contradiction with
that proof!  So for PO's argument he needs to follow coding rules to guarantee no such cheating - and when using one address space for all
the code (decider HHH, and all its nested simulations) those rules mean
pure functions or something that amounts to that.

###  That is the point which makes it clearest that HHH/DD need to following coding rules such as being pure functions (or something very
like this) so that there can be no such cheating.  That way, if PO's
HHH/DD pair are correctly coded to reflect the relationship they have in Linz proof, and if HHH /still/ correctly decides DD()'s halting status,
that would be a problem for the Linz proof.

Anyway that's why the talk of pure functions comes up - it's not
relevant if we simply want to use x86utm to execute one program in isolation, but PO must follow the code restrictions if he wants his arguments about HHH and DD to hold.

He's made his own life more
complicated by his design.  If he had created his simulations each in
their own address space the use of global data would not really matter -
it would just be "part of the computation" happening in that address
space, and could not influence other simulation levels in a cheating manner.  So there would be no requirement for "pure" functions to
prevent that cheating...  (I think! maybe more thought is needed.)

Each of the simulations already do occur in their own address space.
Every time that HHH is invoked or simulated this HHH creates a
separate process context that stores a set of 16 virtual registers
and a virtual stack.

The key missing element is providing a way that the outermost
HHH can see the execution trace derived by the inner HHH(DD)
instances as a pure function of its own input.

These traces already are a pure function of the input to the
outer HHH. They remain the same even if they are not stored.

Not sure if that is useful or the sort of response you were looking
for.  It seems to me that you were in effect asking "why do people talk about pure functions?"

Mike.

C functions that are Turing computable.
--
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 09/09/2025 16:40, olcott wrote:

On 9/8/2025 10:31 PM, Mike Terry wrote:

On 09/09/2025 02:03, wij wrote:

On Tue, 2025-09-09 at 01:25 +0100, Mike Terry wrote:

[..snip..]

  There are
soooo many other more basic problems to pick on first if we're just refuting PO's claims - like HHH
decides DD never halts, when DD halts.


Mike.

IMO, in POOH case, since HHH is the halt decider (a TM), reaching final halt
state should be defined like:

int main() {
   int final_stat= HHH(DD);  // "halt at the final state" when HHH returns here
                             // and the variable final_stat is initialized. >>> }

Yes.  In x86utm world, the equivalent of a TM machine is something like HHH, but x86utm is written
to locate and run a function called "main" which calls HHH, and HHH subsequently returns to main.

So main here isn't part of "TM" (HHH) being executed.  It's part of the paraphernalia PO uses to
get the x86utm virtual address space (particularly the stack) into the right state to start the TM
(HHH). And when HHH returns, the "TM machine" ends like you say when it returns its final state.
The rest of main isn't part of the TM.

But it's useful and quite flexible to have main there, and the coding for x86utm is simplified.

There are other ways it might have been done, e.g. eliminating main() and have x86utm itself set
up the stack to run HHH.  Or other ways of indicating halting might have been used like calling a
primitive operation with signature "void Halt(int code)".  But given we all like "structured
programming" concepts like strictly nested code blocks, returning from HHH seems like the most
natural way to do it.

That also means:
   1. DD halts means:
      int main() {
        DD();
      } // DD halts means the real *TM* DD reaches here

Yes.

   2. The DD 'input simulated' by HHH is not real, it can never really reach
      the real final halt state but a data/string analyzed/decided to reach its
      final state.

Well, HHH could analyse some other halting function like say SomeFunc().  It can do its simulation
and simulate right up to SomeFunc's return.  HHH will see that, and conclude that SomeFunc() is
halting.  That's ok, but simulation is just one kind of analysis a halt decider can perform to
reach its decision.  Like you say in this case SomeFunc() is not "real" in the way HHH is - it's
part of the calculation HHH is performing.

HHH can simulate /some/ functions to their final state, but not DD, because of the specific way DD
and HHH are related.

And, so, I think 'pure' function or not (and others) should not be important (so far).

Probably not. (so far).

But... PO wants to argue about his simulations and what they're doing. His x86utm is written so
that the original HHH and all its nested simulations run in the same address space.  When a
simulation changes something in memory every simulation and outer HHH has visibility of that
change, at least in principle!  (The simulations might try to avoid looking at those changes, but
that takes discipline through coding rules.)

Also PO talks about HHH and DD() which calls HHH because that corresponds to what the Linz proof
does: the Linz proof (using TMs) embeds the functionality of HHH inside DD and the key point is
that HHH inside DD must do exactly what HHH did.

It's easy to make HHH (the decider) and HHH (embedded in DD) behave differently if impure
functions e.g. misusing global variables are allowed: just set a global flag which modifies HHH
behaviour according to how deep it is in the simulation stack.  So we could make HHH decide DD's
halting correctly with such "cheating"!

But with this cheating PO would be breaking the correspondence with the Linz proof, and for such a
cheat there would be no contradiction with that proof!  So for PO's argument he needs to follow
coding rules to guarantee no such cheating - and when using one address space for all the code
(decider HHH, and all its nested simulations) those rules mean pure functions or something that
amounts to that.

###  That is the point which makes it clearest that HHH/DD need to following coding rules such as
being pure functions (or something very like this) so that there can be no such cheating.  That
way, if PO's HHH/DD pair are correctly coded to reflect the relationship they have in Linz proof,
and if HHH /still/ correctly decides DD()'s halting status, that would be a problem for the Linz
proof.

Anyway that's why the talk of pure functions comes up - it's not relevant if we simply want to use
x86utm to execute one program in isolation, but PO must follow the code restrictions if he wants
his arguments about HHH and DD to hold.

He's made his own life more complicated by his design.  If he had created his simulations each in
their own address space the use of global data would not really matter - it would just be "part of
the computation" happening in that address space, and could not influence other simulation levels
in a cheating manner.  So there would be no requirement for "pure" functions to prevent that
cheating...  (I think! maybe more thought is needed.)

Each of the simulations already do occur in their own address space.
Every time that HHH is invoked or simulated this HHH creates a
separate process context that stores a set of 16 virtual registers
and a virtual stack.

No, you don't understand what an "address space" is. Simply put, it's the set of all the memory
locations accessible by the processor when running the program. Since outer HHH and all the
simulations have the same accessible memory locations, they are in the same address space. You also
don't seem to understand the differences between processes and threads based on what you've said
elsewhere. (Good job you were in the top 5% of your CS class, or I'd really have to go back to
basics!) :)

Mike.

The key missing element is providing a way that the outermost
HHH can see the execution trace derived by the inner HHH(DD)
instances as a pure function of its own input.

These traces already are a pure function of the input to the
outer HHH. They remain the same even if they are not stored.

Not sure if that is useful or the sort of response you were looking for.  It seems to me that you
were in effect asking "why do people talk about pure functions?"


Mike.

C functions that are Turing computable.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

Op 09.sep.2025 om 02:52 schreef olcott:

On 9/8/2025 7:47 PM, olcott wrote:

On 9/7/2025 10:14 AM, Kaz Kylheku wrote:

On 2025-09-07, joes <noreply@example.org> wrote:

I think we all understand that HHH cannot simulate itself to
completion.

When he has it returning 0, HHH itself is obviously completing.
It doesn't simulate its input to completion.

But it can, and Peter Olcott might even have the software skills to
pull that off within his apparatus.

The problem is he would never code anything that disagrees with his
narrative. He's looking for ways to confirm he is right, rather
than, like a proper scientist, looking for for ways he might be wrong. >>>>

It just the opposite. You and others are so indoctrinated
into the received view that you fail to understand that:

(A) The input finite string to HHH(DD) specifies non-terminating
recursive simulation AND

Counter-factual, because the program specifies code to abort and halt,
which it does when not prematurely aborted as proven by world-class simulators and direct execution of exactly the same input.

(B) ALL halt deciders ARE ONLY CONCERNED WITH the
ACTUAL BEHAVIOR that the ACTUAL INPUT ACTUALLY SPECIFIES

In this case the input specifies a halting program, not a DD based on a hypothetical HHH that does not abort.

ALL you people as so indoctrinated that you expect
a halt decider to report on behavior THAT IT CANNOT
POSSIBLY SEE and you then blame the decider for not
having psychic ability.

If a decider cannot see the full specification of the input, then the decider fails. It is as simple as that. No psychic ability needed.

DD() is essentially infinite recursion that is
aborted after its second recursive call.

When HHH can directly see DD() then HHH aborts
DD() on its first recursive call.

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

_DD()
[00002211] 55 push ebp
[00002212] 8bec mov ebp,esp
[00002214] 51 push ecx
[00002215] 6811220000 push 00002211
[0000221a] e802f4ffff call 00001621
[0000221f] 83c404 add esp,+04
[00002222] 8945fc mov [ebp-04],eax
[00002225] 837dfc00 cmp dword [ebp-04],+00
[00002229] 7402 jz 0000222d
[0000222b] ebfe jmp 0000222b
[0000222d] 8b45fc mov eax,[ebp-04]
[00002230] 8be5 mov esp,ebp
[00002232] 5d pop ebp
[00002233] c3 ret
Size in bytes:(0035) [00002233]

_main()
[00002241] 55 push ebp
[00002242] 8bec mov ebp,esp
[00002244] e8c8ffffff call 00002211
[00002249] 6841220000 push 00002241
[0000224e] e8cef3ffff call 00001621
[00002253] 83c404 add esp,+04
[00002256] 33c0 xor eax,eax
[00002258] 5d pop ebp
[00002259] c3 ret
Size in bytes:(0025) [00002259]

machine stack stack machine assembly
address address data code language
======== ======== ======== ============== ============= [00002249][001039bc][00002241] 6841220000 push 00002241 // push main [0000224e][001039b8][00002253] e8cef3ffff call 00001621 // call HHH execution_trace:90909090
New slave_stack at:15e52c

Begin Local Halt Decider Simulation Execution Trace Stored at:16e534 [00002241][0016e524][0016e528] 55 push ebp // main-01 [00002242][0016e524][0016e528] 8bec mov ebp,esp // main-02 [00002244][0016e520][00002249] e8c8ffffff call 00002211 // call DD [00002211][0016e51c][0016e524] 55 push ebp // DD-01 [00002212][0016e51c][0016e524] 8bec mov ebp,esp // DD-02 [00002214][0016e518][0015e52c] 51 push ecx // DD-03 [00002215][0016e514][00002211] 6811220000 push 00002211 // push DD [0000221a][0016e510][0000221f] e802f4ffff call 00001621 // call HHH execution_trace:16e534
New slave_stack at:1a8f54
[00002211][001b8f4c][001b8f50] 55 push ebp // DD-01 [00002212][001b8f4c][001b8f50] 8bec mov ebp,esp // DD-02 [00002214][001b8f48][001a8f54] 51 push ecx // DD-03 [00002215][001b8f44][00002211] 6811220000 push 00002211 // push DD [0000221a][001b8f40][0000221f] e802f4ffff call 00001621 // call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[00002253][001039c0][00000000] 83c404 add esp,+04 // main-06 [00002256][001039c0][00000000] 33c0 xor eax,eax // main-07 [00002258][001039c4][00000018] 5d pop ebp // main-08 [00002259][001039c8][00000000] c3 ret // main-09
Number of Instructions Executed(22962) == 343 Pages

Now that HHH can see DD() executed from main HHH
correctly determines that DD() executed from main()
does not halt.
--
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 9/9/2025 3:18 AM, joes wrote:

Am Mon, 08 Sep 2025 19:00:42 -0500 schrieb olcott:

On 9/7/2025 10:22 AM, Kaz Kylheku wrote:

On 2025-09-06, olcott <polcott333@gmail.com> wrote:

On 9/6/2025 5:42 PM, Kaz Kylheku wrote:

DD calls HHH(DD) in recursive simulation THIS CHANGES THE BEHAVIOR >>>>>> OF DD

Sure, but that's not exactly allowed,

Its not allowed for HHH. It is allowed for DD.

Again, you are forgetting that HHH is built almost entirely out of DD.
The change in behavior of DD is the result of HHH changing is behavior,
which you are now admitting is not allowed.

I never said it is not allowed.

What did you mean above by "changing the behaviour of DD is allowed
for DD by calling HHH(DD)"?

DD can be any sort of garbage and it not requires
to be a pure function. When we assume that HHH(DD)

DD correctly simulated by HHH always has the
same behavior no matter what.

On 9/4/2025 4:16 PM, Kaz Kylheku wrote:

If we somehow correctly detect that successive
nested simulations are identical, we can conclude
by induction that we have a repeating pattern:
all subsequent levels are the same.

If HHH can see this repeating pattern and thus
correctly returns 0, this allows the executed DD()
to reach its own final halt state.

I said that the current implementation detail of the method that it uses
to detect recursive simulation is not a computable function.

That's not what I read, but you couldn't have coded your abort check
if it were uncomputable.

C computable and Turing computable are not the same thing.
Pure C functions are Turing computable functions. https://en.wikipedia.org/wiki/Pure_function
--
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 9/9/2025 3:13 AM, joes wrote:

Am Mon, 08 Sep 2025 19:47:51 -0500 schrieb olcott:

On 9/7/2025 10:14 AM, Kaz Kylheku wrote:

On 2025-09-07, joes <noreply@example.org> wrote:

I think we all understand that HHH cannot simulate itself to
completion.

When he has it returning 0, HHH itself is obviously completing.
It doesn't simulate its input to completion.
But it can, and Peter Olcott might even have the software skills to
pull that off within his apparatus.
The problem is he would never code anything that disagrees with his
narrative. He's looking for ways to confirm he is right, rather than,
like a proper scientist, looking for for ways he might be wrong.

It just the opposite. You and others are so indoctrinated into the
received view that you fail to understand that:
(A) The input finite string to HHH(DD) specifies non-terminating
recursive simulation AND
(B) ALL halt deciders ARE ONLY CONCERNED WITH the ACTUAL BEHAVIOR that
the ACTUAL INPUT ACTUALLY SPECIFIES

DD specifies a call to an aborting(!), therefore terminating simulator.

Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running.

Although the technical terms of the art define a Turing machine that
only halts as a decider that has accepted its input that it not what a
decider means everywhere else.

A decider can also halt in a non-accepting state.

--
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 09/09/2025 17:44, olcott wrote:

If HHH can see this repeating pattern and thus
correctly returns 0, this allows the executed DD()
to reach its own final halt state.

I will accept that HHH(DD) yields 0. You should know, after all.
But "correctly"?

A result of 0 rejects DD as non-halting.

But when HHH yields 0, DD halts.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 09/09/2025 17:54, olcott wrote:

<snip>

Neither the simulated HHH nor the simulated DD
can possibly halt even though they stop running.

I think that speaks for itself.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/9/2025 11:33 AM, Mike Terry wrote:

On 09/09/2025 16:40, olcott wrote:>>

Each of the simulations already do occur in their own address space.
Every time that HHH is invoked or simulated this HHH creates a
separate process context that stores a set of 16 virtual registers
and a virtual stack.

No, you don't understand what an "address space" is.  Simply put, it's
the set of all the memory locations accessible by the processor when
running the program.

We have a bunch of different processors.
The highest relevant level processor is
the x86utm operating system that directly
simulates the code specified in main().

The next level processor is when main()
calls HHH(DD) and HHH simulates its input.
The next level is when the simulated DD
calls HHH(DD) that simulates its input.

That is all the levels we need for HHH to
match the recursive simulation non-halting
behavior pattern.

Since outer HHH and all the simulations have the
same accessible memory locations, they are in the same address space.

HHH and HHH1 do have local data stored on their stack.
They each also have local static data that is allocated
from the global heap.

You also don't seem to understand the differences between processes and threads based on what you've said elsewhere.  (Good job you were in the
top 5% of your CS class, or I'd really have to go back to basics!)  :)

Mike.

I was the #1 student out of fifty (top 2%) of
my operating systems senior level class.

Back in 1985 textbooks did not mention threads.
I looked it up in my 1985 textbook, no mention.
I looked it up on Google and found that threads
did not become common until the early 2000s.

I remember threads as a lightweight process. https://en.wikipedia.org/wiki/Thread_(computing)
Do you think that threads are Turing computable?

The key missing element is providing a way that the outermost
HHH can see the execution trace derived by the inner HHH(DD)
instances as a pure function of its own input.

These traces already are a pure function of the input to the
outer HHH. They remain the same even if they are not stored.

Not sure if that is useful or the sort of response you were looking
for.  It seems to me that you were in effect asking "why do people
talk about pure functions?"


Mike.

C functions that are Turing computable.

--
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 2025-09-09, olcott <polcott333@gmail.com> wrote:

On 9/9/2025 11:33 AM, Mike Terry wrote:

On 09/09/2025 16:40, olcott wrote:>>

Each of the simulations already do occur in their own address space.
Every time that HHH is invoked or simulated this HHH creates a
separate process context that stores a set of 16 virtual registers
and a virtual stack.

No, you don't understand what an "address space" is.  Simply put, it's
the set of all the memory locations accessible by the processor when
running the program.

We have a bunch of different processors.
The highest relevant level processor is
the x86utm operating system that directly
simulates the code specified in main().

The next level processor is when main()
calls HHH(DD) and HHH simulates its input.
The next level is when the simulated DD
calls HHH(DD) that simulates its input.

That is all the levels we need for HHH to
match the recursive simulation non-halting
behavior pattern.

But the mere circumstance of there being recursive simulation is not
tantamount to non-halting.

All the simulations in an infinte tower of identical simulations
can be individually halting (i.e. heading toward a final halt state
of whatever they are simulating).

It maybe that the tower never terminates due to always sprouting
new terminating simulations, which come into existence at offset
times.

(If an infinite sequence of identical terminating simulations is started
all simultaneously, then the whole thing terminates; but if each
successive simulation is started when its predecessor reaches some step
N > 0, then the sequence never terminates. The individual simulations
still do (if the simulation Subject is terminating, otherwise not).
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/9/2025 9:33 AM, Mike Terry wrote:
[...]

Oh my. He is going to try his hand at multi-threading? Sigh. Does he
even know what a membar is?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-09, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 09/09/2025 17:44, olcott wrote:

If HHH can see this repeating pattern and thus
correctly returns 0, this allows the executed DD()
to reach its own final halt state.

I will accept that HHH(DD) yields 0. You should know, after all.
But "correctly"?

I can accept that halting of a subject S is defined by whether
under the HHH(S) simulation it reaches its last return instruction.

I can accept that HHH(DD) == 0 is correct, even though DD is
the diagonal program targeting HHH.

Great, let's go with that "correct halting question".

Under no circumstances can I accept that, subsequently, when another
decider is proposed such as GGG, that the definition of halting is
changed to "does S under the GGG(S) simulation reach its last return instruction".

The definition must be pinned down and immutable. You get one correct
halting question, not a pattern which generates an infinity of correct questions, one for each decider.

(Moreover, only HHH must be required to be simulating; other deciders are
not required to be simulating, so the very term "GGG(S) simulation"
doesn't even make sense. GGG(S) must reproduce HHH(S) (since HHH(S)
determines what is the correct answer to the "corrrect question")
But it doesn't have to call HHH or use any other simulation mechanism.

I assert that Olcott's Correct Halting Question is still incomputable,
even though it allows HHH(DD) to evade the diagonal DD test case
targeting HHH.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-09, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 9/9/2025 9:33 AM, Mike Terry wrote:
[...]

Oh my. He is going to try his hand at multi-threading? Sigh. Does he
even know what a membar is?

You don't need that if everything is single threaded at the hardware
level; just a software program simulating multiple instances of
simulated x86's, being single stepped one at a time.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/9/2025 12:22 PM, Kaz Kylheku wrote:

On 2025-09-09, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 9/9/2025 9:33 AM, Mike Terry wrote:
[...]

Oh my. He is going to try his hand at multi-threading? Sigh. Does he
even know what a membar is?

You don't need that if everything is single threaded at the hardware
level; just a software program simulating multiple instances of
simulated x86's, being single stepped one at a time.

True. Well, better have signal safe things for code in a handler? POSIX
signal safe?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/9/2025 2:02 PM, Kaz Kylheku wrote:

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

On 9/9/2025 11:33 AM, Mike Terry wrote:

On 09/09/2025 16:40, olcott wrote:>>

Each of the simulations already do occur in their own address space.
Every time that HHH is invoked or simulated this HHH creates a
separate process context that stores a set of 16 virtual registers
and a virtual stack.

No, you don't understand what an "address space" is.  Simply put, it's
the set of all the memory locations accessible by the processor when
running the program.

We have a bunch of different processors.
The highest relevant level processor is
the x86utm operating system that directly
simulates the code specified in main().

The next level processor is when main()
calls HHH(DD) and HHH simulates its input.
The next level is when the simulated DD
calls HHH(DD) that simulates its input.

That is all the levels we need for HHH to
match the recursive simulation non-halting
behavior pattern.

But the mere circumstance of there being recursive simulation is not tantamount to non-halting.

If you paid 100% complete attention I would not
have to repeat myself many dozens of times before
you first notice that I have fully addressed this
point in at least a dozens replies to you.

All the simulations in an infinte tower of identical simulations
can be individually halting (i.e. heading toward a final halt state
of whatever they are simulating).

Sure as soon as someone derives the correct
radius for a square circle has has four
equally length sides of a length of 1.0.

It maybe that the tower never terminates due to always sprouting
new terminating simulations, which come into existence at offset
times.

(If an infinite sequence of identical terminating simulations is started
all simultaneously, then the whole thing terminates; but if each
successive simulation is started when its predecessor reaches some step
N > 0, then the sequence never terminates. The individual simulations
still do (if the simulation Subject is terminating, otherwise not).

It is really not that hard to understand that when
DD calls HHH(DD) in recursive simulation that this
is essentially the same thing as mutual recursion
that cannot possibly come to any normal termination.

You seem to be acting like a brain surgeon that
has no idea that a fever indicates an infection.

The patient has a temperature of 106F so they
are OK for brain surgery and will feel warm and
toasty.
--
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 9/9/2025 2:21 PM, Kaz Kylheku wrote:

On 2025-09-09, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 09/09/2025 17:44, olcott wrote:

If HHH can see this repeating pattern and thus
correctly returns 0, this allows the executed DD()
to reach its own final halt state.

I will accept that HHH(DD) yields 0. You should know, after all.
But "correctly"?

I can accept that halting of a subject S is defined by whether
under the HHH(S) simulation it reaches its last return instruction.

Great we are finally moving forward.
I am only looking for a mutual consensus anchored in
a completely honest dialogue.

I can accept that HHH(DD) == 0 is correct, even though DD is
the diagonal program targeting HHH.

Great, let's go with that "correct halting question".

Under no circumstances can I accept that, subsequently, when another
decider is proposed such as GGG, that the definition of halting is
changed to "does S under the GGG(S) simulation reach its last return instruction".

All termination analyzers operate under the same rule
because they must all report on the basis of the semantic
property of "reaching their simulated final halt state"
specified by their input finite string.

The definition must be pinned down and immutable. You get one correct
halting question, not a pattern which generates an infinity of correct questions, one for each decider.

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

void Infinite_Loop()
{
HERE: goto HERE;
OutputString("I never get here you dumb bunny!\n");
return;
}

int factorial(int n)
{
//Output("factorial:", n);
if (n >= 1)
return n*factorial(n-1);
else
return 1;
}

int factorial_caller()
{
factorial(5);
}

More sample inputs that are decided on the same basis.

(Moreover, only HHH must be required to be simulating; other deciders are
not required to be simulating,

Then they can be fooled. It must either be actual
simulation or something equivalent such as a
directed graph of control SPECIFIED BY THE INPUT
that would be the same control flow as DD simulated by HHH.

so the very term "GGG(S) simulation"
doesn't even make sense. GGG(S) must reproduce HHH(S) (since HHH(S) determines what is the correct answer to the "corrrect question")
But it doesn't have to call HHH or use any other simulation mechanism.

I assert that Olcott's Correct Halting Question is still incomputable,
even though it allows HHH(DD) to evade the diagonal DD test case
targeting HHH.

I think you just confused yourself with convolution
the same way that people analyzing the 1931 incompleteness
theorem used hundreds of nested formulas to confuse
themselves away from this simple truth:

Gödel's 1931 incompleteness theorem
"We are therefore confronted with a proposition
which asserts its own unprovability." Gödel 1931:39-41

Gödel, Kurt 1931. On Formally Undecidable Propositions
of Principia Mathematica And Related Systems I, page 39-41.
--
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 9/9/2025 2:22 PM, Kaz Kylheku wrote:

On 2025-09-09, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 9/9/2025 9:33 AM, Mike Terry wrote:
[...]

Oh my. He is going to try his hand at multi-threading? Sigh. Does he
even know what a membar is?

You don't need that if everything is single threaded at the hardware
level; just a software program simulating multiple instances of
simulated x86's, being single stepped one at a time.

That may now be Turing computable and it seems to change
of what is actually specified, thus inapplicable.
--
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 9/9/2025 2:22 PM, Kaz Kylheku wrote:

On 2025-09-09, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 9/9/2025 9:33 AM, Mike Terry wrote:
[...]

Oh my. He is going to try his hand at multi-threading? Sigh. Does he
even know what a membar is?

You don't need that if everything is single threaded at the hardware
level; just a software program simulating multiple instances of
simulated x86's, being single stepped one at a time.

That may *NOT* be Turing computable and it seems to change
of what is actually specified, thus inapplicable.
--
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

Am Tue, 09 Sep 2025 19:55:56 -0500 schrieb olcott:

On 9/9/2025 2:21 PM, Kaz Kylheku wrote:

On 2025-09-09, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 09/09/2025 17:44, olcott wrote:

I can accept that halting of a subject S is defined by whether under
the HHH(S) simulation it reaches its last return instruction.

Great we are finally moving forward.
I am only looking for a mutual consensus anchored in a completely honest dialogue.

No, you are looking for affirmation.

Under no circumstances can I accept that, subsequently, when another
decider is proposed such as GGG, that the definition of halting is
changed to "does S under the GGG(S) simulation reach its last return
instruction".

You missed the objection.

(Moreover, only HHH must be required to be simulating; other deciders
are not required to be simulating,

Then they can be fooled. It must either be actual simulation or
something equivalent such as a directed graph of control SPECIFIED BY
THE INPUT that would be the same control flow as DD simulated by HHH.

No, they can return "non-halting" just fine.
--
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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/10/2025 12:05 AM, joes wrote:

Am Tue, 09 Sep 2025 19:55:56 -0500 schrieb olcott:

On 9/9/2025 2:21 PM, Kaz Kylheku wrote:

On 2025-09-09, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 09/09/2025 17:44, olcott wrote:

I can accept that halting of a subject S is defined by whether under
the HHH(S) simulation it reaches its last return instruction.

Great we are finally moving forward.
I am only looking for a mutual consensus anchored in a completely honest
dialogue.

No, you are looking for affirmation.

Under no circumstances can I accept that, subsequently, when another
decider is proposed such as GGG, that the definition of halting is
changed to "does S under the GGG(S) simulation reach its last return
instruction".

You missed the objection.

(Moreover, only HHH must be required to be simulating; other deciders
are not required to be simulating,

Then they can be fooled. It must either be actual simulation or
something equivalent such as a directed graph of control SPECIFIED BY
THE INPUT that would be the same control flow as DD simulated by HHH.

No, they can return "non-halting" just fine.

Yeah. A kid in school can say this is non halting

10 PRINT "Halt" : GOTO 10

Lets get him programming BASIC? Leave C/C++ alone for a while?


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 09.sep.2025 om 21:56 schreef olcott:

On 9/9/2025 2:02 PM, Kaz Kylheku wrote:

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

On 9/9/2025 11:33 AM, Mike Terry wrote:

On 09/09/2025 16:40, olcott wrote:>>

Each of the simulations already do occur in their own address space. >>>>> Every time that HHH is invoked or simulated this HHH creates a
separate process context that stores a set of 16 virtual registers
and a virtual stack.

No, you don't understand what an "address space" is.  Simply put, it's >>>> the set of all the memory locations accessible by the processor when
running the program.

We have a bunch of different processors.
The highest relevant level processor is
the x86utm operating system that directly
simulates the code specified in main().

The next level processor is when main()
calls HHH(DD) and HHH simulates its input.
The next level is when the simulated DD
calls HHH(DD) that simulates its input.

That is all the levels we need for HHH to
match the recursive simulation non-halting
behavior pattern.

But the mere circumstance of there being recursive simulation is not
tantamount to non-halting.

If you paid 100% complete attention I would not
have to repeat myself many dozens of times before
you first notice that I have fully addressed this
point in at least a dozens replies to you.

All the simulations in an infinte tower of identical simulations
can be individually halting (i.e. heading toward a final halt state
of whatever they are simulating).

Sure as soon as someone derives the correct
radius for a square circle has has four
equally length sides of a length of 1.0.

It maybe that the tower never terminates due to always sprouting
new terminating simulations, which come into existence at offset
times.

(If an infinite sequence of identical terminating simulations is started
all simultaneously, then the whole thing terminates; but if each
successive simulation is started when its predecessor reaches some step
N > 0, then the sequence never terminates. The individual simulations
still do (if the simulation Subject is terminating, otherwise not).

It is really not that hard to understand that when
DD calls HHH(DD) in recursive simulation that this
is essentially the same thing as mutual recursion
that cannot possibly come to any normal termination.

Incorrect. The input specifies a finite recursion. But HHH fails to see
that because of a premature abort.
When it aborts, it should prove that a correctly continued simulation
would not follow the other branches in the conditional branch
instructions encountered during the simulation of the recursion. It
fails to prove that, so it has no evidence that there is an infinite recursion, when it sees only a finite recursion.


--- Synchronet 3.21a-Linux NewsLink 1.2