Am Wed, 23 Jul 2025 07:57:48 -0500 schrieb olcott:

On 7/23/2025 3:20 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 18:09 schreef olcott:

On 7/22/2025 3:45 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 06:17 schreef olcott:

On 7/21/2025 9:20 PM, Richard Damon wrote:

It is a verified fact that the PROGRAM DDD halts since your
HHH(DDD) returns 0.

It is a self-evident truth that the halting problem proof has always >>>>> been incorrect when it requires a halt decider to report on the
behavior of the direct execution of any Turing machine because no
Turing machine decider can ever take another directly executed
Turing machine as its input.

That's a ridiculous strawman. You're confusing input and output: the
behaviour of a TM CAN be decided from its description (but there is
no one machine that does it for all).

The *domain of this problem is to be taken as the*
*set of all Turing machines* [WRONG] and all w;

The domain of the problem is not *set of all Turing machines* it is the
*set of all finite string Turing machine descriptions*

Those correspond. Every TM can be finitely described, and every
description, well, describes a machine (which may halt immediately due
to a missing rule).

that is, we are looking for a single Turing machine that, given the
description of an arbitrary M and w, will predict whether or not the
computation of M applied to w will halt.

Note the 'given the description of an arbitrary M". It does not say
'given an arbitrary M'. The word 'description' makes your claim
counter- factual.

There is no difference. Are you seriously suggesting that TMs cannot
be simulated?

The halt decider must decide on its input. In this case the input
specifies a DD that calls a HHH that aborts and returns, so the input
specifies a halting program.

The simulated DDD that calls a simulated HHH(DDD)
never aborts or returns.

Duh, because the simulation is aborted before that.

How do you figure HHH's abort check is correct? Preferably without
circular reasoning.

But the HHH called by DDD is programmed to abort after a finite
recursion. The behaviour of DDD depends on the behaviour of HHH. When
HHH returns with a value of 0, DDD reaches the final halt state.
That is what is specified. That is what a correct simulation would see.

The fact that no DDD emulated by HHH according to the semantics of the
x86 language can possibly reach its own simulated "ret" instruction
final halt state proves that DDD specifies non-halting behavior.

The processor must be doing it wrong then.

The directly executed HHH aborts its simulation of DDD which in turn
kills the whole simulation process that includes the simulated HHH.

HHH aborts before it reaches the final halt state. There is nothing in
the simulation that shows that there is no final halt state. In fact,
HHH ignores the conditional branch instructions during the simulation,
which could tell it that there is a final halt state.
Nowhere there is a reference to direct execution. It is only the
semantics of the x86 language that tells enough to prove the halting
behaviour of the program specified in the input. That HHH fails to
simulate he input up to the end, does not change the specification.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Wed, 23 Jul 2025 09:19:48 -0500 schrieb olcott:

On 7/23/2025 8:17 AM, joes wrote:

Am Wed, 23 Jul 2025 07:57:48 -0500 schrieb olcott:

On 7/23/2025 3:20 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 18:09 schreef olcott:

On 7/22/2025 3:45 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 06:17 schreef olcott:

It is a self-evident truth that the halting problem proof has
always been incorrect when it requires a halt decider to report on >>>>>>> the behavior of the direct execution of any Turing machine because >>>>>>> no Turing machine decider can ever take another directly executed >>>>>>> Turing machine as its input.

That's a ridiculous strawman. You're confusing input and output: the
behaviour of a TM CAN be decided from its description (but there is no
one machine that does it for all).

In the case where an x86 input DD calls its own simulating termination analyzer HHH or an input ⟨Ĥ⟩ to a Turing machine Ĥ has its (at least partial) halt decider embedded within it it is a verified fact (that is difficult to understand)

That is not difficult at all.

that DD correctly simulated by HHH and ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
Ĥ.embedded_H has different behavior than the behavior of directly
executed DD() or Ĥ applied to ⟨Ĥ⟩.

We cannot possibly get anywhere until after you understand this. Being
in psychological denial is not a rebuttal.

Oh the irony.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Wed, 23 Jul 2025 15:16:29 -0500 schrieb olcott:

On 7/23/2025 2:08 PM, joes wrote:

Am Wed, 23 Jul 2025 09:19:48 -0500 schrieb olcott:

On 7/23/2025 8:17 AM, joes wrote:

Am Wed, 23 Jul 2025 07:57:48 -0500 schrieb olcott:

On 7/23/2025 3:20 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 18:09 schreef olcott:

On 7/22/2025 3:45 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 06:17 schreef olcott:

It is a self-evident truth that the halting problem proof has >>>>>>>>> always been incorrect when it requires a halt decider to report >>>>>>>>> on the behavior of the direct execution of any Turing machine >>>>>>>>> because no Turing machine decider can ever take another directly >>>>>>>>> executed Turing machine as its input.

That's a ridiculous strawman. You're confusing input and output: the
behaviour of a TM CAN be decided from its description (but there is
no one machine that does it for all).

In the case where an x86 input DD calls its own simulating termination
analyzer HHH or an input ⟨Ĥ⟩ to a Turing machine Ĥ has its (at least >>> partial) halt decider embedded within it it is a verified fact (that
is difficult to understand)

That is not difficult at all.

You continue to deny that HHH does simulate DD and then correctly
simulates itself simulating DD until this simulated simulated DD calls
yet another HHH(DD).

I never denied that. However, HHH never simulates a return of HHH.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Op 23.jul.2025 om 23:02 schreef olcott:

On 7/23/2025 3:51 PM, joes wrote:

Am Wed, 23 Jul 2025 15:16:29 -0500 schrieb olcott:

On 7/23/2025 2:08 PM, joes wrote:

Am Wed, 23 Jul 2025 09:19:48 -0500 schrieb olcott:

On 7/23/2025 8:17 AM, joes wrote:

Am Wed, 23 Jul 2025 07:57:48 -0500 schrieb olcott:

On 7/23/2025 3:20 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 18:09 schreef olcott:

On 7/22/2025 3:45 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 06:17 schreef olcott:

It is a self-evident truth that the halting problem proof has >>>>>>>>>>> always been incorrect when it requires a halt decider to report >>>>>>>>>>> on the behavior of the direct execution of any Turing machine >>>>>>>>>>> because no Turing machine decider can ever take another directly >>>>>>>>>>> executed Turing machine as its input.

That's a ridiculous strawman. You're confusing input and output: the >>>>>> behaviour of a TM CAN be decided from its description (but there is >>>>>> no one machine that does it for all).

In the case where an x86 input DD calls its own simulating termination >>>>> analyzer HHH or an input ⟨Ĥ⟩ to a Turing machine Ĥ has its (at least
partial) halt decider embedded within it it is a verified fact (that >>>>> is difficult to understand)

That is not difficult at all.

You continue to deny that HHH does simulate DD and then correctly
simulates itself simulating DD until this simulated simulated DD calls
yet another HHH(DD).

I never denied that. However, HHH never simulates a return of HHH.

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

OK great we are getting somewhere.

Executed HHH simulates DDD that calls a simulated HHH(DDD)
that simulates its own DDD that calls a simulated simulated HHH(DDD)

That is enough for the executed HHH and any fully
competent software engineer to see that this directly
executed HHH must abort its simulation to prevent its
own non-termination.

Counter-factual. It is irrelevant whether HHH must abort, or not. What
is relevant is that HHH does abort. An competent software engineer with
some insight will not conclude that a finite recursion implies
non-termination.
HHH, both the simulating and the simulated HHH, has code to prematurely
abort the simulation. Therefore, the input specifies an aborting and
halting program, because a correct simulation of the aborting HHH will
reach its final halt state. (Proven by world-class simulators.)
This same engineer will conclude that HHH fails to reach this final halt
state. This failure is no reason to conclude that there is non-termination.

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

Op 24.jul.2025 om 16:34 schreef olcott:

On 7/24/2025 5:09 AM, Fred. Zwarts wrote:

Op 23.jul.2025 om 23:02 schreef olcott:

On 7/23/2025 3:51 PM, joes wrote:

Am Wed, 23 Jul 2025 15:16:29 -0500 schrieb olcott:

On 7/23/2025 2:08 PM, joes wrote:

Am Wed, 23 Jul 2025 09:19:48 -0500 schrieb olcott:

On 7/23/2025 8:17 AM, joes wrote:

Am Wed, 23 Jul 2025 07:57:48 -0500 schrieb olcott:

On 7/23/2025 3:20 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 18:09 schreef olcott:

On 7/22/2025 3:45 AM, Fred. Zwarts wrote:

Op 22.jul.2025 om 06:17 schreef olcott:

It is a self-evident truth that the halting problem proof has >>>>>>>>>>>>> always been incorrect when it requires a halt decider to >>>>>>>>>>>>> report
on the behavior of the direct execution of any Turing machine >>>>>>>>>>>>> because no Turing machine decider can ever take another >>>>>>>>>>>>> directly
executed Turing machine as its input.

That's a ridiculous strawman. You're confusing input and output: >>>>>>>> the
behaviour of a TM CAN be decided from its description (but there is >>>>>>>> no one machine that does it for all).

In the case where an x86 input DD calls its own simulating
termination
analyzer HHH or an input ⟨Ĥ⟩ to a Turing machine Ĥ has its (at least
partial) halt decider embedded within it it is a verified fact (that >>>>>>> is difficult to understand)

That is not difficult at all.

You continue to deny that HHH does simulate DD and then correctly
simulates itself simulating DD until this simulated simulated DD calls >>>>> yet another HHH(DD).

I never denied that. However, HHH never simulates a return of HHH.

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

OK great we are getting somewhere.

Executed HHH simulates DDD that calls a simulated HHH(DDD)
that simulates its own DDD that calls a simulated simulated HHH(DDD)

That is enough for the executed HHH and any fully
competent software engineer to see that this directly
executed HHH must abort its simulation to prevent its
own non-termination.

Counter-factual. It is irrelevant whether HHH must abort, or not.

*The best selling author of theory of computation textbooks disagrees*

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

As usual no rebuttal irrelevant claims. You have been corrected on this
many times. Sipser agreed to a vacuous statement.
H does not do a correct simulation, H does not correctly determine that
D would never stop. So, when the required conditions are not present,
the statement becomes vacuous.

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