From Newsgroup: comp.theory

I find the piece of text is useful. I would like to make it a document,
and for review.
+-----------------------------------+
| C description as a Turing Machine |
+-----------------------------------+
Definition of the TM for treating a piece of C/Assembly (or other high level programming) description as a classic TM.
From classic definition of TM, we need to re-define:
Tape::= Registers + read-writable working space + stack (may contain initial
data)
Transition function::= Readonly program (machine codes)
Initial state::= User define (usually referring to a function call)
Set of final state::= User define (usually the 'ret' instrunction of a 'TM'
function.
'Halt' in classic TM should mean "states that no transition is defined".
But in modern computers, this definition is nearly unworkable.
On CPU machines, halt may be defined the value that Program Counter(PC)
matches specific values (may include the pointed instruction is executed),
and implicitly including the conditon when invalid instruction is
encountered. Once the condition is met, end of the 'TM' definition.
.thread/process: Not part of a TM. There is uncertainty from timing issues (
except cooperative thread).
.Signal(interrupt): Not part of a TM. TM has no capability accessing
information not specifed, and timing issues.
.longjmp(..): Fine.
.exit(int): Depends. If the TM means the whole executable, exit(int) may be fine.
...
.In general, all underlying function calls and data are part of the Transition
function and the Tape.
Example: A Halting Problem proof.
extern int HHH(void (*)());
void DD() {
if(HHH(DD)) while(1);
}
int main() {
HHH(DD); // Assume HHH is a TM (halt decider)
}
This example of description works in some model, but not while assuming HHH is
a TM. Because DD must be considered as data in the tape, which implies the
contained 'HHH(DD)' are all data which may involve encoding. Thus, DD (being
non-real TM) never halts but analyzed to halt or not.
------------------------
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/10/2025 6:36 PM, wij wrote:

I find the piece of text is useful. I would like to make it a document,
and for review.

+-----------------------------------+
| C description as a Turing Machine |
+-----------------------------------+
Definition of the TM for treating a piece of C/Assembly (or other high level programming) description as a classic TM.

From classic definition of TM, we need to re-define:
Tape::= Registers + read-writable working space + stack (may contain initial
data)
Transition function::= Readonly program (machine codes)
Initial state::= User define (usually referring to a function call)
Set of final state::= User define (usually the 'ret' instrunction of a 'TM'
function.

'Halt' in classic TM should mean "states that no transition is defined".
But in modern computers, this definition is nearly unworkable.
On CPU machines, halt may be defined the value that Program Counter(PC)
matches specific values (may include the pointed instruction is executed),
and implicitly including the conditon when invalid instruction is
encountered. Once the condition is met, end of the 'TM' definition.

.thread/process: Not part of a TM. There is uncertainty from timing issues (
except cooperative thread).
.Signal(interrupt): Not part of a TM. TM has no capability accessing
information not specifed, and timing issues.
.longjmp(..): Fine.
.exit(int): Depends. If the TM means the whole executable, exit(int) may be fine.
...
.In general, all underlying function calls and data are part of the Transition
function and the Tape.

Example: A Halting Problem proof.

extern int HHH(void (*)());

void DD() {
if(HHH(DD)) while(1);
}

int main() {
HHH(DD); // Assume HHH is a TM (halt decider)
}

This example of description works in some model, but not while assuming HHH is
a TM. Because DD must be considered as data in the tape, which implies the
contained 'HHH(DD)' are all data which may involve encoding. Thus, DD (being
non-real TM) never halts but analyzed to halt or not. ------------------------

It need not be a TM. It merely needs to
be equivalent to a TM. Kaz is correct
that a pure function ensures that a C
function is TM computable.

https://en.wikipedia.org/wiki/Pure_function
I checked this again and again several different ways
and on other forums.
--
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-10, olcott <polcott333@gmail.com> wrote:

https://en.wikipedia.org/wiki/Pure_function
I checked this again and again several different ways
and on other forums.

Sure, everywhere but in your actual code.
--
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/10/2025 6:52 PM, Kaz Kylheku wrote:

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

https://en.wikipedia.org/wiki/Pure_function
I checked this again and again several different ways
and on other forums.

Sure, everywhere but in your actual code.

I know that HHH(DD) could dig into the data of its
simulated functions as a pure function of its input.
Since HHH would have no idea that it is simulating
itself it could not know where to look.
--
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 Wed, 2025-09-10 at 18:45 -0500, olcott wrote:

On 9/10/2025 6:36 PM, wij wrote:

I find the piece of text is useful. I would like to make it a document, and for review.

+-----------------------------------+

C description as a Turing Machine |

+-----------------------------------+
Definition of the TM for treating a piece of C/Assembly (or other high level
programming) description as a classic TM.

 From classic definition of TM, we need to re-define:
   Tape::= Registers + read-writable working space + stack (may contain initial
           data)
   Transition function::= Readonly program (machine codes)
   Initial state::= User define (usually referring to a function call)    Set of final state::= User define (usually the 'ret' instrunction of a 'TM'
                         function.

       'Halt' in classic TM should mean "states that no transition is defined".
       But in modern computers, this definition is nearly unworkable.        On CPU machines, halt may be defined the value that Program Counter(PC)
       matches specific values (may include the pointed instruction is executed),
       and implicitly including the conditon when invalid instruction is
       encountered. Once the condition is met, end of the 'TM' definition.

  .thread/process: Not part of a TM. There is uncertainty from timing issues (
   except cooperative thread).
  .Signal(interrupt): Not part of a TM. TM has no capability accessing    information not specifed, and timing issues.
  .longjmp(..): Fine.
  .exit(int): Depends. If the TM means the whole executable, exit(int) may be fine.
  ...
  .In general, all underlying function calls and data are part of the Transition
   function and the Tape.

Example: A Halting Problem proof.

  extern int HHH(void (*)());

  void DD() {
    if(HHH(DD)) while(1);
  }

  int main() {
    HHH(DD);   // Assume HHH is a TM (halt decider)
  }

  This example of description works in some model, but not while assuming HHH is
  a TM. Because DD must be considered as data in the tape, which implies the
  contained 'HHH(DD)' are all data which may involve encoding. Thus, DD (being
  non-real TM) never halts but analyzed to halt or not. ------------------------

It need not be a TM. It merely needs to
be equivalent to a TM.

Correct. But the question is you need to prove the equivalence first.

Kaz is correct
that a pure function ensures that a C
function is TM computable.

https://en.wikipedia.org/wiki/Pure_function
I checked this again and again several different ways
and on other forums.

Pure function theory should work. But there are still details (I think mostly  associate to precise definition) to work out. And, the basic still need to be  based on TM. For now, I think my definition above should work better.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On Thu, 2025-09-11 at 08:05 +0800, wij wrote:

On Wed, 2025-09-10 at 18:45 -0500, olcott wrote:

On 9/10/2025 6:36 PM, wij wrote:

I find the piece of text is useful. I would like to make it a document, and for review.

+-----------------------------------+

C description as a Turing Machine |

+-----------------------------------+
Definition of the TM for treating a piece of C/Assembly (or other high level
programming) description as a classic TM.

 From classic definition of TM, we need to re-define:
   Tape::= Registers + read-writable working space + stack (may contain initial
           data)
   Transition function::= Readonly program (machine codes)
   Initial state::= User define (usually referring to a function call)    Set of final state::= User define (usually the 'ret' instrunction of a 'TM'
                         function.

       'Halt' in classic TM should mean "states that no transition is defined".
       But in modern computers, this definition is nearly unworkable.
       On CPU machines, halt may be defined the value that Program Counter(PC)
       matches specific values (may include the pointed instruction is executed),
       and implicitly including the conditon when invalid instruction is
       encountered. Once the condition is met, end of the 'TM' definition.

  .thread/process: Not part of a TM. There is uncertainty from timing issues (
   except cooperative thread).
  .Signal(interrupt): Not part of a TM. TM has no capability accessing    information not specifed, and timing issues.
  .longjmp(..): Fine.
  .exit(int): Depends. If the TM means the whole executable, exit(int) may be fine.
  ...
  .In general, all underlying function calls and data are part of the Transition
   function and the Tape.

Example: A Halting Problem proof.

  extern int HHH(void (*)());

  void DD() {
    if(HHH(DD)) while(1);
  }

  int main() {
    HHH(DD);   // Assume HHH is a TM (halt decider)
  }

  This example of description works in some model, but not while assuming HHH is
  a TM. Because DD must be considered as data in the tape, which implies the
  contained 'HHH(DD)' are all data which may involve encoding. Thus, DD (being
  non-real TM) never halts but analyzed to halt or not. ------------------------

It need not be a TM. It merely needs to
be equivalent to a TM.

Correct. But the question is you need to prove the equivalence first.

 Kaz is correct
that a pure function ensures that a C
function is TM computable.

https://en.wikipedia.org/wiki/Pure_function
I checked this again and again several different ways
and on other forums.

Pure function theory should work. But there are still details (I think mostly 
associate to precise definition) to work out. And, the basic still need to be 
based on TM. For now, I think my definition above should work better.

I am not familiar with pure function, but I feel it may be based on primitive  recursive function theory.
So, if you use it, you should perhaps change POOH to be presented in pure functions.
and talk nothing about TM.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/10/2025 7:51 PM, wij wrote:

On Thu, 2025-09-11 at 08:05 +0800, wij wrote:

On Wed, 2025-09-10 at 18:45 -0500, olcott wrote:

On 9/10/2025 6:36 PM, wij wrote:

I find the piece of text is useful. I would like to make it a document, >>>> and for review.

+-----------------------------------+

C description as a Turing Machine |

+-----------------------------------+
Definition of the TM for treating a piece of C/Assembly (or other high level
programming) description as a classic TM.

 From classic definition of TM, we need to re-define:
   Tape::= Registers + read-writable working space + stack (may contain initial
           data)
   Transition function::= Readonly program (machine codes)
   Initial state::= User define (usually referring to a function call) >>>>    Set of final state::= User define (usually the 'ret' instrunction of a 'TM'
                         function.

       'Halt' in classic TM should mean "states that no transition is defined".
       But in modern computers, this definition is nearly unworkable.
       On CPU machines, halt may be defined the value that Program Counter(PC)
       matches specific values (may include the pointed instruction is executed),
       and implicitly including the conditon when invalid instruction is
       encountered. Once the condition is met, end of the 'TM' definition.

  .thread/process: Not part of a TM. There is uncertainty from timing issues (
   except cooperative thread).
  .Signal(interrupt): Not part of a TM. TM has no capability accessing >>>>    information not specifed, and timing issues.
  .longjmp(..): Fine.
  .exit(int): Depends. If the TM means the whole executable, exit(int) may be fine.
  ...
  .In general, all underlying function calls and data are part of the Transition
   function and the Tape.

Example: A Halting Problem proof.

  extern int HHH(void (*)());

  void DD() {
    if(HHH(DD)) while(1);
  }

  int main() {
    HHH(DD);   // Assume HHH is a TM (halt decider)
  }

  This example of description works in some model, but not while assuming HHH is
  a TM. Because DD must be considered as data in the tape, which implies the
  contained 'HHH(DD)' are all data which may involve encoding. Thus, DD (being
  non-real TM) never halts but analyzed to halt or not.
------------------------

It need not be a TM. It merely needs to
be equivalent to a TM.

Correct. But the question is you need to prove the equivalence first.

 Kaz is correct
that a pure function ensures that a C
function is TM computable.

https://en.wikipedia.org/wiki/Pure_function
I checked this again and again several different ways
and on other forums.

Pure function theory should work. But there are still details (I think mostly
associate to precise definition) to work out. And, the basic still need to be
based on TM. For now, I think my definition above should work better.

I am not familiar with pure function, but I feel it may be based on primitive recursive function theory.

So, if you use it, you should perhaps change POOH to be presented in pure functions.
and talk nothing about TM.

That is why I provided the link that explains
it all in the first two paragraphs.
--
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-11, olcott <polcott333@gmail.com> wrote:

That is why I provided the link that explains
it all in the first two paragraphs.

Anyway, I consider it a progress that you've improved your knowledge
with regard to pure functions.

I do believe that the infinite recursive emulation with abort testing
is possible with pure functions, regardless of whether the concrete implementation in your apparatus achieves purity.

I maintain that when HHH(DD) returns 0, that makes DD terminating.

Essentially, it is /because/ everything is pure, that DD must be
terminating in every simulation level; it is always the same DD
and same HHH(DD) no matter how deep we get into simulations that
run simuations. You cannot have purity if different instances
of expressions like HHH(DD) and DD() compute something different!
Purity demands referential transparency.

Only the invasion of an impurity could wreck that!

I'm assuming that the simulation substrate is correct: it doesn't
make a mistake in stepping any x86 instruction that is generated
by the compiler you are using.

When a simulation is discontinued, that doesn't introduce any
incorrectness; in principle, the simulation can be continued again.

HHH(DD), when it is stepping DD, doesn't do anything different from DD()
on the level 0 native processor, except for ceasing to step.
But HHH ceasing to step doesn't speak to the halting status of DD;
HHH is /mistakenly/ doing that and reporting the incorrect value 0.

If you add code to keep track of all abandoned simulations, and
then have a clean-up routine step all those simulations (or just
one of them), you will see that the simulated DD will reach its
return statement (same as the natively executed one), showing that HHH
had been wrong to stop simulating it and jump to the conclusion that 0
should be returned.

I suspect that if you ever try this, and see the result, you will be
tempted not change your rhetoric, and not to speak about the experiment,
let alone publish the code, because the amount of crow you will have to
eat, and the amount of egg you will have to wipe off your face, will be
too unbearable.

But, here is the thing; people would think more of you, not less.

The bigger the wrong you are able to renounce, the bigger the estimation
of you as an thinker.
--
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/10/2025 10:33 PM, Kaz Kylheku wrote:

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

That is why I provided the link that explains
it all in the first two paragraphs.

Anyway, I consider it a progress that you've improved your knowledge
with regard to pure functions.

I have had this improved knowledge for three years.

I do believe that the infinite recursive emulation with abort testing
is possible with pure functions, regardless of whether the concrete implementation in your apparatus achieves purity.

I maintain that when HHH(DD) returns 0, that makes DD terminating.

All deciders only compute the mapping from their
input finite strings... thus the behavior of DD()
is irrelevant

It is not the behavior of some machine somewhere
else that is "represented" by the finite string.
It is the behavior that the finite string INPUT
SPECIFIES to its decider.

When simulating halt deciders are considered then
we see that DD does call HHH(DD) in recursive
simulation that cannot possibly reach its own
simulated final halt state. The same applies to
the Linz Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.

To expound on some notions in Rice's theorem
deciders accept or reject input finite strings
on the basis of a semantic or syntactic property
[of their input].

Essentially, it is /because/ everything is pure, that DD must be
terminating in every simulation level;

counter-factual, The correct execution traces prove otherwise.

it is always the same DD
and same HHH(DD) no matter how deep we get into simulations that
run simuations. You cannot have purity if different instances
of expressions like HHH(DD) and DD() compute something different!
Purity demands referential transparency.

Purity of HHH is required purity of DD is not required
if DD does not halt then DD is not pure.

Only the invasion of an impurity could wreck that!

I'm assuming that the simulation substrate is correct: it doesn't
make a mistake in stepping any x86 instruction that is generated
by the compiler you are using.

Its a world class emulator named libx86emu.
It has decades of development effort. The author
upgraded it to 32-bit memory space.

When a simulation is discontinued, that doesn't introduce any
incorrectness; in principle, the simulation can be continued again.

HHH(DD), when it is stepping DD, doesn't do anything different from DD()
on the level 0 native processor, except for ceasing to step.

When HHH1 emulates DD, then DD never calls HHH1(DD).
When HHH emulates DD, then DD calls HHH(DD) in
two levels of recursive emulation until the recursive
emulation not halting behavior pattern is matched.

But HHH ceasing to step doesn't speak to the halting status of DD;

It has always been the recursive emulation non-terminating
behavior pattern that all five LLM systems figure out on
their own without prompting.

It may seem easy to simply disbelieve the five LLMs.
What is trickier is to show that they made a mistake
when they did not make any mistake.

HHH is /mistakenly/ doing that and reporting the incorrect value 0.

Counter-factual this is still your own perpetual lack of understanding.

If you add code to keep track of all abandoned simulations, and

There is no need to do that they are all right in the
execution trace until they are all abandoned at once.

then have a clean-up routine step all those simulations (or just
one of them), you will see that the simulated DD will reach its
return statement

As soon as HHH determines that its own DD cannot possibly
reach its own "ret" instruction then the correct thing to
do is stop simulating anything. HHH is only answering
whether or not its own DD can reach its own "ret" instruction.
Once HHH determines the answer is no, then HHH is done looking.

(same as the natively executed one), showing that HHH
had been wrong to stop simulating it and jump to the conclusion that 0
should be returned.

It only seems wrong because you never bothered to
carefully study this until you have a 100% understanding:

Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern* https://github.com/plolcott/x86utm/blob/master/Halt7.c

I suspect that if you ever try this, and see the result, you will be

able to determine that you are wrong

tempted not change your rhetoric, and not to speak about the experiment,
let alone publish the code, because the amount of crow you will have to
eat, and the amount of egg you will have to wipe off your face, will be
too unbearable.

Once HHH has correctly determined that its own DD cannot
possibly reach its own "ret" instruction then HHH is 100%
done and can abort and return 0.

But, here is the thing; people would think more of you, not less.

If a counter-factual statement would make people feel
more of me this would be nauseating and make me vomit.

My whole purpose in all of this is to mathematically
formalize the notion of "true on the basis of meaning"
so that humanity could have an objective measure of truth.
Righteousness cannot exist apart from truth.

The bigger the wrong you are able to renounce, the bigger the estimation
of you as an thinker.

--
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 Thu, 11 Sep 2025 10:04:32 -0500 schrieb olcott:

On 9/10/2025 10:33 PM, Kaz Kylheku wrote:

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

Anyway, I consider it a progress that you've improved your knowledge
with regard to pure functions.

I have had this improved knowledge for three years.

No, as seen below.

I do believe that the infinite recursive emulation with abort testing
is possible with pure functions, regardless of whether the concrete
implementation in your apparatus achieves purity.
I maintain that when HHH(DD) returns 0, that makes DD terminating.

All deciders only compute the mapping from their input finite strings...
thus the behavior of DD() is irrelevant
It is not the behavior of some machine somewhere else that is
"represented" by the finite string.
It is the behavior that the finite string INPUT SPECIFIES to its
decider.

The input string doesn't specify anything else than one machine.

Essentially, it is /because/ everything is pure, that DD must be
terminating in every simulation level;

counter-factual, The correct execution traces prove otherwise.

Aborting a simulation doesn't prove anything either way.

it is always the same DD and same HHH(DD) no matter how deep we get
into simulations that run simuations. You cannot have purity if
different instances of expressions like HHH(DD) and DD() compute
something different! Purity demands referential transparency.

Purity of HHH is required purity of DD is not required if DD does not
halt then DD is not pure.

If DD is not a (pure) function, it doesn't even have a defined
halting status.

Only the invasion of an impurity could wreck that!
I'm assuming that the simulation substrate is correct: it doesn't make
a mistake in stepping any x86 instruction that is generated by the
compiler you are using.

When a simulation is discontinued, that doesn't introduce any
incorrectness; in principle, the simulation can be continued again.
HHH(DD), when it is stepping DD, doesn't do anything different from
DD() on the level 0 native processor, except for ceasing to step.

When HHH1 emulates DD, then DD never calls HHH1(DD).

DD calls HHH, whatever is simulating it. Compare:
DD1() {
HHH1(DD1);
}
Then HHH(DD1) returns "halts", different from HHH1(D1)!

If you add code to keep track of all abandoned simulations, and

There is no need to do that they are all right in the execution trace
until they are all abandoned at once.

And not afterwards.

then have a clean-up routine step all those simulations (or just one of
them), you will see that the simulated DD will reach its return
statement

As soon as HHH determines that its own DD cannot possibly reach its own
"ret" instruction then the correct thing to do is stop simulating
anything. HHH is only answering whether or not its own DD can reach its
own "ret" instruction.
Once HHH determines the answer is no, then HHH is done looking.

Yeah, that's what wrong about it. If a different analyser looked further,
it would see that DD halts, but HHH can't decide DD.

I suspect that if you ever try this, and see the result, you will be

able to determine that you are wrong

Go ahead.
--
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/11/2025 10:18 AM, joes wrote:

Am Thu, 11 Sep 2025 10:04:32 -0500 schrieb olcott:

On 9/10/2025 10:33 PM, Kaz Kylheku wrote:

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

Anyway, I consider it a progress that you've improved your knowledge
with regard to pure functions.

I have had this improved knowledge for three years.

No, as seen below.

I do believe that the infinite recursive emulation with abort testing
is possible with pure functions, regardless of whether the concrete
implementation in your apparatus achieves purity.
I maintain that when HHH(DD) returns 0, that makes DD terminating.

All deciders only compute the mapping from their input finite strings...
thus the behavior of DD() is irrelevant
It is not the behavior of some machine somewhere else that is
"represented" by the finite string.
It is the behavior that the finite string INPUT SPECIFIES to its
decider.

The input string doesn't specify anything else than one machine.

The input string to HHH(DD) does specify recursive simulation
that cannot possibly reach its own simulated final halt state.
<snip>
--
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-11, olcott <polcott333@gmail.com> wrote:

On 9/11/2025 10:18 AM, joes wrote:

Am Thu, 11 Sep 2025 10:04:32 -0500 schrieb olcott:

On 9/10/2025 10:33 PM, Kaz Kylheku wrote:

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

Anyway, I consider it a progress that you've improved your knowledge
with regard to pure functions.

I have had this improved knowledge for three years.

No, as seen below.

I do believe that the infinite recursive emulation with abort testing
is possible with pure functions, regardless of whether the concrete
implementation in your apparatus achieves purity.
I maintain that when HHH(DD) returns 0, that makes DD terminating.

All deciders only compute the mapping from their input finite strings... >>> thus the behavior of DD() is irrelevant
It is not the behavior of some machine somewhere else that is
"represented" by the finite string.
It is the behavior that the finite string INPUT SPECIFIES to its
decider.

The input string doesn't specify anything else than one machine.

The input string to HHH(DD) does specify recursive simulation
that cannot possibly reach its own simulated final halt state.

Sure it does. In the configuration in which HHH(DD) returns 0,
DD is terminating.

When run on the host (not under simulation) it readily terminates.

It will also terminate under simulation: SIM(DD) will terminate,
where SIM is a function that allocates a new set of Registers
and steps the simulaton of DD indefinitely, or until DD terminates.

HHH(DD) conducts a simulation whichis cut sort before DD reaches
its return statement.

That means nothing whatsoever; you will never convince anyone of sound
mind that the incompleteness of HHH's simulation is what determines
the halting status of DD.

When the simulation of DD is continued, the continued execution trace
will shows that the absence of conditional branching instructions
determined by HHH was premature. HHH examined too short a prefix of the execution trace and came to a prematurely wrong conclusion that there
are no branches.
--
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/11/2025 2:59 PM, Kaz Kylheku wrote:

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

On 9/11/2025 10:18 AM, joes wrote:

Am Thu, 11 Sep 2025 10:04:32 -0500 schrieb olcott:

On 9/10/2025 10:33 PM, Kaz Kylheku wrote:

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

Anyway, I consider it a progress that you've improved your knowledge >>>>> with regard to pure functions.

I have had this improved knowledge for three years.

No, as seen below.

I do believe that the infinite recursive emulation with abort testing >>>>> is possible with pure functions, regardless of whether the concrete
implementation in your apparatus achieves purity.
I maintain that when HHH(DD) returns 0, that makes DD terminating.

All deciders only compute the mapping from their input finite strings... >>>> thus the behavior of DD() is irrelevant
It is not the behavior of some machine somewhere else that is
"represented" by the finite string.
It is the behavior that the finite string INPUT SPECIFIES to its
decider.

The input string doesn't specify anything else than one machine.

The input string to HHH(DD) does specify recursive simulation
that cannot possibly reach its own simulated final halt state.

Sure it does. In the configuration in which HHH(DD) returns 0,
DD is terminating.

When measure by the semantic property of the input
finite string AKA the actual behavior that the actual
input actually specifies HHH(DD)==0 is correct.
--
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/12/2025 11:47 AM, olcott wrote:

On 9/11/2025 2:59 PM, Kaz Kylheku wrote:

Sure it does. In the configuration in which HHH(DD) returns 0,
DD is terminating.

When measure by the semantic property of the input
finite string

AKA a complete description of algorithm DD which halts, HHH(DD)==1 is
correct

--- Synchronet 3.21a-Linux NewsLink 1.2