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

Op 25.mrt.2025 om 23:45 schreef olcott:

On 3/25/2025 3:47 AM, joes wrote:

Am Mon, 24 Mar 2025 18:04:21 -0500 schrieb olcott:

On 3/24/2025 5:49 PM, André G. Isaak wrote:

On 2025-03-24 16:43, olcott wrote:
>

Computable functions don't have inputs. They have domains. Turing
machines have inputs.

Maybe when pure math objects. In every model of computation they seem
to always have inputs.

Computable functions *are* pure math objects. You seem to want to
conflate them with C functions, but that is not the case.
The crucial point is that the domains of computable functions are *not*
restricted to strings, even if the inputs to Turing Machines are.
>

While the inputs to TMs are restricted to strings, there is no such
such restriction on computable functions.
The vast majority of computable functions of interest do *not* have
strings as their domains, yet they remain computable functions (a
simple example would be the parity function which maps NATURAL
NUMBERS (not strings) to yes/no values.)

Since there is a bijection between natural numbers and strings of
decimal digits your qualification seems vacuous.

There is not a bijection between natural numbers and strings. There is
a one-to-many mapping from natural numbers to strings, just as there is
a one-to-many mapping from computations (i.e. turing machine/input
string pairs, i.e. actual Turing machines directly running on their
inputs) to strings.

>

When III is emulated by pure emulator EEE for any finite number of steps
of emulation according to the semantics of the x86 language it never
reaches its own "ret" instruction final halt state THUS DOES NOT HALT.
When III is directly executed calls an EEE instance that only emulates
finite number of steps then this directly executed III always reaches
its own "ret" instruction final halt state THUS HALTS.

 

A pure simulator can not limit the number of steps. Also III doesn't
halt in, say, 3 steps. Why should III call a different instance
that doesn't abort, when it is being simulated?
>

 There is no different instance of EEE that doesn't abort.
They all stop emulating after a finite number of steps.
When EEE emulates 4 billion steps of III, III never
reaches its final halt state.
 

Indeed a simulator simulating itself will never reach the end of the simulation.
It is not very interesting to know whether a simulator reports that it is unable to reach the end of the simulation of a program that halts in direct execution.
It is interesting to know:
'Is there an algorithm that can determine for all possible inputs whether the input specifies a program that (according to the semantics of the machine language) halts when directly executed?'
This question seems undecidable for Olcott.