Re: Turing Machine computable functions apply finite string transformations to inputs

On 4/28/25 12:27 PM, olcott wrote:

On 4/28/2025 4:14 AM, Mikko wrote:

On 2025-04-26 15:59:39 +0000, olcott said:
>

On 4/26/2025 3:19 AM, Mikko wrote:

On 2025-04-25 16:31:58 +0000, olcott said:
>

On 4/25/2025 3:46 AM, Mikko wrote:

On 2025-04-24 15:11:13 +0000, olcott said:
>

On 4/23/2025 3:52 AM, Mikko wrote:

On 2025-04-21 23:52:15 +0000, olcott said:
>

Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.

>
Others can see that their justification is defective and contradicted
by a good proof.
>
Some people claim that the unsolvability of the halting problem is
unproven but nobody has solved the problem.

>
For the last 22 years I have only been refuting the
conventional Halting Problem proof.

>
Trying to refute. You have not shown any defect in that proof of the
theorem. There are other proofs that you don't even try to refute.

>
Not at all. You have simply not been paying enough attention.
>
Once we understand that Turing computable functions are only
allowed

>
Turing allowed Turing machines to do whatever they can do.

>
Strawman deception error of changing the subject away
from computable functions.

>
Attempt to deceive by a false claim. The term "computable function" is
defined in terms of Turing machines so Turing machines are on topic.
>

 Since there is no universally agreed upon definition
of the Turing Machine language it is impossible to
provide the 100% concrete details in this Turing
Machine language.

What do you mean by that?
There is a definite formal definition of the language, it might be too abstract for you to understand, but it is fully defined. (with perhaps a few small options)
We start by defining a finite set of symbols that we can put on the tape.
We then make a tape that has a finite number of these symbols on it, and that tape is extended to infinity with some default symbol.
A Head is placed somewhere in that finite initial String.
We then define the machine, as having a finite set of state that it can be in.
There is also a defined set of transformation instructions defined:
For each state we are in, and for each possible symbol at the location of the the Head, we define:
* The symbol to write on the tape where the head is.
* Which direction the tape is to move one space
* What the next state the program is to be in for the next step.
Some state are defined instead, to be terminal, and if we transition to them, the machine stops, and the tape can be inspected.
(A Variation defines the operation to rather than go to a next state to just stop at the current state)

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 Form bottom of page 2, (encoded more simply)
https://www.liarparadox.org/Linz_Proof.pdf
 When embedded_H applies the finite string transformation
rules specified by the above template IT IS clear that
the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach is final state
of ⟨Ĥ.qn⟩

 (a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation

Unless of course, at some point embedded_H stops is emulation and goes to the answer it decided on.
If it doesn't, then since it is the exact same machine as H, neither does H, so H never answers.

 Because none of the details are shown between state
transitions it is not a clear as the x86 example.
 _DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]
 When we apply the finite string transformation rules specified
by the x86 language to the input to HHH(DD) WE ONLY GET THAT
DD DOES NOT HALT.

Sure it does, as the HHH(DD) that DD calls *WILL* abort its processing and return 0 to DD and thus DD will halt.
The fact that HHH doesn't correctly emulate its input and gives up, doesn't change this behavior.
Your problem is you think either that partial emulation defines behavior, or that one program (HHH) can be two different programs with different behavior

 

Turing Machine Computable Functions are not allowed
to output anything besides the result of applying
finite string transformations to their input.

>
A Turing Machine Computable function is allowed and required to output
the value of the function for the given argument and nothing else.
>

 Yes and it must do that by applying finite string
transformation rules to this input.
 When we apply the finite string transformation rules specified
by the x86 language to the input to HHH(DD) WE ONLY GET THAT
DD DOES NOT HALT.
 

No, we get that DD does halt, only after HHH has given up, and stopped its emulation, in VIOLATION of the rules of the x86 language.