Re: Correcting the definition of the halting problem --- Computable functions

Am Mon, 24 Mar 2025 17:11:38 -0500 schrieb olcott:

On 3/24/2025 3:18 PM, dbush wrote:

On 3/24/2025 4:11 PM, olcott wrote:

On 3/24/2025 12:35 PM, dbush wrote:

On 3/24/2025 12:44 PM, olcott wrote:

On 3/24/2025 10:14 AM, dbush wrote:

On 3/24/2025 11:03 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 11:09 PM, olcott wrote:

That seems to be your own fault.
The problem has always been that you want to use the wrong string
for DDD by excluding the code for HHH from it.

DDD emulated by HHH directly causes recursive emulation because it
calls HHH(DDD) to emulate itself again. HHH complies until HHH
determines that this cycle cannot possibly reach the final halt
state of DDD.

Which is another way of saying that HHH can't determine that DDD
halts when executed directly.

given an input of the function domain it can return the
corresponding output.
Computable functions are only allowed to compute the mapping from
their input finite strings to an output.

The HHH you implemented is computing *a* computable function, but
it's not computing the halting function:

The whole point of this post is to prove that no Turing machine ever
reports on the behavior of the direct execution of another Turing
machine.

Sure it can.  Any that takes a description of a turning machine that
halt when executed directly is correct to return 1, regardless
of the logic used to do so.

It has no way of directly computing this. It can only compute the
behavior that the finite string specifies.

The description of a TM completely specifies whether that maching halts.
UTMs/Simulators compute that behaviour from that string.

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