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

On 4/26/2025 5:11 PM, dbush wrote:

On 4/26/2025 6:09 PM, olcott wrote:

On 4/26/2025 4:04 PM, Richard Damon wrote:

On 4/26/25 4:33 PM, olcott wrote:

On 4/26/2025 1:26 PM, Fred. Zwarts wrote:

Op 26.apr.2025 om 19:29 schreef olcott:

On 4/26/2025 12:16 PM, joes wrote:

Am Sat, 26 Apr 2025 11:22:42 -0500 schrieb olcott:

On 4/25/2025 5:09 PM, joes wrote:

Am Fri, 25 Apr 2025 16:46:11 -0500 schrieb olcott:

On 4/25/2025 11:54 AM, Richard Damon wrote:

On 4/25/25 12:31 PM, olcott wrote:

>

Once we understand that Turing computable functions are only allowed
to derived their outputs by applying finite string operations to
their inputs then my claim about the behavior of DD that HHH must
report on is completely proven.
>

Youy have your words wrong. They are only ABLE to use finite
algorithms of finite string operations. The problem they need to
solve do not need to be based on that, but on just general mappings
of finite strings to finite strings that might not be described by a
finite algorithm.
The mapping is computable, *IF* we can find a finite algorith of
transformation steps to make that mapping.
>

There are no finite string operations that can be applied to the input
to HHH(DD) that derive the behavior of of the directly executed DD
thus DD is forbidden from reporting on this behavior.

>

Yes, there are, the operations that the processor executes. How did you
think it works?
>

When you try to actually show the actual steps instead of being stuck in
utterly baseless rebuttal mode YOU FAIL!

Which x86 semantics does a processor violate when deriving a halting
state from the string description of DD?
>

When any HHH emulates DD according to the finite string transformation
rules specified by the x86 language (the line of demarcation between
correct and incorrect emulation) no emulated DD can possibly reach its
final halt state and halt.

Yes, where is that line?
>

>
Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.
>
_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]
>
DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].
>

>
Finite recursion,

>
Mathematical induction proves that DD emulated by
any HHH that applies finite string transformation
rules specified by the x86 language to its input
no DD can possibly reach its final halt state.

>
No, it doesn't, as you can't have an infinte series of a function that has been defined to be a specific instance.
>

>
One recursive emulation of HHH emulating itself emulating
DD after DD has already been emulated by DD once conclusively
proves that
>
simulated DD would never stop running unless aborted
>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its *simulated D would never*
*stop running unless aborted* then
>
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>

 And again you lie by implying that Sipser agrees with you when it has been proven that he doesn't:
  On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
 > I exchanged emails with him about this. He does not agree with anything
 > substantive that PO has written. I won't quote him, as I don't have
 > permission, but he was, let's say... forthright, in his reply to me.
 

That professor Sipser did not have the time to
understand the significance of what he agreed to
does not entail that he did not agree with my
meanings of what he agreed to.
Professor Sipser did not even have the time to
understand the notion of recursive emulation.
Without this it is impossible to see the significance
of my work.
We argued endlessly over the meaning of "correct emulation"
until I overrode everyone when I specified the standard of
measure of the finite string transformation rules of the
x86 language applied to the input to HHH(DD) as the line
of demarcation between correct and incorrect emulation.
(1) DD is correctly emulated by HHH
(2) Until after one emulation and one recursive
emulation HHH has complete proof that DD cannot possibly
reach its own final halt state even after an
infinite number of steps have been emulated.
(3) Therefore HHH is correct to reject DD as non-halting.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer