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

On 3/25/25 6:45 PM, olcott wrote:

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.
 

So, you have in infininte number of EEEs, each given one of an infinite number of IIIs (since to emulate III, we need to include the EEE that it calls as the input, and each of those was different).
NONE of these inputs match the DDD that calls HHH as HHH is different then any of the DDD.
And, we have the fact that for any given EEE, called by a given III, ther exists another (in fact an infinite number of them) EEE that emulates enough longer that if given the input of the III that calls the shorter running EEE will emulate it to the final state.
Of course, we need these two EEEs to be located in different locations of memory since they are different, and to be part of a C program, they will need to be given different names (like EEE1).
If your theory of progarms can't handle relocating programs to other addresses, then you have a fairly worthless system.
Sorry, your ship has sunk, taking your reputation to the bottom of that lake of fire, which you will be join shortly.