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

Op 29.apr.2025 om 06:52 schreef olcott:

On 4/28/2025 7:22 PM, Mike Terry wrote:

On 27/04/2025 17:25, olcott wrote:

On 4/26/2025 10:38 PM, Mike Terry wrote:

On 27/04/2025 04:07, Mike Terry wrote:

On 27/04/2025 01:22, olcott wrote:

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

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

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.

>
In other words, he did not you agree what you think he agreed to, and your posting the above to imply that he did is a form of lying.
>

>
*He agreed to MY meaning of these words*

>
He most certainly did not!  He presumably agreed to what he / thought/ you meant by the words.
>
Since there is a natural interpretation of those words which would be correct, and relevant to a discussion concerning a simulating HD, my GUESS would be that he thought that was what you were saying: basically, the D in the quote below is clearly intended to represent *one* *specific* input whose halt status is being determined, namely the input D.
>
There is talk of "would never stop running if not aborted", which is saying that if H were replaced by a UTM (which never aborts its input) THEN UTM(D) WOULD RUN FOREVER.  That amounts to the same thing as saying that H has determined [through examination of its simulation steps] that D does not halt [when run directly/ natively].  Of course if H has determined that D does not halt, there's no point in simulating further, and H can just decide "non- halting" straight away.
>
NOTE: I said UTM( *D* ), not UTM(UTM) or UTM(D2) where D2 is some modified version of D that reflects changes to the embedded copy of modified H internal to D.  The role of D in all this is /data/ viz the string representing the particular D being discussed.  The role of H is /code/, H being the halt decider deciding the input D.  D does not change when applying the "simulated D would never stop unless aborted", or imagining whatever hypothetical changes to H you are thinking of - only code of H is being (hypothetically) changed.

>
I suppose I should have made this clear, as you get confused by this point - The TM description D which is not changing, includes the [TM description of the] embedded copy of [original] H.  I.e. H without any of your hypothetical imagined changes.
>
Much better still, stop imagining hypothetical changes to things and phrase things by introducing new objects with new names when required, so that a given name always means the same thing....
>
For example:  rather than saying "DDD emulated by HHH cannot return whatever number of steps HHH simulates from 1 to oo" or whatever, say:
>
    "suppose HHH_n is a SHD which simulates its corresponding input DDD_n for
     n steps before aborting.  Then for each n, HHH_n does not simulate DDD_n as far as
     DDD_n's return."
>
That way it's clear that the DDD_n are all different programs, none of which is simulated to its return statement.  The way you say it above sounds like you have ONE DDD whose simulation never returns however far it is simulated!  That would be a non-halting DDD, but that's not the situation at all.  You don't want to invite deliberate confusion, do you?  (Each DDD_n is different, and each / would/ return if simulated further, e.g. perhaps DDD_2 simulated by HHH_100 simulates as far as its final ret and so on.)
>
Mike.
>

>
People proved to fail to NOT comprehend it when it is
said that way. They get stuck in a shell game.

>
You often say that you don't express something in a clear way, because "people get confused" when you say it that way.  There is never any evidence whatsoever that anybody but you is confused about these points.  What you really mean is that when clearly worded your confusions are more easily seen to be mistakes - which is not in your interest it seems.
>

>
*This is a better way to say that*
∄HHH ∈ X86 emulators that emulate 0 to ∞ steps of DD |
(DD emulated by HHH reaches its own final halt state)
>
The category of correct emulator HHH where DD is emulated
by HHH and the emulated DD reaches its final halt state
DOES NOT EXIST.

>
There are a few problems with that wording.  :
>
1)  The main problem is you are still Using a fixed term DD in a

 To refer to a class of computations.
 

deliberate attempt to suggest there is one single input DD that however far you simulate it it never halts.

 It seems obvious to me that I never said anything like this.
 

Hey for sure that means DD never halts, right - it's almost the definition of non-halting!  EXCEPT... THERE IS NO SUCH DD. Every HHH fails to simulate /its corresponding DD/ as far as that DD's halt state,

  Because of recursive emulation.
 

but other simulators can simulate it to its final halt state.
>

 Their input does not have a pathological relationship with them.
 

That confusion was /the reason/ for my previous post, so for you to say your wording is better when it ignores that problem is just nonsense. At best you're just missing the point.  I'll say it again:
>

 int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 Everyone here has been trying to get away with simply ignoring
the pathological relationship that DD defines with HHH.
 

You need to make it clear that the DD is dependent on the chosen HHH.

 I have slapped people in the face with that for at
least three years.
 

You might adopt Linz's notation, with a decider HHH having associated input HHH^, but you would need to explain that notation close to its use.  Better still would be to introduce an operator like MAKE_NEMESIS , which converts a halt decider H to its nemesis input MAKE_NEMESIS(H). That seems clearest for emphasising that MAKE_NEMESIS(HHH) [aka your DD] is a different input for each HHH.  Or (as most maths people would do) just explain clearly in words!
>

  All that we need to know is to correct the gap
in the theory of computation and understand that
Turing Computable functions are requires to derive
their outputs by applying finite string transformations
to their inputs.
 When HHH(DD) applies the finite string
transformations specified by the x86
language to its input,THIS INPUT CANNOT
POSSIBLY HALT NO MATTER WHAT HHH DOES.
 

2)  use of "duffer-speak".  Duffer-speak is when non-maths people try to trick readers into thinking they are mathematically literate by including what they believe is "proper maths notation, like a real maths person would use".  But they lack all understanding of the terms and when they would actually be used, so the result is an instant "crank warning" for the reader:
>
   MAAARP  MAAARP  MAARP  Crank Warning:  duffer-speak detected!   :)
>
Practically everything you say is duffer-speak, so this is not a problem you can solve in general. But specifically for your "better wording" example above:
>

 Does this mean that you disagree that Turing
Computable functions must derive outputs by applying
finite string transformations to their inputs ???
 

-  "..that emulate 0 to ∞ steps..".  It is not possible for any HHH to / not/ emulate 0 to ∞ steps, so the phrase should just be omitted as it adds nothing but potential confusion.
     But I know the real reason you want to keep the phrase is / because/ it is misleading, again suggesting that there is a single DD which, no matter how far you simulate it it never halts.  As explained above that is the exact opposite of the actual situation!
>

 What I want to achieve is universal consensus
that HHH is correct to reject DD as not halting.
 

-  Using "silly" maths notation unnecessarily.  If you examine maths texts, you'll see they do not introduce fancy maths notation and expressions to make simple high level propositions.  They explain them in english.  Of course there are some exceptions, but your use of ∄, ∈, and "category" are all examples where it is unnecessary, and suggest "crank trying to sound how he/she thinks real maths people talk, so he/ she will be taken more seriously".  It has the opposite effect!  Also it's silly using HHH when your other posts already discuss one specific HHH that you have coded.  Why are there 3 Hs?  And 2 Ds?
>
-------------------
Putting all the above together, how about:
>
-  When a simulating halt decider H simulates its corresponding input H^
    [where H^ is constructed from H according to the Linz HP proof specification],
    H does not simulate H^ as far as H^'s final halt state.
>

 It <IS NOT> that there is something wrong with H.
It has always been that there is something wrong with D.
 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 The simulated ⟨Ĥ⟩ ⟨Ĥ⟩ can never reach its simulated
final state  ⟨Ĥ.qn⟩ because it continues to call
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ in recursive emulation.

Only in your dreams this is an infinite recursion. There is only a finite recursion, because it aborts. So it does not continue.
A correct simulator would simulate itself, including Halt7.c and see that there is a conditional abort, concluding that an infinite recursion cannot be proven. This incorrect behaviour of H does not tell anything about the behaviour of its input.

 (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

Until it aborts and the it returns. Dreaming of an infinite recursion is no substitute for the verifiable fact that it aborts and halts.

 

A bit too clear for you I imagine, as there is nothing to mislead readers into thinking that any particular H^ never halts - only that its corresponding H never simulates it that far.

 The outer H is always one execution trace ahead of the
next inner one. The means that unless the outer H
aborts then none of them do.
 

Also, everybody here (I believe) understands and agrees with this (or very similar) wording. Maybe even you agree??  After all, it's just a rewording of what you said, right?
>
If you used a similar wording you could stop arguing around points where everybody agrees, and move on to whatever comes next.  But of course you /want/ the confusion, so will try to claim that /my/ wording confuses people [..because people reading my wording /don't/ get confused in the way that you are.. :) ]
>
>
Mike.