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.
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_functionOn 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.
<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>
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.
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 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);
}
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.
I am currently unsure of all of the perfect details
of the proof by mathematical induction.
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.
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_inductionBut 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.
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).
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.
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.
>
<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.
There are no finite string transformation rules specified
by the x86 language that derive the behavior of the directly
executed DD.
-- Copyright 2025 Olcott"Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
Re: Refutation of Turing’s 1936 Halting Problem Proof Based on Self-Referential Conflation as a Category (Type) Error
Re: Refutation of Turing’s 1936 Halting Problem Proof Based on Self-Referential Conflation as a Category (Type) Error
