olcott <
polcott333@gmail.com> wrote:
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:
[ .... ]
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.
That's a category error. Mathematical proofs are not "fallible" or
"infallible", they just are. Something mathematically proven is a higher
grade of truth than other known truths because of its certainty.
That's not to say that mathematics is a fixed certainty. It is under
continual development with new theorems and their proofs being discovered
continually.
Unless your world outlook is sort of sollipsist, where the only thing
that truly exists is yourself.
[ .... ]
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.
A complete concrete specification would necessarily include a description
of what you mean by "simulation". But my point was that rather than
sticking to the abstract nature of the proof, you're chipping tiny pieces
out of it and dealing with those. The proof you claim to refute has no
notion of simulation, for example; it doesn't need it.
That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.
It doesn't. See above.
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.
It is a waste of time to discuss things at such an unnecessarily low
level of abstraction.
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?
Yes. I'm not sure you do, though, which is why I was prompting you to be
more concrete. When Alan Turing published his seminal paper, he took a
very great deal of space specifying exactly what he meant by a "machine".
[ .... ]
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?
Whether endless recursion happens depends on whether HHH(DD) returns 0.
Others have pointed out problems with your reasoning here over a long
period of time. I don't want to repeat that.
[ .... ]
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 Ĥ.
OK, that's a start, but it doesn't apply to turing machines.
[ .... ]
DD simulated by HHH is a non-halting pattern that HHH does recognize.
That is disputed by everybody else on this newsgroup.
[ .... ]
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.
Your postings are stuffed full of vagueness and ambiguity. Turing
machines are defined precisely and mathematically. C is a ragbag of
conventions which has happened haphazardly over many decades. Don't get
me wrong, I like C, but it comes a distant second place when describing
computational theory precisely.
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.
I'm not convinced. But certainly anything in computation theory which
can be proved with C can be proven in turing machines.
Hardly any real world algorithm requires unlimited memory. Every
single detail of all of human general knowledge is a finite set.
But these finite sets are of unbounded size.
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.
Not at all. Working at an appropriate level of abstraction saves work
and makes problems tractable by concentrating on the essentials. Most of
your posts here are at a very low level of abstraction, and take enormous
amounts of effort to deal with. That's one reason why I scarcely bother.
[ .... ]
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.
You haven't. You can't, since you don't understand what the work prove
means.
Ĥ applied to ⟨Ĥ⟩ is direct execution.
What follows is an example of unnecessary complication caused by too low
a level of abstraction.
⟨Ĥ⟩ ⟨Ĥ⟩ 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.
Vague and meaningless.
The proof shows that for any purported halting decider, there exists a
program such that the purported decider cannot correctly decide.
As I said, these proofs are correct.
That you believe that they are correct is not the
same thing as them actually being correct.
<Sigh>. I also believe that 2 + 2 = 4. Are you suggesting this is
different from 2 + 2 actually being 4?
If humans are inherently infallible then we could
know that the proofs are correct.
If that is your world view, then there is virtually nothing which comes
into the category "true" for you. That would explain quite a bit about
your posting over the last many years.
Proofs are, by their nature, correct. An incorrect proof is an oxymoron.
I found mistakes and you could not understand
what I said or show that I am wrong.
You did not find mistakes. You have barely even acknowledged the
existence of the proof, never mind finding mistakes in it.
And the burden of proof is not mine. It is yours to show you are
correct. Quite clearly, you cannot meet that burden.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
-- Alan Mackenzie (Nuremberg, Germany).
How do simulating termination analyzers work?
Re: How do simulating termination analyzers work?