Liste des Groupes | Revenir à c theory |
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:
[ .... ]I specifically mean that this x86 machine code
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% completeA complete concrete specification would necessarily include a description
concrete specification "a low level of abstraction".
That HHH(DD) correctly determines that DD simulated by
HHH cannot possibly halt is a proven fact.
of what you mean by "simulation".
But my point was that rather than*Not at all there are two pieces*
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.
It need not be a Turing machine to exactly matchThat DD exactly matches the pattern of the haltingIt doesn't. See above.
problem proof inputs is also a verified fact.
It is just like you are saying that all huge thingsThus HHH(DD) does correctly determine that the haltingIt is a waste of time to discuss things at such an unnecessarily low
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.
level of abstraction.
This should be something you learn in the first year of CS.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 beNot at all. Anyone should instantly see that no HHH
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-haltingWhether endless recursion happens depends on whether HHH(DD) returns 0.
behavior pattern? DO you know what recursion is?
Others have pointed out problems with your reasoning here over a longNo one has ever pointed out any actual error
period of time. I don't want to repeat that.
[ .... ]*Those ARE Turing machines*
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 Ĥ.OK, that's a start, but it doesn't apply to turing machines.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not the directly
executed Ĥ.
[ .... ]*Yet they cannot ever point out even a single actual mistake*
DD simulated by HHH is a non-halting pattern that HHH does recognize.That is disputed by everybody else on this newsgroup.
_DD()I make abstract things 100% concrete so that vaguenessYour postings are stuffed full of vagueness and ambiguity.
and ambiguity cannot possibly exist.
Les messages affichés proviennent d'usenet.