From Newsgroup: comp.theory

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that
the input to H(D) specifies a non-halting sequence
of moves.
--
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:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

It's also not construed as failing to halt!!!

Are you daft or what.

When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that

It means jack all.

the input to H(D) specifies a non-halting sequence
of moves.

Except when you run D on a machine that doesn't have a broken
terminationa analyzer (like a native machine), D is readily shown to halt.

The simulator used by your H is faithful, so the simulated D also halts.

The termination analyzer just makes a mistake; it stops simulating
D (so D stops running) and wrongly declares that D does not halt.

D stopping running is not to be construed as either halting or
non-halting!

But the fact is that in your situation there, D is halting.

H leaves behind an abandoned simulation which can be continued,
and shown to halt, nicely under simulation and all.

The only way in which D doesn't halt is if you switch to the
retarded version of the halting question "does D, simulated
by HHH, reach its return instruction". The retarded question
demands that we regard cessation of running due to abandonment
of the stimulation as failure to reach the halting state.

That' why you only assert that cessation of running is not construed as halting---because your bizarre rhetoric needs to be able to wrongly
construe it as non-halting!!!
--
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 10/09/2025 04:41, olcott wrote:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

I have a better idea - a test harness:

#include <stdio.h>

extern int HaltingCandidate(void);

int main(void)
{
HaltingCandidate();

printf("Halted.\n");

return 0;
}

Either it halts, or it doesn't. The end.

<BS snipped>
--
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 Tue, 09 Sep 2025 22:41:32 -0500, olcott wrote:

Halting is defined as reaching a final halt state stopping running for
any other reason is not construed as halting.

When simulating termination analyzer H correctly determines D simulated
by any H cannot possibly reach its own simulated final halt state this
means that the input to H(D) specifies a non-halting sequence of moves.

H reports that D is non-halting but D halts ergo H is incorrect.

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

From Newsgroup: comp.theory

On 2025-09-10 03:41:32 +0000, olcott said:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

That does not define halting as the term "final halt state" is undefined.

Besides, many authors define halting as reacheng any configuration
where the execution cannot be continued.

When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that
the input to H(D) specifies a non-halting sequence
of moves.

It is bad style and often considered wrong to use the same symbol
for two meanings like H is used above.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 10.sep.2025 om 05:41 schreef olcott:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

As usual incomplete definitions.
A program can halt even if it specifies non-halting behaviour, due to
other causes, such as a failing computer or a failing simulator.
A program can be unable to reach the final halt state by other causes
than specified non-halting behaviour, due to other causes, such as a
failing computer or a failing simulator.

Halting behaviour is defined when a program reaches the final halt state
when allowed to run undisturbed.
Non-halting behaviour is defined when a program does not reach the final
halt state when allowed to run undisturbed.
Any disturbance, such as unplugging the power cord of the computer, or aborting the simulation before the program reaches the final halt state
is no evidence for the specification of either halting or non-halting behaviour.
If a simulation is aborted, other criteria are needed to analyse the
halting behaviour.

When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that
the input to H(D) specifies a non-halting sequence
of moves.

No, that is the thing you need to prove. Assuming that after two moves
the moves will always be repeated is just an assumption, no evidence.
That the H cannot reach the final halt state is only a failure of H.
Other simulators of exactly the same input have no problem to reach the
final halt state. This proves that the final halt state is specified and reachable.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/10/2025 12:15 AM, Kaz Kylheku wrote:

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

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

It's also not construed as failing to halt!!!

Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state. A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz

Are you daft or what.

When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that

It means jack all.

My paragraph is omniscient?

the input to H(D) specifies a non-halting sequence
of moves.

Except when you run D on a machine that doesn't have a broken
terminationa analyzer (like a native machine), D is readily shown to halt.

I am defining the non-halting criteria the above
specific way. It is like a premise to deductive
inference.

The simulator used by your H is faithful, so the simulated D also halts.

Only by not strictly obeying the semantics of the
x86 language.

_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]

The semantics of the x86 language specify that
the first five instructions of DD endlessly
repeat. There is no way around this that does
not involve cheating.

The termination analyzer just makes a mistake; it stops simulating
D (so D stops running) and wrongly declares that D does not halt.

Show the exact details of how DD emulated by HHH
according to the semantics of the x86 language
reaches its simulated "ret" instruction on its
own without intervention.

D stopping running is not to be construed as either halting or
non-halting!

But the fact is that in your situation there, D is halting.

H leaves behind an abandoned simulation which can be continued,
and shown to halt, nicely under simulation and all.

It seems to me that this is categorically impossible
without cheating.

The only way in which D doesn't halt is if you switch to the
retarded version of the halting question "does D, simulated
by HHH, reach its return instruction". The retarded question
demands that we regard cessation of running due to abandonment
of the stimulation as failure to reach the halting state.

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

Likewise we can just wait for infinite loop to
stop running at the heat death of the universe
and then say it halted?

That' why you only assert that cessation of running is not construed as halting---because your bizarre rhetoric needs to be able to wrongly
construe it as non-halting!!!

On 8/2/2024 11:32 PM, Jeff Barnett wrote:

On 8/2/2024 7:19 PM, Mike Terry wrote:

Definition: A TM P given input I is said to "halt" iff ?????
or whatever...

I think this is a rather hopeless venture without
formally defining the representation of a TM. For
example: In some formulations, there are specific
states defined as "halting states" and the machine
only halts if either the start state is a halt state or
there is a transition to a halt state within the execution
trace; In another formulation, machines halt if there
is a transition to an undefined state. Note a few things:
1) the if's above are really iff's, 2) these and many
other definitions all have equivalent computing prowess,
3) Some formulations define results by what is left on
the tape (or other storage device) while others add the
actual halting state to determine the results.

In a conversation about such topics, gentlemen of good
faith and reasonable knowledge can simple ignore these
differences and not go off the rails.

--
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/10/2025 1:03 AM, Richard Heathfield wrote:

On 10/09/2025 04:41, olcott wrote:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

I have a better idea - a test harness:

#include <stdio.h>

extern int HaltingCandidate(void);

int main(void)
{
  HaltingCandidate();

  printf("Halted.\n");

  return 0;
}

Either it halts, or it doesn't. The end.

<BS snipped>

Childish
--
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/10/2025 1:36 AM, Mr Flibble wrote:

On Tue, 09 Sep 2025 22:41:32 -0500, olcott wrote:

Halting is defined as reaching a final halt state stopping running for
any other reason is not construed as halting.

When simulating termination analyzer H correctly determines D simulated
by any H cannot possibly reach its own simulated final halt state this
means that the input to H(D) specifies a non-halting sequence of moves.

H reports that D is non-halting but D halts ergo H is incorrect.

/Flibble

Not when the halt status is measured by the
behavior that the input to HHH(DD) specifies.
--
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 10/09/2025 12:24, olcott wrote:

On 9/10/2025 1:03 AM, Richard Heathfield wrote:

On 10/09/2025 04:41, olcott wrote:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

I have a better idea - a test harness:

#include <stdio.h>

extern int HaltingCandidate(void);

int main(void)
{
   HaltingCandidate();

   printf("Halted.\n");

   return 0;
}

Either it halts, or it doesn't. The end.

<BS snipped>

Childish

Don't be an ass.

You would draw a distinction between halting and stopping! Only
an idiot would let you define halting.

My method brings halting to the workbench and sidesteps any
self-serving bullshit.

If it yields control back to main, *clearly* it 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 9/10/2025 2:57 AM, Mikko wrote:

On 2025-09-10 03:41:32 +0000, olcott said:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

That does not define halting as the term "final halt state" is undefined.

When we are in a comp.theory forum we expect people
to know the terms of the art.

Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state. A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz

Besides, many authors define halting as reacheng any configuration
where the execution cannot be continued.

On 8/2/2024 11:32 PM, Jeff Barnett wrote:

On 8/2/2024 7:19 PM, Mike Terry wrote:

Definition: A TM P given input I is said to "halt" iff ?????
or whatever...

I think this is a rather hopeless venture without
formally defining the representation of a TM. For
example: In some formulations, there are specific
states defined as "halting states" and the machine
only halts if either the start state is a halt state or
there is a transition to a halt state within the execution
trace; In another formulation, machines halt if there
is a transition to an undefined state. Note a few things:
1) the if's above are really iff's, 2) these and many
other definitions all have equivalent computing prowess,
3) Some formulations define results by what is left on
the tape (or other storage device) while others add the
actual halting state to determine the results.

In a conversation about such topics, gentlemen of good
faith and reasonable knowledge can simple ignore these
differences and not go off the rails.

When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that
the input to H(D) specifies a non-halting sequence
of moves.

It is bad style and often considered wrong to use the same symbol
for two meanings like H is used above.

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.

It takes two recursive simulations to establish
that additional recursive simulations will never 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 10/09/2025 16:51, olcott wrote:

On 9/10/2025 2:57 AM, Mikko wrote:

On 2025-09-10 03:41:32 +0000, olcott said:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

That does not define halting as the term "final halt state" is
undefined.

When we are in a comp.theory forum we expect people
to know the terms of the art.

When we are in a comp.theory newsgroup we expect people to
recognise halting when they see it.

$ cat plaindd.c
#include <stdio.h>

#define HHH(x) 0

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

int main()
{
DD();
printf("DD halted.\n");
return 0;
}
$ gcc -o plaindd plaindd.c
$ ./plaindd
DD halted.
$
--
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 Wed, 10 Sep 2025 06:25:20 -0500, olcott wrote:

On 9/10/2025 1:36 AM, Mr Flibble wrote:

On Tue, 09 Sep 2025 22:41:32 -0500, olcott wrote:

Halting is defined as reaching a final halt state stopping running for
any other reason is not construed as halting.

When simulating termination analyzer H correctly determines D
simulated by any H cannot possibly reach its own simulated final halt
state this means that the input to H(D) specifies a non-halting
sequence of moves.

H reports that D is non-halting but D halts ergo H is incorrect.

/Flibble

Not when the halt status is measured by the behavior that the input to HHH(DD) specifies.

The input to HHH is DD, HHH reports non-halting, DD halts ergo HHH is incorrect.

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

From Newsgroup: comp.theory

On 9/10/2025 11:01 AM, Mr Flibble wrote:

On Wed, 10 Sep 2025 06:25:20 -0500, olcott wrote:

On 9/10/2025 1:36 AM, Mr Flibble wrote:

On Tue, 09 Sep 2025 22:41:32 -0500, olcott wrote:

Halting is defined as reaching a final halt state stopping running for >>>> any other reason is not construed as halting.

When simulating termination analyzer H correctly determines D
simulated by any H cannot possibly reach its own simulated final halt
state this means that the input to H(D) specifies a non-halting
sequence of moves.

H reports that D is non-halting but D halts ergo H is incorrect.

/Flibble

Not when the halt status is measured by the behavior that the input to
HHH(DD) specifies.

The input to HHH is DD, HHH reports non-halting, DD halts ergo HHH is incorrect.

/Flibble

If you quit being a troll I will talk to you again.
--
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, 10 Sep 2025 11:25:19 -0500, olcott wrote:

On 9/10/2025 11:01 AM, Mr Flibble wrote:

On Wed, 10 Sep 2025 06:25:20 -0500, olcott wrote:

On 9/10/2025 1:36 AM, Mr Flibble wrote:

On Tue, 09 Sep 2025 22:41:32 -0500, olcott wrote:

Halting is defined as reaching a final halt state stopping running
for any other reason is not construed as halting.

When simulating termination analyzer H correctly determines D
simulated by any H cannot possibly reach its own simulated final
halt state this means that the input to H(D) specifies a non-halting >>>>> sequence of moves.

H reports that D is non-halting but D halts ergo H is incorrect.

/Flibble

Not when the halt status is measured by the behavior that the input to
HHH(DD) specifies.

The input to HHH is DD, HHH reports non-halting, DD halts ergo HHH is
incorrect.

/Flibble

If you quit being a troll I will talk to you again.

Facts aren't trolls, mate.

Again: the input to HHH is DD, HHH reports non-halting, DD halts ergo HHH
is incorrect.

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

From Newsgroup: comp.theory

On 9/10/2025 12:16 PM, Mr Flibble wrote:

On Wed, 10 Sep 2025 11:25:19 -0500, olcott wrote:

On 9/10/2025 11:01 AM, Mr Flibble wrote:

On Wed, 10 Sep 2025 06:25:20 -0500, olcott wrote:

On 9/10/2025 1:36 AM, Mr Flibble wrote:

On Tue, 09 Sep 2025 22:41:32 -0500, olcott wrote:

Halting is defined as reaching a final halt state stopping running >>>>>> for any other reason is not construed as halting.

When simulating termination analyzer H correctly determines D
simulated by any H cannot possibly reach its own simulated final
halt state this means that the input to H(D) specifies a non-halting >>>>>> sequence of moves.

H reports that D is non-halting but D halts ergo H is incorrect.

/Flibble

Not when the halt status is measured by the behavior that the input to >>>> HHH(DD) specifies.

The input to HHH is DD, HHH reports non-halting, DD halts ergo HHH is
incorrect.

/Flibble

If you quit being a troll I will talk to you again.

Facts aren't trolls, mate.

When I correct your misconceptions with words
that are proven completely true entirely
on the basis of their meaning and you
ignore these words then you are a troll.
--
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, 10 Sep 2025 13:14:11 -0500, olcott wrote:

On 9/10/2025 12:16 PM, Mr Flibble wrote:

On Wed, 10 Sep 2025 11:25:19 -0500, olcott wrote:

On 9/10/2025 11:01 AM, Mr Flibble wrote:

On Wed, 10 Sep 2025 06:25:20 -0500, olcott wrote:

On 9/10/2025 1:36 AM, Mr Flibble wrote:

On Tue, 09 Sep 2025 22:41:32 -0500, olcott wrote:

Halting is defined as reaching a final halt state stopping running >>>>>>> for any other reason is not construed as halting.

When simulating termination analyzer H correctly determines D
simulated by any H cannot possibly reach its own simulated final >>>>>>> halt state this means that the input to H(D) specifies a
non-halting sequence of moves.

H reports that D is non-halting but D halts ergo H is incorrect.

/Flibble

Not when the halt status is measured by the behavior that the input
to HHH(DD) specifies.

The input to HHH is DD, HHH reports non-halting, DD halts ergo HHH is
incorrect.

/Flibble

If you quit being a troll I will talk to you again.

Facts aren't trolls, mate.

When I correct your misconceptions with words that are proven completely
true entirely on the basis of their meaning and you ignore these words
then you are a troll.

Facts aren't trolls, mate.

Again: the input to HHH is DD, HHH reports non-halting, DD halts ergo HHH
is incorrect.

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

From Newsgroup: comp.theory

On Wed, 2025-09-10 at 13:14 -0500, olcott wrote:

On 9/10/2025 12:16 PM, Mr Flibble wrote:

On Wed, 10 Sep 2025 11:25:19 -0500, olcott wrote:

On 9/10/2025 11:01 AM, Mr Flibble wrote:

On Wed, 10 Sep 2025 06:25:20 -0500, olcott wrote:

On 9/10/2025 1:36 AM, Mr Flibble wrote:

On Tue, 09 Sep 2025 22:41:32 -0500, olcott wrote:

Halting is defined as reaching a final halt state stopping running
for any other reason is not construed as halting.

When simulating termination analyzer H correctly determines D simulated by any H cannot possibly reach its own simulated final halt state this means that the input to H(D) specifies a non-halting
sequence of moves.

H reports that D is non-halting but D halts ergo H is incorrect.

/Flibble

Not when the halt status is measured by the behavior that the input to
HHH(DD) specifies.

The input to HHH is DD, HHH reports non-halting, DD halts ergo HHH is incorrect.

/Flibble

If you quit being a troll I will talk to you again.

Facts aren't trolls, mate.

When I correct your misconceptions with words
that are proven completely true entirely
on the basis of their meaning and you
ignore these words then you are a troll.

I have told you, even you are god, you cannot solve the halting problem. Surrender and repent to my GUR, son.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

On 9/10/2025 12:15 AM, Kaz Kylheku wrote:

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

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

It's also not construed as failing to halt!!!

Eventually, the whole process may terminate,

No, not the "whole process"; DD() terminates.

If we faithfully interpret its x86 instructions we find that it reaches
its return statement.

HHH faithfully interprets its x86 instructions until coming to a
mistaken conclusion that DD doesn't terminate, and returning 0.

But if DD's suspended simulation is reanimated and taken farther, we
fill find that the simualted DD calls a simulated HHH, which returns 0
to it, and the simulated DD then reaches its return statement.

Now when that happens, the simulated HHH has left an incomplete
simulation of DD! If we pick that one up where it left off, we will find
the same scenario.

Ad infinitum ...

There is an infinity there, of terminating DD simulations.

HHH misinterprets that infinity as non-termination (or makes some other mistake) and returns 0.

When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that

It means jack all.

My paragraph is omniscient?

Yeah, knowing jack all is jack omniscience, sure.

the input to H(D) specifies a non-halting sequence
of moves.

Except when you run D on a machine that doesn't have a broken
terminationa analyzer (like a native machine), D is readily shown to halt. >>

I am defining the non-halting criteria the above
specific way. It is like a premise to deductive
inference.

However you define ynon-halting criteria, they are easily shown
to be incomplete.

The simulator used by your H is faithful, so the simulated D also halts.

Only by not strictly obeying the semantics of the
x86 language.

The only sense in which the semantics is not obeyed is that
the HHH function arbitrarily stops the fetch-decode-execute
cycle and returns 0.

That's not necessarily a deviation. A real x86 chip could be paused indefinitely, such that the execution can be restarted.

_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]

The semantics of the x86 language specify that
the first five instructions of DD endlessly
repeat.

No, you are just too daft to understand your own stuff.

The first five instructions execute, dispatching HHH.
Recursively, HHH begins simulating the same five instructions
again. Another recursive simulation of HHH kicks off.
But the recursive simulations are driven by the top-level
one which is single-stepping.

Eventually the top-level (incorrectly) decides that this
repetition of the five instrutions means that DD is non-terminating.
At that point it returns 0.

And, poof, the instruction pointer has gone past the five
instructions and is now on the "ADD ESP,4".

Now if we imagine that the abandoned simulation is restarted,
the same thing will happen inside that simulation.
The simulated HHH will return 0 to the simulated DD,
which will return, thereby abandoning the simulated simulation.

And then if we imagine that simulated simulation to
be continued, DD terminates again in the simulated simulation.

HHH has mistakenly concluded that because it has seen
"PUSH" and "CALL HHH" several times in the execution trace,
that there is a loop. But by returning, it has interrupted
that loop.

The loop is exactly as deep as the number of PUSH and
CALL instructions that HHH looks for. If you program HHH
to count 1000 PUSH instructions, you will get 1000 nestings
before the oldest level quits.

And then if we continue all the simulating, we will always have
1000 active levels going on, with the oldest one quitting
all the time (HHH returning 0 to DD which quits), and a new
simulation level being born.

The number of PUSHes and CALLs your halting decision looks for
determines the active depth of the nested simulation stack.

There is no way around this that does
not involve cheating.

For values of "this" being "methods used in various halting proofs",
I agree. No escape without some kind of cheating ot create
a smoke-and-mirrors illusion.

The termination analyzer just makes a mistake; it stops simulating
D (so D stops running) and wrongly declares that D does not halt.

Show the exact details of how DD emulated by HHH
according to the semantics of the x86 language
reaches its simulated "ret" instruction on its
own without intervention.

We can modify the apparatus to keep a log of all simulations that are abandoned, when HHH stoips simulating returns 0. The log could be a
linked list of simulation state objects, or whatever.

Then when HHH(DD) returns 0 inside main(), then in the main function, we
can examine the simulation objects in the log, and show that we can
continue stepping them until they terminate.

That proves they were falsely decided to be non-terminating.

More importantly perhaps, it proves that the simulated DD's are
identical to the top level DD (which you say is off limits to HHH
because it is not HHH's true input). That destroys all your false
rhetoric based on insisting that the DD simulated by HHH is special,
and different from a DD executed by the native processor.

D stopping running is not to be construed as either halting or
non-halting!

But the fact is that in your situation there, D is halting.

H leaves behind an abandoned simulation which can be continued,
and shown to halt, nicely under simulation and all.

It seems to me that this is categorically impossible
without cheating.

How so; you're the one who coded the fact that the repetition
of the initial five instructions of DD is not infinite.

You coded the fact that three PUSH instructions are detected
int he execution trace, and then HHH changes its behavior to
return 0.

(The exact details may vary; you have a lot of variations of various
code; a lot of cruft in your project. I'm just recalling one
representative example I was looking at some time ago.)



You

The only way in which D doesn't halt is if you switch to the
retarded version of the halting question "does D, simulated
by HHH, reach its return instruction". The retarded question
demands that we regard cessation of running due to abandonment
of the stimulation as failure to reach the halting state.

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

Likewise we can just wait for infinite loop to
stop running at the heat death of the universe
and then say it halted?

Infinite_Loop() is obviously non-halting.

DD() is halting when HHH(DD) returns 0 to it.

You're trying to prove something about an apple, using
an inappropriate orange analogy.

Infinite_Loop is not related to DD.

Your HHH has a loop detector that is correct enough to detect
this and return 0.

The behavior of Infinite_Loop is not tied to HHH returning a value,
or not returning.

Infinite_Loop is not built on HHH; it doesn't integrate HHH.

Stop bringing up Infinite_Loop to try to distract from the issue of DD()
being a halting computation; it makes you look desperate.
--
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 1:42 PM, Kaz Kylheku wrote:

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

On 9/10/2025 12:15 AM, Kaz Kylheku wrote:

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

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

It's also not construed as failing to halt!!!

Eventually, the whole process may terminate,

No, not the "whole process"; DD() terminates.

I was quoting Linz.

If we faithfully interpret its x86 instructions we find that it reaches
its return statement.

HHH faithfully interprets its x86 instructions until coming to a
mistaken conclusion that DD doesn't terminate, and returning 0.

But if DD's suspended simulation is reanimated and taken farther, we
fill find that the simualted DD calls a simulated HHH, which returns 0
to it, and the simulated DD then reaches its return statement.

Now when that happens, the simulated HHH has left an incomplete
simulation of DD! If we pick that one up where it left off, we will find
the same scenario.

Ad infinitum ...

There is an infinity there, of terminating DD simulations.

HHH misinterprets that infinity as non-termination (or makes some other mistake) and returns 0.

When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that

It means jack all.

My paragraph is omniscient?

Yeah, knowing jack all is jack omniscience, sure.

the input to H(D) specifies a non-halting sequence
of moves.

Except when you run D on a machine that doesn't have a broken
terminationa analyzer (like a native machine), D is readily shown to halt. >>>

I am defining the non-halting criteria the above
specific way. It is like a premise to deductive
inference.

However you define ynon-halting criteria, they are easily shown
to be incomplete.

The simulator used by your H is faithful, so the simulated D also halts. >>>

Only by not strictly obeying the semantics of the
x86 language.

The only sense in which the semantics is not obeyed is that
the HHH function arbitrarily stops the fetch-decode-execute
cycle and returns 0.

That's not necessarily a deviation. A real x86 chip could be paused indefinitely, such that the execution can be restarted.

_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]

The semantics of the x86 language specify that
the first five instructions of DD endlessly
repeat.

No, you are just too daft to understand your own stuff.

The first five instructions execute, dispatching HHH.
Recursively, HHH begins simulating the same five instructions
again. Another recursive simulation of HHH kicks off.
But the recursive simulations are driven by the top-level
one which is single-stepping.

Eventually the top-level (incorrectly) decides that this
repetition of the five instrutions means that DD is non-terminating.
At that point it returns 0.

Would it be better to keep simulating until
the heat death of the universe?
--
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:

On 9/10/2025 2:57 AM, Mikko wrote:

On 2025-09-10 03:41:32 +0000, olcott said:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

That does not define halting as the term "final halt state" is undefined.

When we are in a comp.theory forum we expect people
to know the terms of the art.

Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state.

You don't understand what you are reading. There is no rhetorical "we"
as an external agency. The Turing machine spontaneously reaches
that halt state (and nothing can be done to prevent that).

A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz

Linz is not saying that Turing machine will not enter into
a halt state if we just stop simulating it.

Whether a Turing machine enters into a halt state is a mathematical
property of the Turing machine, not a property of one of its
posible simulations.

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.

It takes two recursive simulations to establish
that additional recursive simulations will never halt.

But your apparatus changes behavior after seeing that the execution
trace contains 3 PUSH instructions and 3 CALL HHH. (Or something like
that I can't be bothered to look at that shit again).

You rigged things so that a certain number of repetitions
of the initial five instruction sequence are counted, and then
HHH aborts the simulation and returns 0. By doing that, it
has broken the repetition.

If you increase the count values you test for (for instance looking
for 200 PUSH instructions) the same thing will happen.

Your decider concludes that 200 repetitions mean forever, and
thereby breaks the loop, breaking the 200 repetition streak:
the 6th instruction is reached!

Your decider is aprt of the loop; it cannot say "I have detected
I am in a loop, therefore I'm returhing", because by doing so
it makes the claim false.

How can a world-renowned expert on self-reference such as yourself
not see this?
--
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-10, Richard Heathfield <rjh@cpax.org.uk> wrote:

On 10/09/2025 16:51, olcott wrote:

On 9/10/2025 2:57 AM, Mikko wrote:

On 2025-09-10 03:41:32 +0000, olcott said:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

That does not define halting as the term "final halt state" is
undefined.

When we are in a comp.theory forum we expect people
to know the terms of the art.

When we are in a comp.theory newsgroup we expect people to
recognise halting when they see it.

Do I have to put on a halter top and shout it from the flatbed
of a truck?
--
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 1:57 PM, Kaz Kylheku wrote:

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

On 9/10/2025 2:57 AM, Mikko wrote:

On 2025-09-10 03:41:32 +0000, olcott said:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

That does not define halting as the term "final halt state" is undefined. >>>

When we are in a comp.theory forum we expect people
to know the terms of the art.

Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state.

You don't understand what you are reading. There is no rhetorical "we"
as an external agency. The Turing machine spontaneously reaches
that halt state (and nothing can be done to prevent that).

A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz

Linz is not saying that Turing machine will not enter into
a halt state if we just stop simulating it.

Whether a Turing machine enters into a halt state is a mathematical
property of the Turing machine, not a property of one of its
posible simulations.

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.

It takes two recursive simulations to establish
that additional recursive simulations will never halt.

But your apparatus changes behavior after seeing that the execution
trace contains 3 PUSH instructions and 3 CALL HHH. (Or something like
that I can't be bothered to look at that shit again).

So you don't want an honest dialogue?
--
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/10/2025 1:42 PM, Kaz Kylheku wrote:

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

_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]

The semantics of the x86 language specify that
the first five instructions of DD endlessly
repeat.

No, you are just too daft to understand your own stuff.

The first five instructions execute, dispatching HHH.
Recursively, HHH begins simulating the same five instructions
again. Another recursive simulation of HHH kicks off.
But the recursive simulations are driven by the top-level
one which is single-stepping.

Eventually the top-level (incorrectly) decides that this
repetition of the five instrutions means that DD is non-terminating.
At that point it returns 0.

I already proved that HHH is correct when I
disabled the abort code and neither HHH nor DDD
ever stopped running.

Do you want an honest dialogue?
--
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:

On 9/10/2025 1:42 PM, Kaz Kylheku wrote:

The semantics of the x86 language specify that
the first five instructions of DD endlessly
repeat.

No, you are just too daft to understand your own stuff.

The first five instructions execute, dispatching HHH.
Recursively, HHH begins simulating the same five instructions
again. Another recursive simulation of HHH kicks off.
But the recursive simulations are driven by the top-level
one which is single-stepping.

Eventually the top-level (incorrectly) decides that this
repetition of the five instrutions means that DD is non-terminating.
At that point it returns 0.

Would it be better to keep simulating until
the heat death of the universe?

No; just until the first simulated DD shows to be halting.

The honest thing would be to change your program so that it
keeps list (e.g. linked list) of all simulations that have
been abandoned.

Then before exiting from main(), it should iterate over
all the simulations in the list, and single step each one
until it terminates.

Be sure that in DD() you have some output, like

void DD(void)
{
if (HHH(DD)) { for(;;); }
OutputString("DD reached its return statement!");
return;
}

Just watch those messages start pouring in as the cleanup code completes
the abandoned simulations.
--
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 10/09/2025 19:46, olcott wrote:

On 9/10/2025 1:42 PM, Kaz Kylheku wrote:

<snip>

Eventually the top-level (incorrectly) decides that this
repetition of the five instrutions means that DD is non-
terminating.
At that point it returns 0.

Would it be better to keep simulating until
the heat death of the universe?

It would be better to come up with a decent design. Guessing
doesn't work.
--
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 10/09/2025 20:10, olcott wrote:

<snip>

I already proved that HHH is correct when I
disabled the abort code and neither HHH nor DDD
ever stopped running.

Do you want an honest dialogue?

$ ./plaindd
DD halted.

Do you?
--
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-10, olcott <polcott333@gmail.com> wrote:

On 9/10/2025 1:42 PM, Kaz Kylheku wrote:

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

_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]

The semantics of the x86 language specify that
the first five instructions of DD endlessly
repeat.

No, you are just too daft to understand your own stuff.

The first five instructions execute, dispatching HHH.
Recursively, HHH begins simulating the same five instructions
again. Another recursive simulation of HHH kicks off.
But the recursive simulations are driven by the top-level
one which is single-stepping.

Eventually the top-level (incorrectly) decides that this
repetition of the five instrutions means that DD is non-terminating.
At that point it returns 0.

I already proved that HHH is correct when I
disabled the abort code and neither HHH nor DDD
ever stopped running.

When you disable the abort code in HHH, you are changing the definition
of HHH.

Since DD is built on HHH, DD changes also.

DD is now non-terminating.

You are confusing yourself by not using different names when changing definitions. When you change the helper function that another function
is built on, the higher level function is changing. If you want to
describe everything honestly, you should rename them all.

The modified HHH now just keeps simulating for as long as that takes
to finish a simulation, possibly forever. There is a runaway recursion. HHH(DD) starts simulating DD and will not return from it until DD
terminates. That simulated DD calls HHH(DD). That simulated HHH(DD)
starts simulating DD and will not return until that simulation
termiantes, ... etc.

There is a runaway recursion/simulation, and so, yes, never do we see
the instruction pointer go past the first five instructions of DD.

Under this new definition of HHH, DD is clearly non-terminating.
Therefore, the correct decision value is zero.

But HHH isn't returning any value, let alone the correct value; it is
failing to decide the test case, by getting into an infinite recursion/simulation.

Thus this new definition HHH is again shown not to be deciding
the new definition of DD.

Do you want an honest dialogue?

Do you mean actually honest dialogue, or just the same old
HHHonest DDialogue?
--
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-10, olcott <polcott333@gmail.com> wrote:

On 9/10/2025 1:57 PM, Kaz Kylheku wrote:

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

It takes two recursive simulations to establish
that additional recursive simulations will never halt.

But your apparatus changes behavior after seeing that the execution
trace contains 3 PUSH instructions and 3 CALL HHH. (Or something like
that I can't be bothered to look at that shit again).

So you don't want an honest dialogue?

Mainly, a dialogue with someone with a substantially better
understanding than a third grader, of midly complex computing topics,
who understands their own code and is willing to go back to it
and explore it with the mindset that it might be wrong.

Someone like that would be too embarrassed to promulgate
all this B.S. so the dialogue would be comparatively short.
--
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 4:08 AM, olcott wrote:

[...]

Do you believe in infinity?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/10/2025 4:34 AM, Richard Heathfield wrote:

On 10/09/2025 12:24, olcott wrote:

On 9/10/2025 1:03 AM, Richard Heathfield wrote:

On 10/09/2025 04:41, olcott wrote:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

I have a better idea - a test harness:

#include <stdio.h>

extern int HaltingCandidate(void);

int main(void)
{
   HaltingCandidate();

   printf("Halted.\n");

   return 0;
}

Either it halts, or it doesn't. The end.

<BS snipped>

Childish

Don't be an ass.

you forgot the hole aspect. ;^)

You would draw a distinction between halting and stopping! Only an idiot would let you define halting.

My method brings halting to the workbench and sidesteps any self-serving bullshit.

If it yields control back to main, *clearly* it halts.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

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

On 9/10/2025 1:42 PM, Kaz Kylheku wrote:

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

_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]

The semantics of the x86 language specify that
the first five instructions of DD endlessly
repeat.

No, you are just too daft to understand your own stuff.

The first five instructions execute, dispatching HHH.
Recursively, HHH begins simulating the same five instructions
again. Another recursive simulation of HHH kicks off.
But the recursive simulations are driven by the top-level
one which is single-stepping.

Eventually the top-level (incorrectly) decides that this
repetition of the five instrutions means that DD is non-terminating.
At that point it returns 0.

I already proved that HHH is correct when I
disabled the abort code and neither HHH nor DDD
ever stopped running.

When you disable the abort code in HHH, you are changing the definition
of HHH.

Since DD is built on HHH, DD changes also.

DD is now non-terminating.

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

So you think that professor Sipser is stupid?

You are confusing yourself by not using different names when changing definitions. When you change the helper function that another function
is built on, the higher level function is changing. If you want to
describe everything honestly, you should rename them all.

The modified HHH now just keeps simulating for as long as that takes
to finish a simulation, possibly forever. There is a runaway recursion. HHH(DD) starts simulating DD and will not return from it until DD
terminates. That simulated DD calls HHH(DD). That simulated HHH(DD)
starts simulating DD and will not return until that simulation
termiantes, ... etc.

There is a runaway recursion/simulation, and so, yes, never do we see
the instruction pointer go past the first five instructions of DD.

Under this new definition of HHH, DD is clearly non-terminating.
Therefore, the correct decision value is zero.

void Infinite_Recursion()
{
Infinite_Recursion();
return;
}

Its the exact same thing with Infinite_Recursion()
when we do not stupidly conflate stopping running
with halting. If a correctly simulated function
cannot possibly reach its own simulated final halt
state then as soon as we see this non-halting behavior
pattern (the five LLM systems figured this out on their
own without prompting) then we abort and return 0.

But HHH isn't returning any value, let alone the correct value; it is
failing to decide the test case, by getting into an infinite recursion/simulation.

Thus this new definition HHH is again shown not to be deciding
the new definition of DD.

Do you want an honest dialogue?

Do you mean actually honest dialogue, or just the same old
HHHonest DDialogue?

Do you think that professor Sipser is stupid?
--
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/10/2025 11:19 AM, wij wrote:

On Wed, 2025-09-10 at 13:14 -0500, olcott wrote:

On 9/10/2025 12:16 PM, Mr Flibble wrote:

On Wed, 10 Sep 2025 11:25:19 -0500, olcott wrote:

On 9/10/2025 11:01 AM, Mr Flibble wrote:

On Wed, 10 Sep 2025 06:25:20 -0500, olcott wrote:

On 9/10/2025 1:36 AM, Mr Flibble wrote:

On Tue, 09 Sep 2025 22:41:32 -0500, olcott wrote:

Halting is defined as reaching a final halt state stopping running >>>>>>>> for any other reason is not construed as halting.

When simulating termination analyzer H correctly determines D
simulated by any H cannot possibly reach its own simulated final >>>>>>>> halt state this means that the input to H(D) specifies a non-halting >>>>>>>> sequence of moves.

H reports that D is non-halting but D halts ergo H is incorrect. >>>>>>>
/Flibble

Not when the halt status is measured by the behavior that the input to >>>>>> HHH(DD) specifies.

The input to HHH is DD, HHH reports non-halting, DD halts ergo HHH is >>>>> incorrect.

/Flibble

If you quit being a troll I will talk to you again.

Facts aren't trolls, mate.

When I correct your misconceptions with words
that are proven completely true entirely
on the basis of their meaning and you
ignore these words then you are a troll.

I have told you, even you are god, you cannot solve the halting problem.

Surrender and repent to my GUR, son.

ROFL!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/10/2025 11:58 AM, Kaz Kylheku wrote:

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

On 10/09/2025 16:51, olcott wrote:

On 9/10/2025 2:57 AM, Mikko wrote:

On 2025-09-10 03:41:32 +0000, olcott said:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

That does not define halting as the term "final halt state" is
undefined.

When we are in a comp.theory forum we expect people
to know the terms of the art.

When we are in a comp.theory newsgroup we expect people to
recognise halting when they see it.

Do I have to put on a halter top and shout it from the flatbed
of a truck?

Oh my! olcott might say my soapbox is bigger. Shit man. It sure seems
like he might be totally fucked forever. Not totally sure, but wow.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/10/2025 12:07 PM, olcott wrote:

On 9/10/2025 1:57 PM, Kaz Kylheku wrote:

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

On 9/10/2025 2:57 AM, Mikko wrote:

On 2025-09-10 03:41:32 +0000, olcott said:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

That does not define halting as the term "final halt state" is
undefined.

When we are in a comp.theory forum we expect people
to know the terms of the art.

Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state.

You don't understand what you are reading. There is no rhetorical "we"
as an external agency. The Turing machine spontaneously reaches
that halt state (and nothing can be done to prevent that).

A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz

Linz is not saying that Turing machine will not enter into
a halt state if we just stop simulating it.

Whether a Turing machine enters into a halt state is a mathematical
property of the Turing machine, not a property of one of its
posible simulations.

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.

It takes two recursive simulations to establish
that additional recursive simulations will never halt.

But your apparatus changes behavior after seeing that the execution
trace contains 3 PUSH instructions and 3 CALL HHH. (Or something like
that I can't be bothered to look at that shit again).

So you don't want an honest dialogue?

PUKE!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/09/2025 20:40, Kaz Kylheku wrote:

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

On 9/10/2025 1:57 PM, Kaz Kylheku wrote:

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

It takes two recursive simulations to establish
that additional recursive simulations will never halt.

But your apparatus changes behavior after seeing that the execution
trace contains 3 PUSH instructions and 3 CALL HHH. (Or something like
that I can't be bothered to look at that shit again).

So you don't want an honest dialogue?

Mainly, a dialogue with someone with a substantially better
understanding than a third grader, of midly complex computing topics,
who understands their own code and is willing to go back to it
and explore it with the mindset that it might be wrong.

Here's hoping I qualify.

I had an idea by which I thought that HHH could avoid aborting. I
suggested it to our resident theorist, but he rejected it out of
hand. And hey, maybe rightly. But I would welcome your opinion.

The idea is based on Olcott's claim that HHH(DD) returns 0.

HHH is simulating, so it gets here...:

.int Halt_Status = HHH(DD);

and starts simulating:

..int Halt_Status = HHH(DD);

and starts simulating:

...int Halt_Status = HHH(DD);

and at some point decides to call it a day, abort the simulation,
and return 0. Well, *having made that decision*, it can now use
the axiom that two things that are equal to the same thing are
equal to each other. HHH has decided that /it/ yields 0 as a
result for DD. It can therefore save the state (push it on a
local stack, say) and replace the next simulated HHH call with a 0:

....int Halt_Status = 0;

It can now continue with the simulation.

....if (Halt_Status)
/* skip over the loop */
....return Halt_Status;

It now knows that its previous decision was wrong, so it can pop
the state, push again to make the whole thing loopable, and
replace the next simulated HHH call with a 1:

....int Halt_Status = 1;
....if (Halt_Status)
....enter the loop of death. HHH will need a way to identify the
fact, but HHH already does something akin but harder.

It now knows that its previous decision was wrong, so it can pop
the state, push again and replace the next simulated HHH call
with a 0...

If it's been keeping track, it can now announce:

puts( "N"
"eit"
"her r"
"eturn v"
"alue is c"
"onsistent w"
"ith DD's beha"
"viour. Turing w"
"as right; who cou"
"ld possibly have su"
"spected such a thing?"
);

and then we can all find something more interesting to talk about.

Someone like that would be too embarrassed to promulgate
all this B.S. so the dialogue would be comparatively short.

Er, quite so.
--
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/10/2025 2:33 PM, Kaz Kylheku wrote:

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

On 9/10/2025 1:42 PM, Kaz Kylheku wrote:

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

_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]

The semantics of the x86 language specify that
the first five instructions of DD endlessly
repeat.

No, you are just too daft to understand your own stuff.

The first five instructions execute, dispatching HHH.
Recursively, HHH begins simulating the same five instructions
again. Another recursive simulation of HHH kicks off.
But the recursive simulations are driven by the top-level
one which is single-stepping.

Eventually the top-level (incorrectly) decides that this
repetition of the five instrutions means that DD is non-terminating.
At that point it returns 0.

I already proved that HHH is correct when I
disabled the abort code and neither HHH nor DDD
ever stopped running.

When you disable the abort code in HHH, you are changing the definition
of HHH.

Since DD is built on HHH, DD changes also.

DD is now non-terminating.

Since all that I changed was removing the abort code
this unequivocally proves that this criteria has been met:

<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>
--
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/10/2025 4:06 PM, olcott wrote:

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

So you think that professor Sipser is stupid?

No, but he apparently thinks you are:

On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:

I exchanged emails with him about this. He does not agree with anything substantive that PO has written. I won't quote him, as I don't have permission, but he was, let's say... forthright, in his reply to me.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have
been aware that D is supposed to be the diagonal test case targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly
followed.

So you think that professor Sipser is stupid?

No, just you, sorry.

I'd like not to, but you're trying incredibly hard to remain in such a
regard.

Its the exact same thing with Infinite_Recursion()
when we do not stupidly conflate stopping running
with halting.

We must likewise not stupidly conflate stopping running
with non-halting, as I said.

You cannot get this just half right; the full truth
is that "stopping running" (simulation is suspended
indefinitely) has no bearing on whether the subject
is halting or non-halting.

If a correctly simulated function
cannot possibly reach its own simulated final halt
state

... due to stopping running ...

then as soon as we see this non-halting behavior

... then as soon as we see "stopping running" as a "non-halting
behavior" we are a bleeping idiot who conflates "stopping running" with
"non halting".

How can you call someone stupid for conflating "sopping running" with "halting", which at least "smell" similar, but then yourself conflate
"stopping running" with "NON-halting", which superficially look like
outright opposites!

Like, wow ...

Do you want an honest dialogue?

Do you mean actually honest dialogue, or just the same old
HHHonest DDialogue?

Do you think that professor Sipser is stupid?

Well, everyone who engages you, including myself, is obviously
stupid to some extent.
--
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-10, olcott <polcott333@gmail.com> wrote:

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

When you disable the abort code in HHH, you are changing the definition
of HHH.

Since DD is built on HHH, DD changes also.

DD is now non-terminating.

Since all that I changed was removing the abort code
this unequivocally proves that this criteria has been met:

Removing the abort code changes both of the important pieces:
the proposed decider HHH and the function DD.

We are on a different <H, D> diagonal pair.

You obviously have no idea what constitutes all the bits of
input to HHH in the expression HHH(DD).

You might be thinking that when you change some behavior in HHH, DD is
staying the same. Because you didn't touch the source code of DD, and
the machine code looks the same.

You've neglected to clarify what exactly comprises the input
to HHH in the expression HHH(DD).
--
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 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

The diagonal test case never could ever actually exist.
There never has been AN ACTUAL INPUT that does the opposite
of whatever its decider decides.

This has always been the error of conflating the behavior
of being called in recursive emulation with the behavior
of NOT being called in recursive emulation.

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Those are my own words the professor Sipser agreed
to. I spent two years writing those words, they are
unequivocal.

Separately from that, if Sisper really did say that, he might not have
been aware that D is supposed to be the diagonal test case targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly followed.

My words are a universal truism.
They prevent the error of conflating the behavior
that the actual input actually specifies with any
other behavior.

So you think that professor Sipser is stupid?

No, just you, sorry.

I know that I know what I know.
You merely presume that I am incorrect.

I'd like not to, but you're trying incredibly hard to remain in such a regard.

You are simply far too indoctrinated into the received view.
Wittgenstein has this same issue with his reviewers.

Logicians are closed minded to what they learned by rote
as if it was the infallible word of God. Philosophers of
logic like Wittgenstein are just the opposite. Unless they
can validate every single nuanced detail directly themselves
they do not accept the received view.

Its the exact same thing with Infinite_Recursion()
when we do not stupidly conflate stopping running
with halting.

We must likewise not stupidly conflate stopping running
with non-halting, as I said.

HHH is a valid termination analyzer even if it is
not a pure function of its inputs. HHH does recognize
correct non-halting behavior patterns.

You cannot get this just half right; the full truth
is that "stopping running" (simulation is suspended
indefinitely) has no bearing on whether the subject
is halting or non-halting.

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

Five different LLM systems figured this out on their
own without prompting.

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

The diagonal test case never could ever actually exist.

That's because a prerequisite for that case to exist would be for the
total halt decider it's built on to exist.

So you've once again agreed that Turing and Linz are correct.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you, obviously
does believe that diagonal test cases can actually exist?
--
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 11/09/2025 01:11, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have
been aware that D is supposed to be the diagonal test case targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly followed.

My explanation is Sipser is considering a general H and a general input D. When he says "...its
simulated D would never stop running unless aborted..." he is naturally talking about criteria that
can be applied to determine non-halting *OF INPUT D*, and no other input.

The point being he is (obviously) NOT saying that if input D is changed to some other D2, and D2
would not halt unless aborted, then H may decide that D is non-halting. His remark applies
generally, even to PO's HHH/DD which are related in a particular way, PROVIDED DD is not changed
into a new DD2 as part of the consideration. [Sure enough UTM(DD) halts, in disagreement with PO's
conclusion.]

In effect Sipser was just saying "if H determines that UTM(D) would never halt, it is ok for H to
decide D never halts". That is honest, and relevant when engaged in a discussion of how a
simulating halt decider might make certain halting decisions.

PO knows that Sipser would not support his arguments, but continues frequently citing him in some
kind of false appeal to authority. It's a morally feeble attempt to try to shut down lines of
reasoning he doesn't like (but doesn't know how to counter himself) /at Sipser's expense/. Now
recently he brings Sipser's professional reputation into his argument, knowing Sipser is not here,
and is not going to come here to call him out.

While I don't like base insults being directed at people, I can't help thinking that a typical
reader would be thinking "PO - what a human TURD that guy is!". (I'm not suggesting that of course...)


Mike.

So you think that professor Sipser is stupid?

No, just you, sorry.

I'd like not to, but you're trying incredibly hard to remain in such a regard.

Its the exact same thing with Infinite_Recursion()
when we do not stupidly conflate stopping running
with halting.

We must likewise not stupidly conflate stopping running
with non-halting, as I said.

You cannot get this just half right; the full truth
is that "stopping running" (simulation is suspended
indefinitely) has no bearing on whether the subject
is halting or non-halting.

If a correctly simulated function
cannot possibly reach its own simulated final halt
state

... due to stopping running ...

then as soon as we see this non-halting behavior

... then as soon as we see "stopping running" as a "non-halting
behavior" we are a bleeping idiot who conflates "stopping running" with
"non halting".

How can you call someone stupid for conflating "sopping running" with "halting", which at least "smell" similar, but then yourself conflate "stopping running" with "NON-halting", which superficially look like
outright opposites!

Like, wow ...

Do you want an honest dialogue?

Do you mean actually honest dialogue, or just the same old
HHHonest DDialogue?

Do you think that professor Sipser is stupid?

Well, everyone who engages you, including myself, is obviously
stupid to some extent.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/10/2025 7:57 PM, Mike Terry wrote:

On 11/09/2025 01:11, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have
been aware that D is supposed to be the diagonal test case targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision.  Had that been pointed out, a corection would have swiftly
followed.

My explanation is Sipser is considering a general H and a general input
D.  When he says "...its simulated D would never stop running unless aborted..." he is naturally talking about criteria that can be applied
to determine non-halting *OF INPUT D*, and no other input.

Yet input D can be anything it is an arbitrary placeholder.

The point being he is (obviously) NOT saying that if input D is changed
to some other D2, and D2 would not halt unless aborted, then H may
decide that D is non-halting.  His remark applies generally, even to
PO's HHH/DD which are related in a particular way, PROVIDED DD is not changed into a new DD2 as part of the consideration.  [Sure enough
UTM(DD) halts, in disagreement with PO's conclusion.]

None the less when I comment out the abort code
of HHH and this causes DD() to never stop running
we have one independent variable with two values:
abort / do not abort and one dependent variable
with two corresponding values: stop running /
never stop running.

In effect Sipser was just saying "if H determines that UTM(D) would
never halt, it is ok for H to decide D never halts".  That is honest,
and relevant when engaged in a discussion of how a simulating halt
decider might make certain halting decisions.

Not quite. H is the UTM with added features.
We must take into account that when DD calls
HHH(DD) that this does specify behavior that
cannot stop running unless aborted.

PO knows that Sipser would not support his arguments,

That is counter-factual.
Professor Sipser merely has not taken the
time to understand the recursive simulation
non-halting behavior pattern so he has no
way to see any significance to my work.

but continues
frequently citing him in some kind of false appeal to authority.  It's a morally feeble attempt to try to shut down lines of reasoning he doesn't like (but doesn't know how to counter himself) /at Sipser's expense/.
Now recently he brings Sipser's professional reputation into his
argument, knowing Sipser is not here, and is not going to come here to
call him out.

Now I have a better way of saying the same thing
I only refer back to Professor Sipser's agreement
to show another way that proves that I am correct.
The meaning of my words has always proved that
I am correct.

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

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you, obviously
does believe that diagonal test cases can actually exist?

I just discovered this when I was spending
December to May getting chemo therapy, radiation
therapy and CAR-T cell therapy in Minnesota.

There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.

This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.

Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.
--
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/10/2025 7:57 PM, Mike Terry wrote:

On 11/09/2025 01:11, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have
been aware that D is supposed to be the diagonal test case targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision.  Had that been pointed out, a corection would have swiftly
followed.

My explanation is Sipser is considering a general H and a general input
D.  When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied
to determine non-halting *OF INPUT D*, and no other input.

Yet input D can be anything it is an arbitrary placeholder.

(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)

But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.

Paraphrase:

If a halt decider /correctly/ determine, by /correctly/ simulating its
input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.

We have an logical if here:

"If it can correctly simulate ... determine, ... THEN it can reject"

IF P THEN Q

P -> Q

Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.

P Q P -> Q
F F T
F T T
T F F
T T T

In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.

Thus P is false.

If P is false then P -> Q is true.

Therefore, it is reasonable to agree with P -> Q.

"If unicorns exist, then pigs fly" --- I don't disagree!

However, there are some reasons to believe we can hit the "T F"
case of the truth table.

Suppose that H correctly determines the halting status of D. H cannot
report that. It has to keep it to itself and not return. In that case,
H can stop the simulation of D, but just cannot itself terminate; if it
returns anything to D, it is automatically wrong.

In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)

It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?

If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.

If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that
proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.

The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is observable, or the fact that the function is not returning. Therefore
the former camp is more on the correct side (H is not deemed to have
correctly determined anything until it returns) and can agree with
your verbatim text.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you, obviously
does believe that diagonal test cases can actually exist?

I just discovered this when I was spending
December to May getting chemo therapy, radiation
therapy and CAR-T cell therapy in Minnesota.

There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.

This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.

Nope; the input, such as DD, fully encapsulates the
entire decider HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body.
It is built on it.

There is no "trompe d'oeil", like a hand reaching out
of the picture to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp
can copy itself: "/bin/cp /bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input
to /bin/cp.

Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You say you disagree: that it wouldn't happen that way.

I suspect you understand the explanations very well, and
are just too scared to try it.
--
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-10 15:51:21 +0000, olcott said:

On 9/10/2025 2:57 AM, Mikko wrote:

On 2025-09-10 03:41:32 +0000, olcott said:

Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.

That does not define halting as the term "final halt state" is undefined.

When we are in a comp.theory forum we expect people
to know the terms of the art.

Different authors use different definitions. Although the definitions
are essentially equivalent there are sifferences that may be important
in some cases.

Readers should know that a incomplete or missing definitions are often
used by charlatans in preparation of a equivocation deception.

Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state. A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz

The above quote contains a definition: "A Turing machine is said
to halt whenever it reaches a configuration for which δ is not
defined", where δ is in the original context deifned as the
partial function that maps configurations to other configurations
but may be undefined for some (or even all) configurations.

Besides, many authors define halting as reacheng any configuration
where the execution cannot be continued.

As noted above, Linz is one of those may authors.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

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

On 9/10/2025 7:57 PM, Mike Terry wrote:

On 11/09/2025 01:11, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have >>>> been aware that D is supposed to be the diagonal test case targeting H, >>>> such that D is built on top of H, and D's behavior depends on H's
decision.  Had that been pointed out, a corection would have swiftly
followed.

My explanation is Sipser is considering a general H and a general input
D.  When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied
to determine non-halting *OF INPUT D*, and no other input.

Yet input D can be anything it is an arbitrary placeholder.

(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)

But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.

Paraphrase:

If a halt decider /correctly/ determine, by /correctly/ simulating its
input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.

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

HHH(DD) simulates DD that call HHH(DD) then
HHH(DD) simulates DD that call HHH(DD)

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

To get over the issue of the static data we call
HHH a termination analyzer instead of a halt decider.

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

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you, obviously
does believe that diagonal test cases can actually exist?

I just discovered this when I was spending
December to May getting chemo therapy, radiation
therapy and CAR-T cell therapy in Minnesota.

There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.

This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.

Nope; the input, such as DD, fully encapsulates the
entire decider HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body.
It is built on it.

There is no "trompe d'oeil", like a hand reaching out
of the picture to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp
can copy itself: "/bin/cp /bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input
to /bin/cp.

Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD)
matches this recursive simulation non halting behavior
pattern:

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

that it has answered the only question that it
was asking: Does my input DD specify behavior
reach reaches its own final halt state?

At that point it is required to stop simulating
anything.

You say you disagree: that it wouldn't happen that way.

I suspect you understand the explanations very well, and
are just too scared to try it.

I have been over these same points hundreds of more
times than you have. Each time I check and recheck.
My IQ really is the same as an average MD. By checking
and rechecking my work I put a transmission on my mind
such the more time spent raises my effective IQ.

When I spend 12 hours per day 7 days per week for
ten years sharply focused on a problem I beat anyone
with a 180 IQ that only spent six months at 40 hours
per week. True greatness can only be achieved by a
very abnormally high focus of concentration. Most
people are simply not wired that way.
--
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:30:40 -0500 schrieb olcott:

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

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

Without the execution trace that a simulating termination analyzer
provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this
recursive simulation non halting behavior pattern:

that it has answered the only question that it was asking: Does my input
DD specify behavior reach reaches its own final halt state?
At that point it is required to stop simulating anything.

Not really. It could simulate further, as long is still halts and
returns this value, although there would be no point.

You say you disagree: that it wouldn't happen that way.
I suspect you understand the explanations very well, and are just too
scared to try it.

I have been over these same points hundreds of more times than you have.
Each time I check and recheck. My IQ really is the same as an average
MD. By checking and rechecking my work I put a transmission on my mind
such the more time spent raises my effective IQ.
When I spend 12 hours per day 7 days per week for ten years sharply
focused on a problem I beat anyone with a 180 IQ that only spent six
months at 40 hours per week. True greatness can only be achieved by a
very abnormally high focus of concentration. Most people are simply not
wired that way.

There'd be no need to recheck if you had already convinced yourself.
You basically can't change your IQ; people with an IQ of 180 don't exist
and intelligence isn't the same as knowledge. The HP also isn't that deep.
--
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:52 AM, joes wrote:

Am Thu, 11 Sep 2025 10:30:40 -0500 schrieb olcott:

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

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

Without the execution trace that a simulating termination analyzer
provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this
recursive simulation non halting behavior pattern:

that it has answered the only question that it was asking: Does my input
DD specify behavior reach reaches its own final halt state?
At that point it is required to stop simulating anything.

Not really. It could simulate further, as long is still halts and
returns this value, although there would be no point.

It could simulate until just before the heat death of
the universe and then finally report that DD does not halt.
I merely coded it to report as soon as it can do this correctly.

You say you disagree: that it wouldn't happen that way.
I suspect you understand the explanations very well, and are just too
scared to try it.

I have been over these same points hundreds of more times than you have.
Each time I check and recheck. My IQ really is the same as an average
MD. By checking and rechecking my work I put a transmission on my mind
such the more time spent raises my effective IQ.
When I spend 12 hours per day 7 days per week for ten years sharply
focused on a problem I beat anyone with a 180 IQ that only spent six
months at 40 hours per week. True greatness can only be achieved by a
very abnormally high focus of concentration. Most people are simply not
wired that way.

There'd be no need to recheck if you had already convinced yourself.
You basically can't change your IQ; people with an IQ of 180 don't exist
and intelligence isn't the same as knowledge. The HP also isn't that deep.

I have verified directly to myself that one can increase
one's effective IQ in a specific narrow subject matter field.

When one goes over the details of this subject matter many
many times it is clear that deeper and deeper insights do
occur. https://www.rd.com/list/highest-iq-in-the-world/

It is well documented that I have been working on the subject
of the halting problem and other problems of pathological
self-reference since 2004. It just occurred to me in the
last nine months that I discovered

There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.

This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.

Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.
--
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 Thu, 11 Sep 2025 11:38:22 -0500, olcott wrote:

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

Am Thu, 11 Sep 2025 10:30:40 -0500 schrieb olcott:

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

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

Without the execution trace that a simulating termination analyzer
provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this
recursive simulation non halting behavior pattern:

that it has answered the only question that it was asking: Does my
input DD specify behavior reach reaches its own final halt state?
At that point it is required to stop simulating anything.

Not really. It could simulate further, as long is still halts and
returns this value, although there would be no point.

It could simulate until just before the heat death of the universe and
then finally report that DD does not halt.
I merely coded it to report as soon as it can do this correctly.

But DD halts so it didn't report correctly.

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

From Newsgroup: comp.theory

On 9/11/2025 11:45 AM, Mr Flibble wrote:

On Thu, 11 Sep 2025 11:38:22 -0500, olcott wrote:

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

Am Thu, 11 Sep 2025 10:30:40 -0500 schrieb olcott:

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

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

Without the execution trace that a simulating termination analyzer >>>>>> provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this
recursive simulation non halting behavior pattern:

that it has answered the only question that it was asking: Does my
input DD specify behavior reach reaches its own final halt state?
At that point it is required to stop simulating anything.

Not really. It could simulate further, as long is still halts and
returns this value, although there would be no point.

It could simulate until just before the heat death of the universe and
then finally report that DD does not halt.
I merely coded it to report as soon as it can do this correctly.

But DD halts so it didn't report correctly.

/Flibble

That is the very subtle fallacy of equivocation error
that has been perpetuated by every textbook on the subject.

All deciders only compute the mapping from their
input finite strings...

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].
--
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 Thu, 11 Sep 2025 11:57:45 -0500, olcott wrote:

On 9/11/2025 11:45 AM, Mr Flibble wrote:

On Thu, 11 Sep 2025 11:38:22 -0500, olcott wrote:

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

Am Thu, 11 Sep 2025 10:30:40 -0500 schrieb olcott:

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

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

Without the execution trace that a simulating termination analyzer >>>>>>> provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this
recursive simulation non halting behavior pattern:

that it has answered the only question that it was asking: Does my
input DD specify behavior reach reaches its own final halt state? At >>>>> that point it is required to stop simulating anything.

Not really. It could simulate further, as long is still halts and
returns this value, although there would be no point.

It could simulate until just before the heat death of the universe and
then finally report that DD does not halt.
I merely coded it to report as soon as it can do this correctly.

But DD halts so it didn't report correctly.

/Flibble

That is the very subtle fallacy of equivocation error that has been perpetuated by every textbook on the subject.

All deciders only compute the mapping from their input finite strings...

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

Nope. HHH(DD) reports that DD doesn't halt but DD halts ergo HHH is
incorrect.

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

From Newsgroup: comp.theory

On 11/09/2025 17:38, olcott wrote:

<snip>

[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.

It would still be wrong. DD halts.

I merely coded it to report as soon as it can do this correctly.

It can't.

<snip>

There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.

That's because ACTUAL INPUT that does the Turing Twist doesn't
have a decider. We have a proof.

This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.

No, the error is in believing you have a decider into which you
can input.

Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.

Your simulating termination analyser gets the answer wrong, so I
don't suppose anyone is going to trust it very much.
--
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 11/09/2025 04:17, Kaz Kylheku wrote:

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

On 9/10/2025 7:57 PM, Mike Terry wrote:

On 11/09/2025 01:11, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have >>>> been aware that D is supposed to be the diagonal test case targeting H, >>>> such that D is built on top of H, and D's behavior depends on H's
decision.� Had that been pointed out, a corection would have swiftly
followed.

My explanation is Sipser is considering a general H and a general input
D.� When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied
to determine non-halting *OF INPUT D*, and no other input.

Yet input D can be anything it is an arbitrary placeholder.

(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)

But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.

Paraphrase:

If a halt decider /correctly/ determine, by /correctly/ simulating its
input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.

We have an logical if here:

"If it can correctly simulate ... determine, ... THEN it can reject"

IF P THEN Q

P -> Q

Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.

P Q P -> Q
F F T
F T T
T F F
T T T

In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.

Thus P is false.

If P is false then P -> Q is true.

Therefore, it is reasonable to agree with P -> Q.

"If unicorns exist, then pigs fly" --- I don't disagree!

However, there are some reasons to believe we can hit the "T F"
case of the truth table.

Suppose that H correctly determines the halting status of D. H cannot
report that. It has to keep it to itself and not return. In that case,
H can stop the simulation of D, but just cannot itself terminate; if it returns anything to D, it is automatically wrong.

In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)

It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?

If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.

If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.

The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is observable, or the fact that the function is not returning. Therefore
the former camp is more on the correct side (H is not deemed to have correctly determined anything until it returns) and can agree with
your verbatim text.

I think I'm on safe grounds predicting that Sipser is considering deciding to mean reporting the
decision and halting. And of course an H which never returns is not a halt decider in the sense of
the HP.

But your idea of internally determining something made me think: is it easy to actually do that in
practice? It seems so to me.

H can be coded to examine its input computation. If it sees that it has no reachable code path that
leads to any final state, it can be said to "know" (or have "determined") at that point that its
input is non-halting - if we like we could say it must pass through a designated "I've worked out
the input doesn't halt" state to "register" its discovery. Regardless of the previous test
succeeding, H then loops.

So now we construct the diagonal machine D, which embeds H algorithm. H(D) never halts, and so D
never halts. Moreover, D() has no reachable code path that returns, and that fact can be correctly
ascertained by code in H, so H (coded appropriately) can "determine" that D() never halts and
register this, before continuing with its infinite loop.

Conclusion: H has correctly proved (internally) that D() does not halt, and registered that by
passing through its designated state. And indeed D() never halts as proved (internally) by H.

For comparison we could imaging an H that (regardless of input) just "registers" that the input
never halts, then enters an infinite loop. That's much simpler! But... while this H /correctly/
registers that its associated diagonal D() never halts, it can't be said to have "seen"/"determined"
that it halts, as you required(??), because there are alternative inputs which H will also register
as never halting but will in fact halt.

[OK, I'm not sure if you used the word "determined" in the stronger sense I interpreted it, or in
the weaker sense of H simply being "correct for the case being considered" without any
justification. My H which looks for reachable terminating code paths works with the stronger
"determined" interpretation.]


Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

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

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

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you, obviously >>>> does believe that diagonal test cases can actually exist?

I just discovered this when I was spending
December to May getting chemo therapy, radiation
therapy and CAR-T cell therapy in Minnesota.

There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.

This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.

Nope; the input, such as DD, fully encapsulates the
entire decider HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body.
It is built on it.

There is no "trompe d'oeil", like a hand reaching out
of the picture to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp
can copy itself: "/bin/cp /bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input
to /bin/cp.

Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD)
matches this recursive simulation non halting behavior
pattern:

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

Here is what you don't understand. In every recursive
simulation level. your HHH(DD) returns 0.

Each recursive simulation level has a *parent* HHH(DD)
which is simualting it.

That parent HHH(DD) fails to simulate the child DD, with its HH(DD)
far enough to get to the part where HH(DD) returns 0.

Until that point, it thinks it is seeing the correct conditions
for an infinitely recursive simulation.

All your simulation levels apply their abort condition
just short of the correct depth to see that the next level
below terminates.

You can't escape that. You could put in a counter to count more
levels before aborting. 15, 20, ... but the simulation would
always shot itself halting at the one level deeper than that.

My IQ really is the same as an average MD.

Maybe it once was, but you have evidently suffered enough cognitive
decline that you're down to the average naturopath.

By checking
and rechecking my work I put a transmission on my mind
such the more time spent raises my effective IQ.

All software organizations that know what they are doing
have their engineers check each other's work. Regardless
of IQ, people are blind go their own bugs when they
develop code.

When I spend 12 hours per day 7 days per week for
ten years sharply focused on a problem I beat anyone
with a 180 IQ that only spent six months at 40 hours
per week.

That is false. A difference in intelligence isn't something you can make
up for in /quantity/ of effort; it is a /qualitative/ difference.

You could spend years toiling on something that a smarter
mind will see through in an instant.

True greatness can only be achieved by a
very abnormally high focus of concentration.

Mainly by a combination genetics, youth, and a privileged background
full of opportunities.
--
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-11, olcott <polcott333@gmail.com> wrote:

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

Not correctly though. Once that condition fires, and the
simulation is abandoned, it is failing to see that if the
simulation were continued, the simulated HHH(DD) would
return and proceed to the conditional instruction.

You know this is true, but you would rather look brutally
stupid than to admit being wrong.

Like I said, someone will come along and demonstrate what
I'm talking about using your own code, and you will have
your ass handed to you at that point.
--
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 12:06 PM, Mike Terry wrote:

On 11/09/2025 04:17, Kaz Kylheku wrote:

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

On 9/10/2025 7:57 PM, Mike Terry wrote:

On 11/09/2025 01:11, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have >>>>> been aware that D is supposed to be the diagonal test case
targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision.  Had that been pointed out, a corection would have swiftly >>>>> followed.

My explanation is Sipser is considering a general H and a general input >>>> D.  When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied >>>> to determine non-halting *OF INPUT D*, and no other input.

Yet input D can be anything it is an arbitrary placeholder.

(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)

But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.

Paraphrase:

   If a halt decider /correctly/ determine, by /correctly/ simulating its >>    input that the input doesn't halt, then a halt decicer
   can stop the simulation and reject the input.

We have an logical if here:

    "If it can correctly simulate ... determine, ... THEN it can reject" >>
    IF P THEN Q

    P -> Q

Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.

    P   Q    P -> Q
    F   F      T
    F   T      T
    T   F      F
    T   T      T

In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.

Thus P is false.

If P is false then P -> Q is true.

Therefore, it is reasonable to agree with P -> Q.

"If unicorns exist, then pigs fly" --- I don't disagree!

However, there are some reasons to believe we can hit the "T F"
case of the truth table.

Suppose that H correctly determines the halting status of D.  H cannot
report that. It has to keep it to itself and not return.  In that case,
H can stop the simulation of D, but just cannot itself terminate; if it
returns anything to D, it is automatically wrong.

In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)

It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?

If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.

If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that
proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.

The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is
observable, or the fact that the function is not returning.  Therefore
the former camp is more on the correct side (H is not deemed to have
correctly determined anything until it returns) and can agree with
your verbatim text.

I think I'm on safe grounds predicting that Sipser is considering
deciding to mean reporting the decision and halting.  And of course an H which never returns is not a halt decider in the sense of the HP.

But your idea of internally determining something made me think: is it
easy to actually do that in practice?  It seems so to me.

H can be coded to examine its input computation.  If it sees that it has
no reachable code path that leads to any final state, it can be said to "know" (or have "determined") at that point that its input is non-
halting - if we like we could say it must pass through a designated
"I've worked out the input doesn't halt" state to "register" its discovery.  Regardless of the previous test succeeding, H then loops.

So now we construct the diagonal machine D, which embeds H algorithm.
H(D) never halts, and so D never halts.  Moreover, D() has no reachable code path that returns, and that fact can be correctly ascertained by
code in H, so H (coded appropriately) can "determine" that D() never
halts and register this, before continuing with its infinite loop.

Conclusion: H has correctly proved (internally) that D() does not halt,
and registered that by passing through its designated state.  And indeed D() never halts as proved (internally) by H.

For comparison we could imaging an H that (regardless of input) just "registers" that the input never halts, then enters an infinite loop. That's much simpler!  But... while this H /correctly/ registers that its associated diagonal D() never halts, it can't be said to have "seen"/"determined" that it halts, as you required(??), because there
are alternative inputs which H will also register as never halting but
will in fact halt.

[OK, I'm not sure if you used the word "determined" in the stronger
sense I interpreted it, or in the weaker sense of H simply being
"correct for the case being considered" without any justification.  My H which looks for reachable terminating code paths works with the stronger "determined" interpretation.]

Even an approach like the one you sketch here is unlikely to be
practical for very much. Consider just one class of problems that you
will not be able to deal with: State A conditionally "branches" to state
B but no state B is defined. This is only a problem if 1) there is a
path to state A and 2) its possible that the specified character is
under the read head. Both are equivalent to th original halting problem.

Many similar situations, some simpler to spot and others much more
difficult, are buried. Even if you want to make it the responsibility of
the problem presenter to remove problems of well-formdness you've just transformed the impossible problems to the presenter. Consider when a
new TM is formed by pipe-lining other TM's as is done in many proofs;
that process frequently introduces unreachable states and branches that
can't be followed.

There are formal approaches that can make some progress. For example, a tool-set that tries to help you compute an algorithm's complexity by
trying to help you guess loop invariants and solving the combining of complexity formulas along execution paths. Exercises with such a tool
may help one establish complexity (halting) or find cases where that is impossible. Such insights might help determining halting in cases of
practical interest. But no guarantees. Naturally!
--
Jeff Barnett

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-11, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

On 11/09/2025 04:17, Kaz Kylheku wrote:

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

On 9/10/2025 7:57 PM, Mike Terry wrote:

On 11/09/2025 01:11, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have >>>>> been aware that D is supposed to be the diagonal test case targeting H, >>>>> such that D is built on top of H, and D's behavior depends on H's
decision.  Had that been pointed out, a corection would have swiftly >>>>> followed.

My explanation is Sipser is considering a general H and a general input >>>> D.  When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied >>>> to determine non-halting *OF INPUT D*, and no other input.

Yet input D can be anything it is an arbitrary placeholder.

(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)

But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.

Paraphrase:

If a halt decider /correctly/ determine, by /correctly/ simulating its
input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.

We have an logical if here:

"If it can correctly simulate ... determine, ... THEN it can reject"

IF P THEN Q

P -> Q

Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.

P Q P -> Q
F F T
F T T
T F F
T T T

In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.

Thus P is false.

If P is false then P -> Q is true.

Therefore, it is reasonable to agree with P -> Q.

"If unicorns exist, then pigs fly" --- I don't disagree!

However, there are some reasons to believe we can hit the "T F"
case of the truth table.

Suppose that H correctly determines the halting status of D. H cannot
report that. It has to keep it to itself and not return. In that case,
H can stop the simulation of D, but just cannot itself terminate; if it
returns anything to D, it is automatically wrong.

In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)

It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?

If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.

If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that
proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.

The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is
observable, or the fact that the function is not returning. Therefore
the former camp is more on the correct side (H is not deemed to have
correctly determined anything until it returns) and can agree with
your verbatim text.

I think I'm on safe grounds predicting that Sipser is considering deciding to mean reporting the
decision and halting. And of course an H which never returns is not a halt decider in the sense of
the HP.

But your idea of internally determining something made me think: is it easy to actually do that in
practice? It seems so to me.

With side effects, it is possible. Then we don't have pure functions any more.

E.g. the decider can do this:

puts("I know this doesn't halt, but I can't return because that would change the result.");
for(;;)/**/;

In order to have act on this output, we would have to wrap the decider
with a procedure which captures it. And at that point we again have a
decider that succumbs to diagonalization.

Conclusion: H has correctly proved (internally) that D() does not halt, and registered that by
passing through its designated state. And indeed D() never halts as proved (internally) by H.

That passage through the state has to be externally observable in order
to exist meaningfully in the world, which makes it an effect.

There is one detail we have to consider. Suppose a decider passes
through its special observable state in such a way that it indicates
one decision (e.g. "reject"), but then later returns with the opposite
decision (e.g. "accept"). Do we consider the decider to be
contradicting itself and deem it to be wrong? It would make sense to
impose the rule that if the decider chooses to pass through a
designated state indicating that has made a determination, then that
decider must either not return, or return the same determination, or
else it is not a decider.

The state being externally observable to the world makes it observable
to the diagonal program D also:

D() {
process h = coprocess { H(D) }

switch (wait_for_event(h)) {
case TERMINATED_ACCEPT:
for(;;);
case TERMINATED_REJECT:
return;
case OBSERVED_INTERNAL_ACCEPT:
kill(h);
for(;;);
case OBSERVED_INTERNAL_REJECT:
kill(h);
return;
}
}

Using the process handle h, D monitors for two events that can
arrive in any order: 1) H(D) terminates with a status or 2)
H(D) passes through its observable state, making it known what
it thinks about the termination.

In situation (1), D just "behaves opposite" like a regular
diagonalization program built in pure functions with no
observable state.

In situation (2), D can also "behave opposite". If the coprocess h
has passed through an observable state which says "reject",
then D can terminate h, and return, showing that "reject" is wrong.
In the "accept" case, D can go into an infinite loop.

What if we change the rules to allow h to change its mind, such that
when it terminates, the final decision is the one we must take; the
observable passage through the state is a tentative, interim result that applies while it has not yet terminated? Furthermore, it then matters
whether h is killed; so what if we disallow that?

That creates a difficulty for D. If it observes the interim result
of "reject", it cannot bail out to contradict it. Bailing out
is the last thing it does, after which h can switch to an
"accept" verdict. If D observes an "accept" interim result,
that's easier; it just has to stay looping, thereby maintaining
a contradiction.

The problem with a decider that's allowed to change its mind is that it
takes away authority from the interim decision. If the decider posts the interim decision and then fails to terminate, we must decide between
accepting the interim decision and waiting longer, which is just
one of the faces of undecidability.
--
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 5:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have
been aware that D is supposed to be the diagonal test case targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly followed.

So you think that professor Sipser is stupid?

No, just you, sorry.

I'd like not to, but you're trying incredibly hard to remain in such a regard.

Its the exact same thing with Infinite_Recursion()
when we do not stupidly conflate stopping running
with halting.

We must likewise not stupidly conflate stopping running
with non-halting, as I said.

You cannot get this just half right; the full truth
is that "stopping running" (simulation is suspended
indefinitely) has no bearing on whether the subject
is halting or non-halting.

If a correctly simulated function
cannot possibly reach its own simulated final halt
state

... due to stopping running ...

then as soon as we see this non-halting behavior

... then as soon as we see "stopping running" as a "non-halting
behavior" we are a bleeping idiot who conflates "stopping running" with
"non halting".

How can you call someone stupid for conflating "sopping running" with "halting", which at least "smell" similar, but then yourself conflate "stopping running" with "NON-halting", which superficially look like
outright opposites!

Like, wow ...

Do you want an honest dialogue?

Do you mean actually honest dialogue, or just the same old
HHHonest DDialogue?

Do you think that professor Sipser is stupid?

Well, everyone who engages you, including myself, is obviously
stupid to some extent.

Shit.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-10 21:17, Kaz Kylheku wrote:

Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.

P Q P -> Q
F F T
F T T
T F F
T T T

Just to warn you, you're venturing into dangerous territory here. Among Olcott's many peculiarities is the fact that in the past he has rejected
the above truth table (though it's never been clear what he wants to
replace it with).

André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On Thu, 2025-09-11 at 16:05 -0600, André G. Isaak wrote:

On 2025-09-10 21:17, Kaz Kylheku wrote:

Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.

    P   Q    P -> Q
    F   F      T
    F   T      T
    T   F      F
    T   T      T

Just to warn you, you're venturing into dangerous territory here. Among Olcott's many peculiarities is the fact that in the past he has rejected
the above truth table (though it's never been clear what he wants to
replace it with).

André

And latter, I found olcott does not even understand X&~X (olcott can copy,
but does not understand what contradiction is)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/11/2025 12:12 PM, Richard Heathfield wrote:

On 11/09/2025 17:38, olcott wrote:

<snip>

[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.

It would still be wrong. DD halts.

I carefully explain all of the details of how
this is incorrect and you don't hear a single word.

Presuming that I must be wrong without finding a
single error in the reasoning of my basis counts
as less then no rebuttal at all.
--
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/11/2025 2:04 PM, Kaz Kylheku wrote:

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

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

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you, obviously >>>>> does believe that diagonal test cases can actually exist?

I just discovered this when I was spending
December to May getting chemo therapy, radiation
therapy and CAR-T cell therapy in Minnesota.

There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.

This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.

Nope; the input, such as DD, fully encapsulates the
entire decider HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body.
It is built on it.

There is no "trompe d'oeil", like a hand reaching out
of the picture to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp
can copy itself: "/bin/cp /bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input
to /bin/cp.

Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD)
matches this recursive simulation non halting behavior
pattern:

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

Here is what you don't understand. In every recursive
simulation level. your HHH(DD) returns 0.

I spent 10,000 hours on this an you only spent a few
minutes, you are simply wrong and I will explain
why and how.

An instance of HHH correctly determines that DD simulated
by HHH matches the infinite recursion behavior pattern as
soon as it simulates DD twice, thus is one step ahead of
all of the others.

It sees that DD calls HHH(DD) twice in sequence with
no conditional code between the invocation of DD and
its call to HHH(DD). This entails non-halting behavior
for DD.

Unless this directly executed HHH aborts none of them
ever abort because they all have the exact same machine code.

Each recursive simulation level has a *parent* HHH(DD)
which is simualting it.

The directly executed HHH has no parent.

<snip> I did read all the rest. I only do that for my best reviewers.
--
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 12/09/2025 15:36, olcott wrote:

On 9/11/2025 12:12 PM, Richard Heathfield wrote:

On 11/09/2025 17:38, olcott wrote:

<snip>

[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.

It would still be wrong. DD halts.

I carefully explain all of the details of how
this is incorrect

I and many others frequently and very carefully explain how
you're talking complete gibberish, and you never pay the
slightest attention. DD halts.

Presuming that I must be wrong without finding a
single error in the reasoning of my basis counts
as less then no rebuttal at all.

* We have a proof.
* DD halts and can be and has been shown to halt.
* Your "simulator" fails to simulate most of the code, and quelle
surprise, it gets the result wrong. Getting the wrong answer is
not just a single error - it's *the* single error!
* You incorrectly cite LLMs as authorities when you tell them
lies, but refuse to accept their reasoning when they are driven
neutrally.
* One moment you claim that DD is none of HHH's business, and the
next you claim that HHH is a decider for DD.
* You draw a distinction between a pointer value and...itself!
* You appeal to *your own* authority as a high-achieving high-IQ
student.
* You frequently use accusations of stupidity and dishonesty as
debating strategies.
* You confuse stack traces with "reasoning".
* You claimed credit for an idea 80-odd years after it was first
expressed!!
* But perhaps most importantly, you will sweep ALL of this under
the carpet, and maybe a week from now you'll again be claiming
that your reasoning is flawless and your intellectual integrity
rock solid.

It truly beggars belief.
--
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 Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:

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

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

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

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal >>>>>>>> test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you,
obviously does believe that diagonal test cases can actually exist? >>>>>>

I just discovered this when I was spending December to May getting
chemo therapy, radiation therapy and CAR-T cell therapy in
Minnesota.

There never has been any ACTUAL INPUT that does the opposite of
whatever its decider decides.

This has always been the error of conflating the behavior that the
ACTUAL INPUT ACTUALLY SPECIFIES with other behavior somewhere else.

Nope; the input, such as DD, fully encapsulates the entire decider
HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body.
It is built on it.

There is no "trompe d'oeil", like a hand reaching out of the picture
to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp can copy itself: "/bin/cp
/bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input to /bin/cp.

Without the execution trace that a simulating termination analyzer
provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this
recursive simulation non halting behavior pattern:

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

Here is what you don't understand. In every recursive simulation level.
your HHH(DD) returns 0.

I spent 10,000 hours on this an you only spent a few minutes, you are
simply wrong and I will explain why and how.

An instance of HHH correctly determines that DD simulated by HHH matches
the infinite recursion behavior pattern as soon as it simulates DD
twice, thus is one step ahead of all of the others.

It sees that DD calls HHH(DD) twice in sequence with no conditional code between the invocation of DD and its call to HHH(DD). This entails non-halting behavior for DD.

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is incorrect.

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

From Newsgroup: comp.theory

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

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

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

Not correctly though. Once that condition fires, and the
simulation is abandoned, it is failing to see that if the
simulation were continued, the simulated HHH(DD) would
return and proceed to the conditional instruction.

As I already said in my prior post and will repeat again
so that you can pay better attention. HHH sees that its
simulated DDD matches a non-halting behavior pattern as
soon as it simulated DD twice.

The next level simulated HHH could only see that DD has
been simulated once when the executed one has already
met is abort criteria.

Since every HHH has the exact same x86 code if the outer
one waited on the inner one then this wold form an infinite
chain of waiting and none of them would ever abort.

You know this is true, but you would rather look brutally
stupid than to admit being wrong.

The bible says: Revelation 21:8 NRSV
"...all liars, their place will be in the lake that burns with
fire and sulfur, which is the second death."

(1) I am not taking any chances.

(2) Mathematically formalizing the notion of
{true on the basis of meaning} has been my life's
work for 21 years.

*This has involved*
(a) The Liar Paradox

(b) The Tarski Undefinability Theorem

(c) Gödel's 1931 Incompleteness theorem
“We are therefore confronted with a proposition
which asserts its own unprovability.” (Gödel 1931:40-41)

(d) The Halting Problem proofs

(e) Montague Grammar of natural language semantics https://plato.stanford.edu/entries/montague-semantics/

(f) Minimal Type Theory (MTT) I created MTT to translate
formal logic expressions into their directed graphs to
detect cycles that indicate an expression cannot be
resolved to a truth value.

(g) Prolog's unify_with_occurs_check/2
“guards against creating cycles” https://www.swi-prolog.org/pldoc/man?predicate=unify_with_occurs_check/2

Like I said, someone will come along and demonstrate what
I'm talking about using your own code, and you will have
your ass handed to you at that point.

That is mere bluster having no actual basis on this
specific 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 9/11/2025 1:06 PM, Mike Terry wrote:

On 11/09/2025 04:17, Kaz Kylheku wrote:

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

On 9/10/2025 7:57 PM, Mike Terry wrote:

On 11/09/2025 01:11, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal
test case aimed against H!

Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.

Separately from that, if Sisper really did say that, he might not have >>>>> been aware that D is supposed to be the diagonal test case
targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision.  Had that been pointed out, a corection would have swiftly >>>>> followed.

My explanation is Sipser is considering a general H and a general input >>>> D.  When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied >>>> to determine non-halting *OF INPUT D*, and no other input.

Yet input D can be anything it is an arbitrary placeholder.

(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)

But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.

Paraphrase:

   If a halt decider /correctly/ determine, by /correctly/ simulating its >>    input that the input doesn't halt, then a halt decicer
   can stop the simulation and reject the input.

We have an logical if here:

    "If it can correctly simulate ... determine, ... THEN it can reject" >>
    IF P THEN Q

    P -> Q

Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.

    P   Q    P -> Q
    F   F      T
    F   T      T
    T   F      F
    T   T      T

In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.

Thus P is false.

If P is false then P -> Q is true.

Therefore, it is reasonable to agree with P -> Q.

"If unicorns exist, then pigs fly" --- I don't disagree!

However, there are some reasons to believe we can hit the "T F"
case of the truth table.

Suppose that H correctly determines the halting status of D.  H cannot
report that. It has to keep it to itself and not return.  In that case,
H can stop the simulation of D, but just cannot itself terminate; if it
returns anything to D, it is automatically wrong.

In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)

It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?

If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.

If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that
proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.

The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is
observable, or the fact that the function is not returning.  Therefore
the former camp is more on the correct side (H is not deemed to have
correctly determined anything until it returns) and can agree with
your verbatim text.

I think I'm on safe grounds predicting that Sipser is considering
deciding to mean reporting the decision and halting.  And of course an H which never returns is not a halt decider in the sense of the HP.

But your idea of internally determining something made me think: is it
easy to actually do that in practice?  It seems so to me.

H can be coded to examine its input computation.  If it sees that it has
no reachable code path that leads to any final state, it can be said to "know" (or have "determined") at that point that its input is non-
halting - if we like we could say it must pass through a designated
"I've worked out the input doesn't halt" state to "register" its discovery.  Regardless of the previous test succeeding, H then loops.

HHH(DD) sees that DD correctly simulated by HHH
cannot possibly reach its own simulated final halt state.

*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence
(b) With the same argument
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).

So now we construct the diagonal machine D, which embeds H algorithm.
H(D) never halts, and so D never halts.  Moreover, D() has no reachable code path that returns, and that fact can be correctly ascertained by
code in H, so H (coded appropriately) can "determine" that D() never
halts and register this, before continuing with its infinite loop.

Conclusion: H has correctly proved (internally) that D() does not halt,
and registered that by passing through its designated state.  And indeed D() never halts as proved (internally) by H.

For comparison we could imaging an H that (regardless of input) just "registers" that the input never halts, then enters an infinite loop. That's much simpler!  But... while this H /correctly/ registers that its associated diagonal D() never halts, it can't be said to have "seen"/"determined" that it halts, as you required(??), because there
are alternative inputs which H will also register as never halting but
will in fact halt.

[OK, I'm not sure if you used the word "determined" in the stronger
sense I interpreted it, or in the weaker sense of H simply being
"correct for the case being considered" without any justification.  My H which looks for reachable terminating code paths works with the stronger "determined" interpretation.]

Mike.

--
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/11/2025 2:46 PM, Kaz Kylheku wrote:

On 2025-09-11, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

I think I'm on safe grounds predicting that Sipser is considering deciding to mean reporting the
decision and halting. And of course an H which never returns is not a halt decider in the sense of
the HP.

But your idea of internally determining something made me think: is it easy to actually do that in
practice? It seems so to me.

With side effects, it is possible. Then we don't have pure functions any more.

E.g. the decider can do this:

puts("I know this doesn't halt, but I can't return because that would change the result.");
for(;;)/**/;

That has no effect when the measure of halting is
ONLY the semantic property of the input finite string.

HHH(DD) sees that DD correctly simulated by HHH
cannot possibly reach its own simulated final halt state.

*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence
(b) With the same argument
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).

<snip>

I skimmed the rest and it is not related to the actual
behavior that the input finite string actually specifies.
--
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/11/2025 5:05 PM, André G. Isaak wrote:

On 2025-09-10 21:17, Kaz Kylheku wrote:

Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.

    P   Q    P -> Q
    F   F      T
    F   T      T
    T   F      F
    T   T      T

Just to warn you, you're venturing into dangerous territory here. Among Olcott's many peculiarities is the fact that in the past he has rejected
the above truth table (though it's never been clear what he wants to
replace it with).

André

*I finally have good words for this*
Because implication is thought to model a
logical "if" statement:

If X then Y means that whenever X is true then
Y is true and whenever Y is false then X is false.

P Q if P then Q
F F T
F T F
T F F
T T T
--
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 Fri, 12 Sep 2025 10:36:59 -0500 schrieb olcott:

(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).

It is not the same DD that calls the same function. They aren't even
in the same simulation level.
There is nothing else in DD. What does HHH(HHH) return?
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/09/2025 16:36, olcott wrote:

HHH(DD) sees that DD correctly simulated by HHH
cannot possibly reach its own simulated final halt state.

Actually, it seems to cope just fine.

$ ./plaindd
DD halted.
$

When a simulator departs from reality, the fault lies with the
simulator. You can't blame reality for being real. You can call
it stupid or dishonest if you like, but it doesn't care.

DD halts. Deal with it.
--
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/12/2025 10:16 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:

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

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

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

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal >>>>>>>>> test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you,
obviously does believe that diagonal test cases can actually exist? >>>>>>>

I just discovered this when I was spending December to May getting >>>>>> chemo therapy, radiation therapy and CAR-T cell therapy in
Minnesota.

There never has been any ACTUAL INPUT that does the opposite of
whatever its decider decides.

This has always been the error of conflating the behavior that the >>>>>> ACTUAL INPUT ACTUALLY SPECIFIES with other behavior somewhere else. >>>>>

Nope; the input, such as DD, fully encapsulates the entire decider
HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body.
It is built on it.

There is no "trompe d'oeil", like a hand reaching out of the picture >>>>> to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp can copy itself: "/bin/cp
/bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input to /bin/cp.

Without the execution trace that a simulating termination analyzer >>>>>> provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this
recursive simulation non halting behavior pattern:

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

Here is what you don't understand. In every recursive simulation level.
your HHH(DD) returns 0.

I spent 10,000 hours on this an you only spent a few minutes, you are
simply wrong and I will explain why and how.

An instance of HHH correctly determines that DD simulated by HHH matches
the infinite recursion behavior pattern as soon as it simulates DD
twice, thus is one step ahead of all of the others.

It sees that DD calls HHH(DD) twice in sequence with no conditional code
between the invocation of DD and its call to HHH(DD). This entails
non-halting behavior for DD.

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is incorrect.

/Flibble

This is my basis. Changing the basis does not show
any error in my reasoning. My conclusion does logically
follow from my basis.

HHH(DD) sees that DD correctly simulated by HHH
cannot possibly reach its own simulated final halt state.

*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence
(b) With the same argument
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
--
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:08 AM, joes wrote:

Am Fri, 12 Sep 2025 10:36:59 -0500 schrieb olcott:

(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).

HHH(DD) sees that DD correctly simulated by HHH
cannot possibly reach its own simulated final halt state.

*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence
(b) With the same argument
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).

You cut off too much of the context
and somehow screwed up the formatting.

It is not the same DD that calls the same function. They aren't even
in the same simulation level.

There is one finite string of x86 machine code at
one machine address for each of HHH and DD.

Different simulation levels are essentially the
same thing as different recursion levels of the
same function called recursively.

There is nothing else in DD. What does HHH(HHH) return?

--
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 Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.

/Flibble

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is incorrect.

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

From Newsgroup: comp.theory

On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:

On 9/12/2025 10:16 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:

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

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

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

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal >>>>>>>>>> test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you,
obviously does believe that diagonal test cases can actually
exist?

I just discovered this when I was spending December to May getting >>>>>>> chemo therapy, radiation therapy and CAR-T cell therapy in
Minnesota.

There never has been any ACTUAL INPUT that does the opposite of
whatever its decider decides.

This has always been the error of conflating the behavior that the >>>>>>> ACTUAL INPUT ACTUALLY SPECIFIES with other behavior somewhere
else.

Nope; the input, such as DD, fully encapsulates the entire decider >>>>>> HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body.
It is built on it.

There is no "trompe d'oeil", like a hand reaching out of the
picture to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp can copy itself: "/bin/cp
/bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input to /bin/cp.

Without the execution trace that a simulating termination analyzer >>>>>>> provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this
recursive simulation non halting behavior pattern:

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

Here is what you don't understand. In every recursive simulation
level.
your HHH(DD) returns 0.

I spent 10,000 hours on this an you only spent a few minutes, you are
simply wrong and I will explain why and how.

An instance of HHH correctly determines that DD simulated by HHH
matches the infinite recursion behavior pattern as soon as it
simulates DD twice, thus is one step ahead of all of the others.

It sees that DD calls HHH(DD) twice in sequence with no conditional
code between the invocation of DD and its call to HHH(DD). This
entails non-halting behavior for DD.

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.

/Flibble

This is my basis. Changing the basis does not show any error in my
reasoning. My conclusion does logically follow from my basis.

HHH(DD) sees that DD correctly simulated by HHH cannot possibly reach
its own simulated final halt state.

*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is incorrect.

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

From Newsgroup: comp.theory

On 9/12/2025 10:08 AM, Richard Heathfield wrote:

On 12/09/2025 15:36, olcott wrote:

On 9/11/2025 12:12 PM, Richard Heathfield wrote:

On 11/09/2025 17:38, olcott wrote:

<snip>

[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.

It would still be wrong. DD halts.

I carefully explain all of the details of how
this is incorrect

I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest attention.
DD halts.

When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
--
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, Mr Flibble wrote:

On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.

/Flibble

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is incorrect.

/Flibble

When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
--
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:48 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:

On 9/12/2025 10:16 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:

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

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

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

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the diagonal >>>>>>>>>>> test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you, >>>>>>>>> obviously does believe that diagonal test cases can actually >>>>>>>>> exist?

I just discovered this when I was spending December to May getting >>>>>>>> chemo therapy, radiation therapy and CAR-T cell therapy in
Minnesota.

There never has been any ACTUAL INPUT that does the opposite of >>>>>>>> whatever its decider decides.

This has always been the error of conflating the behavior that the >>>>>>>> ACTUAL INPUT ACTUALLY SPECIFIES with other behavior somewhere
else.

Nope; the input, such as DD, fully encapsulates the entire decider >>>>>>> HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body.
It is built on it.

There is no "trompe d'oeil", like a hand reaching out of the
picture to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp can copy itself: "/bin/cp >>>>>>> /bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input to /bin/cp. >>>>>>>

Without the execution trace that a simulating termination analyzer >>>>>>>> provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt, >>>>>>> /your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this
recursive simulation non halting behavior pattern:

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

Here is what you don't understand. In every recursive simulation
level.
your HHH(DD) returns 0.

I spent 10,000 hours on this an you only spent a few minutes, you are
simply wrong and I will explain why and how.

An instance of HHH correctly determines that DD simulated by HHH
matches the infinite recursion behavior pattern as soon as it
simulates DD twice, thus is one step ahead of all of the others.

It sees that DD calls HHH(DD) twice in sequence with no conditional
code between the invocation of DD and its call to HHH(DD). This
entails non-halting behavior for DD.

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.

/Flibble

This is my basis. Changing the basis does not show any error in my
reasoning. My conclusion does logically follow from my basis.

HHH(DD) sees that DD correctly simulated by HHH cannot possibly reach
its own simulated final halt state.

*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is incorrect.

/Flibble

When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
--
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 12/09/2025 17:35, olcott wrote:

DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).

It's got a doozy on the next line though.

And that's going to fire as soon as HHH returns.

I invite you to remember that HHH is a component of the DD
algorithm. DD's behaviour depends in part on HHH.

When HHH yields 0, as you say it must, DD uses that value to halt.

Either this fact is known to HHH (in which case it should explore
the consequence of returning 0), or it isn't (in which case HHH
doesn't have all the information it needs to do its job, so you
need to reconsider the interface).

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 Fri, 12 Sep 2025 11:50:43 -0500, olcott wrote:

On 9/12/2025 11:48 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:

On 9/12/2025 10:16 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:

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

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

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

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

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

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

That is positively true ... provided that D is not the >>>>>>>>>>>> diagonal test case aimed against H!

The diagonal test case never could ever actually exist.

So it's okay not to mention that to Sipser, who, unlike you, >>>>>>>>>> obviously does believe that diagonal test cases can actually >>>>>>>>>> exist?

I just discovered this when I was spending December to May
getting chemo therapy, radiation therapy and CAR-T cell therapy >>>>>>>>> in Minnesota.

There never has been any ACTUAL INPUT that does the opposite of >>>>>>>>> whatever its decider decides.

This has always been the error of conflating the behavior that >>>>>>>>> the ACTUAL INPUT ACTUALLY SPECIFIES with other behavior
somewhere else.

Nope; the input, such as DD, fully encapsulates the entire
decider HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body.
It is built on it.

There is no "trompe d'oeil", like a hand reaching out of the
picture to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp can copy itself: "/bin/cp >>>>>>>> /bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input to /bin/cp. >>>>>>>>

Without the execution trace that a simulating termination
analyzer provides this conflation error remained invisible.

Without the execution trace showing that the simulation wrongly >>>>>>>> abandoned by HHH can be picked up and continued to watch DD halt, >>>>>>>> /your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this >>>>>>> recursive simulation non halting behavior pattern:

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

Here is what you don't understand. In every recursive simulation
level.
your HHH(DD) returns 0.

I spent 10,000 hours on this an you only spent a few minutes, you
are simply wrong and I will explain why and how.

An instance of HHH correctly determines that DD simulated by HHH
matches the infinite recursion behavior pattern as soon as it
simulates DD twice, thus is one step ahead of all of the others.

It sees that DD calls HHH(DD) twice in sequence with no conditional
code between the invocation of DD and its call to HHH(DD). This
entails non-halting behavior for DD.

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.

/Flibble

This is my basis. Changing the basis does not show any error in my
reasoning. My conclusion does logically follow from my basis.

HHH(DD) sees that DD correctly simulated by HHH cannot possibly reach
its own simulated final halt state.

*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.

/Flibble

When HHH(DD) is supposed to ONLY report on the behavior that its actual
input actually specifies then HHH(DD)==0 is correct. That people keep changing this basis as their rebuttal is only the dishonestly of the
strawman error

DD halts.

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

From Newsgroup: comp.theory

On Fri, 12 Sep 2025 11:50:19 -0500, olcott wrote:

On 9/12/2025 11:47 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.

/Flibble

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.

/Flibble

When HHH(DD) is supposed to ONLY report on the behavior that its actual
input actually specifies then HHH(DD)==0 is correct. That people keep changing this basis as their rebuttal is only the dishonestly of the
strawman error

DD halts.

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

From Newsgroup: comp.theory

On 12/09/2025 17:49, olcott wrote:

<snip>

When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct.

Since we know that DD halts, HHH(DD) is incorrect.

That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error

No, sir; it's a ridiculous justification. Your argument amounts
to this:

1) you're too stupid to show HHH all the DD information it needs
2) therefore HHH is justified in getting the answer wrong
3) therefore the answer is right

It's complete baloney. DD halts.

What HHH(DD) is supposed to report on is whether DD halts. If you
can get that right via simulation, great! But you clearly can't,
therefore your method is screwed.

Failing to provide a function with the data it needs to do its
job is not "correct"; it's just boneheaded.
--
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 12/09/2025 17:50, olcott wrote:

<snip>

When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct.

DD halts. If you stand by your claim that HHH(DD) == 0 is
correct, we are forced to conclude that HHH is not a decider for DD.

That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error

The "basis" is baloney, and what's dishonest is that you keep
presenting it when you must surely *know* it's baloney.
--
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 12/09/2025 17:50, olcott wrote:

When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error

No matter how many times you repeat this nonsense, nonsense it
remains.

Write a better simulator or... better yet... just read the bloody
proof.
--
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/12/2025 11:58 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 11:50:43 -0500, olcott wrote:

On 9/12/2025 11:48 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:

On 9/12/2025 10:16 AM, Mr Flibble wrote:

On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:

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

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

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

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

On 9/10/2025 7:41 PM, Kaz Kylheku wrote:

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

On 9/10/2025 7:11 PM, Kaz Kylheku wrote:

On 2025-09-10, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> <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>

That is positively true ... provided that D is not the >>>>>>>>>>>>> diagonal test case aimed against H!

The diagonal test case never could ever actually exist. >>>>>>>>>>>

So it's okay not to mention that to Sipser, who, unlike you, >>>>>>>>>>> obviously does believe that diagonal test cases can actually >>>>>>>>>>> exist?

I just discovered this when I was spending December to May >>>>>>>>>> getting chemo therapy, radiation therapy and CAR-T cell therapy >>>>>>>>>> in Minnesota.

There never has been any ACTUAL INPUT that does the opposite of >>>>>>>>>> whatever its decider decides.

This has always been the error of conflating the behavior that >>>>>>>>>> the ACTUAL INPUT ACTUALLY SPECIFIES with other behavior
somewhere else.

Nope; the input, such as DD, fully encapsulates the entire
decider HHH in its description.

In effect, it's as if DD has a copy of that decider.

The actual input to the decider; has the decider in its body. >>>>>>>>> It is built on it.

There is no "trompe d'oeil", like a hand reaching out of the >>>>>>>>> picture to hold a pen which draws the picture.

Programs can easily have themselves as input.

For instance your Unix program /bin/cp can copy itself: "/bin/cp >>>>>>>>> /bin/cp copy-of-cp"

/bin/cp is a string of bits which is the actual input to /bin/cp. >>>>>>>>>

Without the execution trace that a simulating termination
analyzer provides this conflation error remained invisible. >>>>>>>>>

Without the execution trace showing that the simulation wrongly >>>>>>>>> abandoned by HHH can be picked up and continued to watch DD halt, >>>>>>>>> /your own/ error of reasoning remains invisible to you.

You still do not understand that as soon as HHH(DD) matches this >>>>>>>> recursive simulation non halting behavior pattern:

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

Here is what you don't understand. In every recursive simulation >>>>>>> level.
your HHH(DD) returns 0.

I spent 10,000 hours on this an you only spent a few minutes, you
are simply wrong and I will explain why and how.

An instance of HHH correctly determines that DD simulated by HHH
matches the infinite recursion behavior pattern as soon as it
simulates DD twice, thus is one step ahead of all of the others.

It sees that DD calls HHH(DD) twice in sequence with no conditional >>>>>> code between the invocation of DD and its call to HHH(DD). This
entails non-halting behavior for DD.

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is >>>>> incorrect.

/Flibble

This is my basis. Changing the basis does not show any error in my
reasoning. My conclusion does logically follow from my basis.

HHH(DD) sees that DD correctly simulated by HHH cannot possibly reach
its own simulated final halt state.

*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).

But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.

/Flibble

When HHH(DD) is supposed to ONLY report on the behavior that its actual
input actually specifies then HHH(DD)==0 is correct. That people keep
changing this basis as their rebuttal is only the dishonestly of the
strawman error

DD halts.

/Flibble

--
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-12, olcott <polcott333@gmail.com> wrote:

On 9/12/2025 10:08 AM, Richard Heathfield wrote:

On 12/09/2025 15:36, olcott wrote:

On 9/11/2025 12:12 PM, Richard Heathfield wrote:

On 11/09/2025 17:38, olcott wrote:

<snip>

[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.

It would still be wrong. DD halts.

I carefully explain all of the details of how
this is incorrect

I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest attention.
DD halts.

When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error

The input contains its own HHH. The *correctly and completely* simulated
input calls HHH, obtains 0 and returns, exactly like when DD is
run at the outer level zero that is not simulated.

HHH does not *correctly and completely* simulate its input; it
jumps to the wrong conclusion and stops simulating a halting input,
wrongly declaring it to be non-halting.

According to the half-baked halting criteria you have selected, indeed
there is no evidence of halting in the execution trace up to the point
where the decision is made. But that evidence shows up afterward, if the simulation is continued and execution trace further extended.

The simulated HHH is the same as the outside HHH; both return 0.

Any demo of yours in which the simulated HHH(DD) does not also return 0, whenever the outer HHH(DD) one does, shows itself to be incorrect.

HHH and DD are required to be pure; all occurrences of HHH(DD) anywhere
denote exactly the same computation with the same properties.

When-so-ever you have a HHH that is not pure, it your interlocutor's
privilege to examine each of your divergent HHH(DD) expressions, and the divergent DD() expressions built on them, and pick a pair that
contradict each other.

For instance, if you have a HHH(DD) that returns 0, and another HHH(DD)
that fails to return, it is the interlocutor's privilege to take the
HHH(DD) == 0 result as the truth that your system is asserting. And then
if there exists a halting DD() and a non-halting DD(), it is the
interlocutor's privilege to assert that HHH(DD) == 0 talking about the
halting one.

In other words, each HHH(DD) expression that occurs in your system must calculate a correct decision about every DD() that occurs in your
system: the full N x N mesh of combinations must all be correct.
If any HHH(DD) speaks wrongly about any DD(), or if any HHH(DD)
fails to terminate you have a mistake.
--
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 Fri, 12 Sep 2025 11:49:35 -0500, olcott wrote:

On 9/12/2025 10:08 AM, Richard Heathfield wrote:

On 12/09/2025 15:36, olcott wrote:

On 9/11/2025 12:12 PM, Richard Heathfield wrote:

On 11/09/2025 17:38, olcott wrote:

<snip>

[HHH] could simulate until just before the heat death of the
universe and then finally report that DD does not halt.

It would still be wrong. DD halts.

I carefully explain all of the details of how this is incorrect

I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest attention.
DD halts.

When HHH(DD) is supposed to ONLY report on the behavior that its actual
input actually specifies then HHH(DD)==0 is correct. That people keep changing this basis as their rebuttal is only the dishonestly of the
strawman error

DD halts.

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