Liste des Groupes | Revenir à theory |
On 7/6/2025 4:23 PM, Alan Mackenzie wrote: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:
[ .... ]
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".
I specifically mean that this x86 machine code[ .... ]
Is emulated by an x86 emulator named HHH.
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.
*Not at all there are two pieces*
(1) HHH(DD) does correctly determine that its input
specifies non halting behavior.
(2) The directly executed DD() does not contradict this.
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.
It is just like you are saying that all huge things
are always very tiny. The high level of abstraction
of C is not any 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,
This should be something you learn in the first year of CS.
It is like an auto mechanic asking me: What is a spark plug?
The first thing that every programmer learns is that an
C language interpreter is not the same thing as a compiler.
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".
Whether endless recursion happens depends on whether HHH(DD) returns 0.
Not at all.
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
*Don't erase this part make sure that you respond to it*
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)...
Others have pointed out problems with your reasoning here over a long
period of time. I don't want to repeat that.
No one has ever pointed out any actual error
in this reasoning. Others have kept acting
like they have no idea what recursion is.
The above x86 machine code emulated by HHH according
to the semantics of the x86 language has zero vagueness
and zero ambiguity.
The above code roughly maps to the (TM equivalent)
RASP machine architecture.
Until you understand that DD emulated by HHH
according to the semantics of the x86 language
cannot possibly reach its own final halt state
your understanding will remain woefully deficient.
No sense going over any other points until after
you get this point.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
Les messages affichés proviennent d'usenet.