On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/6/2025 5:16 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/5/2025 2:07 PM, Alan Mackenzie wrote:
[ .... ]
That's what I'm saying. Those proofs of the halting theorem are free
from mistakes.
More to the point, it is YOU who cannot point to any mistakes in them.
[ .... ]
They are valid proofs. Your work, if it contradicts those proofs (which
isn't at all clear) can thus be dismissed without further consideration.
The is the ad ignorantiam error.
https://en.wikipedia.org/wiki/Argument_from_ignorance
Atheists have made that their doctrine.
Garbage! I say again, if your proposition contradicts a known truth,
then it is necessarily false, and can be discarded.
There is a subtle difference between your original
statement and this one. Known truths are not exactly
the same thing as the result of a proof unless the
proof is inherently infallible.
[ .... ]
Turing machine partial halt deciders compute the mapping
from their actual inputs to the actual behavior that these
inputs specify.
And a fourth. There's some semblance of truth in there, but it's very
confused.
It is not at all confused. I know exactly what it means.
It's very confused to everybody but you, then.
Sloppy wording is your technique to get people to go down to your level
of discussion. That involves many posts trying just to tie you down to
specific word meanings, and is very tiresome and unrewarding. I decline
to get involved any further.
*Yet as I claimed you found no actual mistake*
I've found plenty of actual mistakes. I was a software developer by
profession.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Then you should know that DD simulated by HHH
according to the semantics of the C programming
language cannot possibly reach its own "return"
statement final halt state.
An argument like this is at such a low level of abstraction as to be near
valuless.
It is really weird that you are calling a 100% complete
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
But analysing it a bit further, it is not clear exactly what
you mean by "simulated by HHH".
Do you have any idea what "simulation" means?
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162
[0000216b] e862f4ffff call 000015d2
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
DD emulated by HHH according tot eh semantics of the x86
language cannot possibly reach its own "ret" instruction
is as concrete as I can get. This might not make sense if
you have no idea what an x86 emulator is.
It's quite clear that DD will reach its
return statement if HHH(DD) returns 0.
So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?
Let me tell you the punchline so that you can
see why I said those things.
Despite what I said last post, I will actually go to the trouble of
analysing your sloppy expression.
Because directly executed Turing machines cannot
possibly be inputs to Turing machine deciders this
makes them outside of the domain of these deciders.
It's entirely unclear what a "directly executed Turing machine" is. Most
of the time turing machines are theoretical constructs used for proving
theorems. They can be executed, but rarely are.
No reply to this? Do you agree with me that "directly executed turning
machine" is not a coherent notion?
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD); // DDD finite string of x86 code emulated by HHH
DDD(); // DDD directly executed
}
It's unclear what you mean by a turing machine being an input to a turing
machine. Read up about universal turing machines to get a bit of
background.
The directly executed DDD() is not an input to HHH.
Vague word salad again.
We have the exact same thing in the Linz proof.
You do not. There is no concept of "directly executed" in turing
machines, and Linz's proof concerns turing machines. Other people here
have said that one of the reasons you present your propositions as C, and
even some x86 assembly language, is to avoid the precision afforded by
turing machines. I'd tend to agree with them, here.
Ĥ is applied to ⟨Ĥ⟩ is the directly executed Ĥ.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly
executed Ĥ.
When Ĥ is applied to ⟨Ĥ⟩ // adapted from bottom of page 319
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt
Ĥ applied to ⟨Ĥ⟩ is the directly executed Ĥ ⟨Ĥ⟩
not ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>> When a partial halt decider is required to report
on the direct execution of a machine this requirement
is bogus.
See above. That paragraph is meaningless.
That you do not understand a paragraph does not entail
that it is meaningless.
That paragraph has no precise meaning. You could chose to reformulate it
so that it does, but I don't think you want to do that.
I can't tell what paragraph is being referred to.
This means that the behavior of DD() is none of the damn
business of HHH, thus does not contradict HHH(DD)==0.
*If you disagree this only proves that you do not understand*
It's fully obscure what DD() and HHH mean, and thus impossible to
affirm or contradict the meaningless "HHH(DD)==0".
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code).
Again, it is impossible to "detect" many non-terminating patterns
That is the strawman error of changing what I said and then
rebutting these changed words. DD simulated by HHH is a
non-halting pattern that HHH does recognize.
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
and (as
you have found out here) it is easy mistakenly to "detect" such a
pattern when it's not there at all.
The no one here seems to understand what recursion is
does not create any actual rebuttal at all.
HHH(DD) does correctly detect that DD simulated by HHH
according to the semantics pf the C programming language
cannot possibly reach its own "return"statement final
halt state.
See above. By the way, people concerned with computation theory use
turing machines, which are well-defined, simple, and powerful. They lack
the complexity, ambiguity, and unsuitability for theoretical work of real
world programming languages like C.
Yet they have vagueness that C does not have.
They do not. That assertion is down to your general lack of
understanding of abstract things.
I make abstract things 100% concrete so that vagueness
and ambiguity cannot possibly exist.
C is a fully operational high level programming language.
Yes. Which makes it unsuitable for proving things in computation theory.
Not at all. Many things can be proven in computation theory in C.
Hardly any real world algorithm requires unlimited memory. Every
single detail of all of human general knowledge is a finite set.
TM's are at such a low level that it could take hundreds
of instructions to just move a single value in memory.
That assertion is down to your general lack of understanding of abstract
things. Although true, it is utterly irrelevant to the normal use of
turing machines.
It seems dumb to stick with the ambiguity and vagueness
of abstractions when they can be translated into 100%
concrete specifications.
[ .... ]
Any mindless idiot can disagree. Showing an error and proving
that it is an actual mistake requires much more than this.
Indeed. All you have done is disagree with one of the proofs of the
halting theorem. You have yet to show an error in it. That will be
difficult, because there aren't any.
There are two errors:
(1) The false assumption that TM's report on the behavior
of the directly executed machine "if Ĥ applied to ⟨Ĥ⟩ halts"
(see above).
That assumption does not appear in the pertinent proofs. Indeed, those
proofs concern turing machines, which have no concept of "directly
executed", as explained above.
I already proved otherwise and you ignored the proof.
Ĥ applied to ⟨Ĥ⟩ is direct execution.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H *is not direct execution* of ⟨Ĥ⟩ ⟨Ĥ⟩
(2) That simulating partial halt decider Ĥ.embedded_H is
incorrect to transition to Ĥ.qn on input ⟨Ĥ⟩ ⟨Ĥ⟩.
The proofs concern purported halt deciders, not partial halt deciders.
The actual proofs themselves only actually deal with
one specific input. They purport to show one undecidable
example.
As I said, these proofs are correct.
That you believe that they are correct is not the
same thing as them actually being correct.
If humans are inherently infallible then we could
know that the proofs are correct.
I found mistakes and you could not understand
what I said or show that I am wrong.
-- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
-- Copyright 2025 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer
How do simulating termination analyzers work?
Re: How do simulating termination analyzers work?