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

Op 25.mrt.2025 om 13:04 schreef olcott:

On 3/25/2025 4:19 AM, Fred. Zwarts wrote:

Op 25.mrt.2025 om 00:04 schreef 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.p
>

>
Maybe when pure math objects. In every model of
computation they seem to always have inputs.
https://en.wikipedia.org/wiki/Computable_function

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

>
_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
>
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

>
If fails to complete the simulation of a program that halts

 It is stupid to ignore the pathological relationship
that III defines with EEE.
 

That relation is irrelevant, it fails to reach the end of the simulation anyhow.
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.