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

On 4/27/25 11:46 AM, olcott wrote:

On 4/26/2025 10:07 PM, 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.
>

 I know what I meant by my words and rephrased them
so that everyone that says that HHH should report
on the direct execution of DD looks ridiculously foolish.
 A Turing Machine computable function is only allowed
to apply the finite string transformation specified by
the x86 language to its input finite string to derive
any outputs including Booleans.

Of course not. There is NOTHING about the definition of a Turing Machine that limits it to the x86 language, and in fact, the x86 language isn't actually directly usable for a Turing Machine language.

    a function is computable if there exists an algorithm
   that can do the job of the function, i.e. given an input
   of the function domain it can return the corresponding output.
   https://en.wikipedia.org/wiki/Computable_function

Which says NOTHING about a Turing machine at all. Yes, A Turing Machine is one way to express the "algorithm" specifed by the defintion.
Your problem is you are

 On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
 > I don't think that is the shell game.  PO really /has/ an H
 > (it's trivial to do for this one case) that correctly determines
 > that P(P) *would* never stop running *unless* aborted.
...
 > But H determines (correctly) that D would not halt if it
 > were not halted.  That much is a truism.

Which is just saying that in your definition of your other problem that you have been talking about (Halting is NOT about "unless aborted") or your POOP, you have a proof that DD doesn't POOP.

 <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 since H doesn't prove that D doesn't halt, since that D must be a complte program, including the exact H that it calls, which actually DOES abort and return 0 to D, so that D does halt.
So, since H can't prove the requirement, the fact that it DID abort, just makes it wrong.

 All of the scamming to try to get away with saying the simultion
was incorrect is proven to be bunk.
 

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

 Not at all. That is dumb. Of course I meant every H/D
pair that meets the pattern. H and D are the names of
categorical propositions, AKA the syllogism.

No, you keep on saying that H and its frieds are defined in Halt7.c and thus there is only one version of it.
Or are you going to appoligize for every time you corrected my for not using that stipulation.
And in the case where the stipulation is removed, the definition of D must include to code for the ONE H that instance has been paired with, and every H has been paired with a DIFFERENT D, and thus you argument breaks.

 

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

Yes
 

[when run directly/natively].

 No. The finite string transformation rules specified
by the x86 language applied to the input to HHH(DD)
forbid this. If you don't know the x86 language then
just say this, please don't bluff.

Of course not. What they forbid is just partially emulating the input, as part of the rules is that EVERY instruction will be followed by the next instruction where the PC ends up at the end of the instruction.
Thus, NONE of you HHH that answer meet your requirements.

 

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

 typedef void (*ptr)();
int HHH(ptr P);
 int DD()
{
   int Halt_Status = UTM(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 int main()
{
   UTM(DD);
}

WHich isn't a complete program, you need to include the code for the EXACT HHH that this DD is using.

 

To apply Sipser's agreed criterion in the case of your HHH/DDD code, HHH would need to simulate DDD until it determines that UTM(DDD) would never terminate.  Then at that point it can stop simulating and announce non- halting.

 DD is emulated by HHH once and then HHH emulates itself
emulating DD at this point HHH has complete proof that DD
would never stop running unless aborted.

No it doesn't.

 I am currently unsure of all of the perfect details
of the proof by mathematical induction.

Glad you admit you uncertainty.
The problem is your proof is just invalid.

 The induction variable stands for the number of
instructions of DD emulated by HHH. It ends with
the conclusion that an infinite number of instructions
of DD correctly emulated by HHH cannot possibly reach
their own final halt state.

And since for each instance of that inducatio variable, you have a different input, you haven't proven anything about any specific input.
All you have done is proven that every one of your deciders aborts its input and returns 0, and then we can use an ACTUAL CORRECT emulation of that input, and see that it halt, and thus your induction proves that all your decider are wrong.

 A proof by induction consists of two cases. The first, the base
case, proves the statement for n = 0 without assuming any knowledge
of other cases. The second case, the induction step, proves that
if the statement holds for any given case n = k then it must also
hold for the next case n = k + 1 These two steps establish that the
statement holds for every natural number n.
https://en.wikipedia.org/wiki/Mathematical_induction

Yes, which you can't do.

 

But your HHH never does determine that, and in fact we know that your UTM(DDD) DOES halt, same as running DDD directly.  So Sipser's agreed criterion  does not apply.
>

 HHH(DD) sees a repeating pattern that cannot possibly
stop running unless aborted.
 

But will be aborted, as that is what the HHH that DD calls will do, if the decider does it.

>
Of course, this is just what I imagine Sipser meant.  It would be relevant and correct, and Sipser is a sensible guy, but I don't wouldn't presume to speak on his behalf!  Neither should you.
>

 He cannot possibly mean that the correct emulation
of the input to HHH(DD) means anything else besides
applying the finite string transformation rules
specified by the x86 language to the input to HHH(DD).

Right, which isn't what HHH does, but needs to be the emulation by an emulator of the DD that calls the HHH that you claim to be correct (and thus does abort and return 0) and this clearly will reach the end.

 

Best just drop all mention of Sipser from your posts, and of others like Hehner who are not here. Rather than attempting to shut down discussion with a fallacial appeal to authority, just stick to arguing your own case!
>
Mike.
>

 You cannot correctly point to any mistake to my
Turing Machine computable function specification.

Sure we can, and have.

 When applied to the x86 language HHH(DD) must emulate
its input according to the finite string transformation
rules of the x86 language. This does include HHH emulating
itself emulating DD.

Yes, it means emulating the exact instructions of HHH emulating itself emualting DD even past the point in the emulation when the outer HHH gies up (as the x86 language specification never gives up) and that will see the emualated HHH aborting its emulation and returning 0 to DD which will halt

 

>
<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>
>

>
[..snip further appeal to authority fallacy using Ben's words!..]
>

 Professor Sipser and Ben do agree. All the nonsense
about correct simulation being the same as direct
execution is proven to be nonsense.

Nope, your claim that a partial emulation is "correct" is the nonsense.

 There are no finite string transformation rules specified
by the x86 language that derive the behavior of the directly
executed DD.
 

And what rule does the direct execution break?
Sorry, you are just proving yourself to be an ignorant liar.