DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
On 3/11/2025 8:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
If it correctly simulates infinitely many steps, it doesn't
terminate. Look up "infinite".
*It was dishonest of you to remove this context*
On 3/11/2025 12:42 PM, Mike Terry wrote:
(Even though it demonstrably DOES halt if not
aborted and simulated further.
That statement is stupidly false.
But your task is to decide for /any/ program, not just DDD.
No you have this WRONG.
My WHOLE effort has been to correctly determine the
halt status of the conventional halting problem proof's
"impossible" input.
This by itself is better than anyone else has ever done
with this proof since it was first presented 89 years ago.
On 3/11/2025 9:02 PM, dbush wrote:
On 3/11/2025 9:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
If it correctly simulates infinitely many steps, it doesn't
terminate. Look up "infinite".
But your task is to decide for /any/ program, not just DDD.
That, as you are so fond of saying, is 'stipulated', and you
can't get out of it. The whole point of the
Entscheidungsproblem is its universality. Ignore that, and you
have nothing.
Given that his code has HHH(DD) returning 0,
THESE ARE THE WORDS ANYONE THAT DODGES THESE
WORDS WILL BE TAKEN FOR A LIAR
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
On 3/11/2025 8:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
If it correctly simulates infinitely many steps, it doesn't terminate.
Look up "infinite".
*It was dishonest of you to remove this context*
On 3/11/2025 12:42 PM, Mike Terry wrote:
(Even though it demonstrably DOES halt if not
aborted and simulated further.
That statement is stupidly false.
But your task is to decide for /any/ program, not just DDD.
No you have this WRONG.
My WHOLE effort has been to correctly determine the
halt status of the conventional halting problem proof's
"impossible" input.
This by itself is better than anyone else has ever done
with this proof since it was first presented 89 years ago.
The lack of a counter-example
sufficiently proves that you
have no basis for *the exact meaning of my specific claim*
On 3/11/2025 9:29 PM, Richard Heathfield wrote:
On 12/03/2025 02:06, olcott wrote:
On 3/11/2025 9:02 PM, dbush wrote:
On 3/11/2025 9:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
If it correctly simulates infinitely many steps, it doesn't
terminate. Look up "infinite".
But your task is to decide for /any/ program, not just DDD.
That, as you are so fond of saying, is 'stipulated', and you
can't get out of it. The whole point of the
Entscheidungsproblem is its universality. Ignore that, and
you have nothing.
Given that his code has HHH(DD) returning 0,
THESE ARE THE WORDS ANYONE THAT DODGES THESE
WORDS WILL BE TAKEN FOR A LIAR
"THESE ARE THE WORDS ANYONE THAT DODGES THESE WORDS WILL BE
TAKEN FOR A LIAR"?
Is that all you've got? Nothing on your function's inability to
correctly decide on whether arbitrary input programs terminate,
which is a ***stipulated*** requirement for the problem.
Without that, all you have is loud.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
Look up "infinite". You keep using that word. I do not think it
means what you think it means.
DDD correctly simulated by HHH cannot
possibly f-cking halt no f-cking matter what.
On 3/11/2025 10:33 PM, olcott wrote:
Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD) cannot
possibly f-cking halt no f-cking matter what.
Obviously, so what's the next step?
DDD is a dumbed down version of DD and thus
isomorphic to DD.
DD is isomorphic to the HP
counter example input. DD simulated by HHH
cannot possibly halt.
The DD input to HHH cannot possibly halt
The question you continually fail to address is what HHH() does
with arbitrary input programs.
On 3/11/2025 10:32 PM, Richard Heathfield wrote:<snip>
On 12/03/2025 02:29, olcott wrote:
The lack of a counter-example
I gave you three upthread. I can give you a dozen more at the
drop of a hat if you want them, but here's one [...elided...]
sufficiently proves that you
have no basis for *the exact meaning of my specific claim*
The exact meaning of your specific claim is of no consequence
You can't freaking correctly determine that nitwit unless
you first pay 100% attention to exactly what I said.
Here is is greatly dumbed down;It doesn't even start.
DDD correctly emulated by HHH DOES NOT HALT.
Anything more than this is way over your head.
On 3/11/2025 11:02 PM, Richard Heathfield wrote:
Who wrote this shit? You? Or would you like to blame someone else?
Anything more than this is way over your head.
I see.
Dipshit
https://github.com/plolcott/x86utm
On 3/11/2025 10:49 PM, Richard Heathfield wrote:
On 12/03/2025 02:33, dbush wrote:
On 3/11/2025 10:33 PM, olcott wrote:
<snip>
Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD) cannot
possibly f-cking halt no f-cking matter what.
Obviously, so what's the next step?
To show that it provides the correct answer for other
functions. This he has not yet done. Of course, it's not
impossible to get a few right...
int halts(void(*p)())
{
return 1;
}
will produce the right answer most of the time, but it's hardly
a plausible way to overturn Turing's paper. OP's decision
program has to get it right /every/ time. One failure proves
that Olcott is wrong.
DD simulated by HHH cannot possibly halt
Is the counter-example input to the HP.
Am Tue, 11 Mar 2025 21:03:35 -0500 schrieb olcott:
On 3/11/2025 8:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
lol*It was dishonest of you to remove this context*DDD correctly simulated by HHH never reaches its own "return"If it correctly simulates infinitely many steps, it doesn't terminate.
instruction and terminates normally in any finite or infinite number
of correctly simulated steps.
Look up "infinite".
On 3/11/2025 12:42 PM, Mike Terry wrote:
> (Even though it demonstrably DOES halt if not aborted and simulated
> further.
That statement is stupidly false.
It is impossible because a decider doesn't exist.But your task is to decide for /any/ program, not just DDD.No you have this WRONG.
My WHOLE effort has been to correctly determine the halt status of the
conventional halting problem proof's "impossible" input.
On 3/11/2025 8:41 PM, Richard Heathfield wrote:lol
On 12/03/2025 01:22, olcott wrote:
*It was dishonest of you to remove this context*DDD correctly simulated by HHH never reaches its own "return"If it correctly simulates infinitely many steps, it doesn't terminate.
instruction and terminates normally in any finite or infinite number
of correctly simulated steps.
Look up "infinite".
On 3/11/2025 12:42 PM, Mike Terry wrote:
(Even though it demonstrably DOES halt if not aborted and simulated further.That statement is stupidly false.
It is impossible because a decider doesn't exist.But your task is to decide for /any/ program, not just DDD.No you have this WRONG.
My WHOLE effort has been to correctly determine the halt status of the conventional halting problem proof's "impossible" input.
This by itself is better than anyone else has ever done with this proof--
since it was first presented 89 years ago.
On 3/11/2025 9:32 PM, dbush wrote:
On 3/11/2025 10:31 PM, olcott wrote:
On 3/11/2025 9:18 PM, dbush wrote:
On 3/11/2025 10:06 PM, olcott wrote:
On 3/11/2025 9:02 PM, dbush wrote:
On 3/11/2025 9:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
If it correctly simulates infinitely many steps, it doesn't
terminate. Look up "infinite".
But your task is to decide for /any/ program, not just DDD. That, >>>>>>> as you are so fond of saying, is 'stipulated', and you can't get >>>>>>> out of it. The whole point of the Entscheidungsproblem is its
universality. Ignore that, and you have nothing.
Given that his code has HHH(DD) returning 0,
THESE ARE THE WORDS ANYONE THAT DODGES THESE
WORDS WILL BE TAKEN FOR A LIAR
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
Changing the input is not allowed.
*You are simply lying that any input was ever changed*
You did precisely that when you hypothesize different code for HHH.
Changing the input is not allowed.
*THIS IS WHAT MY ORIGINAL WORDS MEANT*
HHH is the infinite set of every possible C function
that correctly emulates N steps of its input where
N any finite positive integer.
On 3/11/2025 9:37 PM, dbush wrote:
On 3/11/2025 10:36 PM, olcott wrote:
On 3/11/2025 9:32 PM, dbush wrote:
On 3/11/2025 10:31 PM, olcott wrote:
On 3/11/2025 9:18 PM, dbush wrote:
On 3/11/2025 10:06 PM, olcott wrote:
On 3/11/2025 9:02 PM, dbush wrote:
On 3/11/2025 9:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
If it correctly simulates infinitely many steps, it doesn't
terminate. Look up "infinite".
But your task is to decide for /any/ program, not just DDD.
That, as you are so fond of saying, is 'stipulated', and you >>>>>>>>> can't get out of it. The whole point of the
Entscheidungsproblem is its universality. Ignore that, and you >>>>>>>>> have nothing.
Given that his code has HHH(DD) returning 0,
THESE ARE THE WORDS ANYONE THAT DODGES THESE
WORDS WILL BE TAKEN FOR A LIAR
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
Changing the input is not allowed.
*You are simply lying that any input was ever changed*
You did precisely that when you hypothesize different code for HHH.
Changing the input is not allowed.
*THIS IS WHAT MY ORIGINAL WORDS MEANT*
HHH is the infinite set of every possible C function
that correctly emulates N steps of its input where
N any finite positive integer.
In other words, you're changing the input.
Changing the input is not allowed.
It is an infinite set of HHH/DDD pairs having the
property that DDD[0] ... DDD[N] never halts.
On 3/11/2025 12:42 PM, Mike Terry wrote:
On 11/03/2025 13:46, Richard Heathfield wrote:
On 11/03/2025 13:31, olcott wrote:
On 3/11/2025 5:28 AM, Mikko wrote:
On 2025-03-10 23:41:13 +0000, olcott said:
typedef void (*ptr)();
int HHH(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void DDD()
{
HHH(DDD);
return;
}
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
That when HHH correctly emulates N steps of the
above functions that none of these functions can
possibly reach their own "return" instruction
and terminate normally.
Every competent programmer knows that the information given is
insufficient to determine whether HHH emulates at all, and whether
it emulates correctly if it does.
Since HHH does see that same pattern that competent
C programmers see it correctly aborts its emulation
and rejects these inputs as non terminating.
Whether HHH does see those patterns cannot be inferred from the information
given. Only about DDD one can see that it halts if HHH returns. In addition,
the given information does not tell whether HHH can see patterns that are >>>>> not there.
How many competent programmers you have asked?
Two C programmers with masters degrees in computer science
agree that DDD correctly emulated by HHH cannot possibly
reach its own "return" instruction and terminate normally.
Bring 'em on. Perhaps /they/ have the source to HHH, because without it
you don't have anything. (And btw whatever it is you claim to have is
far from clear, because all I've seen so far is an attempt to express
the Halting Problem in C and pseuodocode, where the pseudocode reads:
HHH(){ magic happens }
It takes newcommers a while to understand the context behind what PO is
saying, and he never bothers to properly explain it himself, and is
incapable of doing so in any rigorous fashion.
So I'll explain for you my interpretation.
His HHH is a C function called by DDD, which will "simulate" DDD().
The simulation consists of simulating the individual x86 instructions
of DDD [and functions it calls] sequentially, and may only be a
/partial/ simulation, because HHH also contains logic to analyse the
progress of the simulation, and it may decide at some point to simply
stop simulating. (This being referred to as HHH "aborting" its
simulation.)
Of course, we expect that the (partial) simulation of DDD will exactly
track the direct execution of DDD, up to the point where HHH aborts the
simulation. [This is NOT what PO's actual HHH code does, due to bugs/
design errors/misunderstandings etc., but for the purpose of PO's
current point, you might consider this to be what happens.]
So if we imagine HHH never aborts, then HHH simulates DDD(), which
calls HHH, and (simulated) HHH will again simulate DDD() - a nested
simulation. (PO calls this recursive simulation.) This continues, and
such an HHH will obviously never terminate - in particular THE
SIMULATION by outer HHH will never proceed as far as DDD's final ret
instruction. (This is genuine "infinitely recursive simulation")
OTOH if HHH logic aborts the simulation at some point, regardless of
how many nested levels of simulation have built up, it will be the
/outer/ HHH that aborts, because the outer HHH is ahead of all the
simulated HHH's in its progress and will reach its abort criterion
first. At the point where it aborts, the DDD it is simulating will
clearly not have reached its final ret instruction, as then its
simulation would have ended "normally" rather than aborting.
So whatever HHH's exact logic and abort criteria, it will not be the
case that its *simulation of DDD* progresses as far as DDD's final ret
instruction: either HHH never aborts so never terminates, or if it
does abort, the (outer) HHH simulating it will abort DDD before it gets
to the final ret instruction.
The key point here is that we are not talking about whether DDD()
halts! We are only talking about whether HHH's /simulation/ of DDD
proceeds as far as simulating the final DDD ret instruction. So at
this point we are not talking about the Halting Problem, as that is
concerned with whether DDD() halts, not whether some partial simulation
of DDD() simulates as far as the ret instruction.
Given that HHH is free to stop simulating DDD *whenever it wants*, you
might consider it rather banal to be arguing for several months over
whether it actually simulates as far as DDD's return. After all, it
could simulate one instruction and then give up, so it didn't get as
far as DDD returning - but SO WHAT!? Why is PO even considering such a
question?
[PO would say something like "/however far/ HHH simulates this remains
the case", misunderstanding the fact that here he is talking about
multiple different HHHs, each with their own distinct DDDs. (Yes, none
of those different HHHs simulate their corresponding DDD to completion,
but all of those DDD halt [if run directly], assuming their HHH aborts
the simulation at some point. We can see this just from the given code
of DDD: if HHH returns, DDD returns...)]
But if you think PO properly understands this you would be vastly
overestimating his reasoning powers and his capacity for abstract
thought. Even if you "agree" that HHH (however coded) will not
simulate DDD to completion, you would not really be "agreeing" with PO
as such, because that would imply you understand PO's understanding of
all that's been said, and that there is a shared agreement on the
meaning of what's been said and its consequences etc., and we can
guarantee that will NOT be the case! We could say PO "fractally"
misunderstands every technical concept needed to properly discuss the
halting problem (or any other technical topic).
PO's "understanding" will entail some idea that the situation means
that DDD "actually" doesn't halt, or that HHH is "correct" to say that
DDD doesn't halt.
This is a very stupid mistake:
(Even though it demonstrably DOES halt if not aborted and simulated further.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
On 3/11/2025 10:49 PM, Richard Heathfield wrote:
On 12/03/2025 02:33, dbush wrote:
On 3/11/2025 10:33 PM, olcott wrote:
<snip>
Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD) cannot
possibly f-cking halt no f-cking matter what.
Obviously, so what's the next step?
To show that it provides the correct answer for other functions. This
he has not yet done. Of course, it's not impossible to get a few right...
int halts(void(*p)())
{
return 1;
}
will produce the right answer most of the time, but it's hardly a
plausible way to overturn Turing's paper. OP's decision program has to
get it right /every/ time. One failure proves that Olcott is wrong.
DD simulated by HHH cannot possibly halt
Is the counter-example input to the HP.
Look up "infinite". You keep using that word. I do not think it means
what you think it means.
On 2025-03-11 20:29, Richard Heathfield wrote:
Look up "infinite". You keep using that word. I do not think it
means what you think it means.
If you continue to engage with Olcott,
you will discover that a
great many words don't mean what he thinks they mean.
On 3/12/2025 4:32 AM, Fred. Zwarts wrote:
Op 12.mrt.2025 om 03:39 schreef olcott:
On 3/11/2025 9:37 PM, dbush wrote:Proving that HHH[0] ... HHH[N} are unable to correctly complete the
On 3/11/2025 10:36 PM, olcott wrote:
On 3/11/2025 9:32 PM, dbush wrote:
On 3/11/2025 10:31 PM, olcott wrote:
On 3/11/2025 9:18 PM, dbush wrote:
On 3/11/2025 10:06 PM, olcott wrote:
On 3/11/2025 9:02 PM, dbush wrote:
On 3/11/2025 9:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
If it correctly simulates infinitely many steps, it doesn't >>>>>>>>>>> terminate. Look up "infinite".
But your task is to decide for /any/ program, not just DDD. >>>>>>>>>>> That, as you are so fond of saying, is 'stipulated', and you >>>>>>>>>>> can't get out of it. The whole point of the
Entscheidungsproblem is its universality. Ignore that, and >>>>>>>>>>> you have nothing.
Given that his code has HHH(DD) returning 0,
THESE ARE THE WORDS ANYONE THAT DODGES THESE
WORDS WILL BE TAKEN FOR A LIAR
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
Changing the input is not allowed.
*You are simply lying that any input was ever changed*
You did precisely that when you hypothesize different code for HHH. >>>>>>
Changing the input is not allowed.
*THIS IS WHAT MY ORIGINAL WORDS MEANT*
HHH is the infinite set of every possible C function
that correctly emulates N steps of its input where
N any finite positive integer.
In other words, you're changing the input.
Changing the input is not allowed.
It is an infinite set of HHH/DDD pairs having the
property that DDD[0] ... DDD[N] never halts.
simulation.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
In the exact same way that HHH cannot complete the
simulation of the above functions.
BECAUSE THEY SPECIFY NON-TERMINATING BEHAVIOR.
On 3/12/2025 5:46 PM, Richard Damon wrote:
On 3/12/25 10:50 AM, olcott wrote:
On 3/12/2025 8:03 AM, André G. Isaak wrote:
On 2025-03-11 20:29, Richard Heathfield wrote:
Look up "infinite". You keep using that word. I do not think it
means what you think it means.
If you continue to engage with Olcott, you will discover that a
great many words don't mean what he thinks they mean.
André
Incomplete[0] (base meaning)
Not having all the necessary or appropriate parts.
Provable[0] (base meaning)
Can be shown to be definitely true by some means.
Right, and the appropriate part for logic that it is missing is the
proofs of some of the statements.
Proofs, to SHOW something, must be finite, as we can not see something
that is infinite, as we are finite.
So then we know that G <is> TRUE because meta-math proves this.
If we are stupid enough to define a system that does not know
this then we are stupid.
On 3/12/2025 5:46 PM, Richard Damon wrote:
On 3/12/25 11:31 AM, olcott wrote:
On 3/11/2025 9:29 PM, Richard Heathfield wrote:
On 12/03/2025 02:06, olcott wrote:
On 3/11/2025 9:02 PM, dbush wrote:
On 3/11/2025 9:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
If it correctly simulates infinitely many steps, it doesn't
terminate. Look up "infinite".
But your task is to decide for /any/ program, not just DDD. That, >>>>>>> as you are so fond of saying, is 'stipulated', and you can't get >>>>>>> out of it. The whole point of the Entscheidungsproblem is its
universality. Ignore that, and you have nothing.
Given that his code has HHH(DD) returning 0,
THESE ARE THE WORDS ANYONE THAT DODGES THESE
WORDS WILL BE TAKEN FOR A LIAR
"THESE ARE THE WORDS ANYONE THAT DODGES THESE WORDS WILL BE TAKEN
FOR A LIAR"?
Is that all you've got? Nothing on your function's inability to
correctly decide on whether arbitrary input programs terminate,
which is a ***stipulated*** requirement for the problem.
Without that, all you have is loud.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
Look up "infinite". You keep using that word. I do not think it
means what you think it means.
When N steps of DDD are correctly emulated by every element
of the set of C functions named HHH that do x86 emulation and
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
WRONG, because "DDD reaching its "return" instruction" isn't defined
by the HHH that emulates it,
Thus the Liar Paradox is TRUE because it is ~TRUE
Instances of pathological self-reference
CANNOT BE CORRECTLY IGNORED !!!
On 3/12/2025 4:32 AM, Fred. Zwarts wrote:
Op 12.mrt.2025 om 03:39 schreef olcott:
On 3/11/2025 9:37 PM, dbush wrote:
On 3/11/2025 10:36 PM, olcott wrote:
On 3/11/2025 9:32 PM, dbush wrote:
On 3/11/2025 10:31 PM, olcott wrote:
On 3/11/2025 9:18 PM, dbush wrote:
On 3/11/2025 10:06 PM, olcott wrote:
On 3/11/2025 9:02 PM, dbush wrote:
On 3/11/2025 9:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
Proving that HHH[0] ... HHH[N} are unable to correctly complete theIn other words, you're changing the input.You did precisely that when you hypothesize different code for HHH. >>>>>> Changing the input is not allowed.Changing the input is not allowed.Given that his code has HHH(DD) returning 0,DDD correctly simulated by HHH never reaches its own "return" >>>>>>>>>>>> instruction and terminates normally in any finite or infinite >>>>>>>>>>>> number of correctly simulated steps.
If it correctly simulates infinitely many steps, it doesn't >>>>>>>>>>> terminate. Look up "infinite".
But your task is to decide for /any/ program, not just DDD. >>>>>>>>>>> That, as you are so fond of saying, is 'stipulated', and you >>>>>>>>>>> can't get out of it. The whole point of the
Entscheidungsproblem is its universality. Ignore that, and you >>>>>>>>>>> have nothing.
DDD correctly simulated by HHH never reaches its own "return" >>>>>>>>> instruction and terminates normally in any finite or infinite >>>>>>>>> number of correctly simulated steps.
*You are simply lying that any input was ever changed*
HHH is the infinite set of every possible C function that correctly
emulates N steps of its input where N any finite positive integer.
Changing the input is not allowed.
It is an infinite set of HHH/DDD pairs having the property that DDD[0]
... DDD[N] never halts.
simulation.
void Infinite_Loop()
void Infinite_Recursion()
In the exact same way that HHH cannot complete the simulation of the
above functions.
BECAUSE THEY SPECIFY NON-TERMINATING BEHAVIOR.
On 3/11/2025 9:29 PM, Richard Heathfield wrote:
On 12/03/2025 02:06, olcott wrote:
On 3/11/2025 9:02 PM, dbush wrote:
On 3/11/2025 9:41 PM, Richard Heathfield wrote:
On 12/03/2025 01:22, olcott wrote:
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
If it correctly simulates infinitely many steps, it doesn't
terminate. Look up "infinite".
But your task is to decide for /any/ program, not just DDD. That,
as you are so fond of saying, is 'stipulated', and you can't get
out of it. The whole point of the Entscheidungsproblem is its
universality. Ignore that, and you have nothing.
Given that his code has HHH(DD) returning 0,
THESE ARE THE WORDS ANYONE THAT DODGES THESE
WORDS WILL BE TAKEN FOR A LIAR
"THESE ARE THE WORDS ANYONE THAT DODGES THESE WORDS WILL BE TAKEN FOR
A LIAR"?
Is that all you've got? Nothing on your function's inability to
correctly decide on whether arbitrary input programs terminate, which
is a ***stipulated*** requirement for the problem.
Without that, all you have is loud.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH never reaches its
own "return" instruction and terminates normally
in any finite or infinite number of correctly
simulated steps.
Look up "infinite". You keep using that word. I do not think it means
what you think it means.
When N steps of DDD are correctly emulated by every element
of the set of C functions named HHH that do x86 emulation and
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
On 3/12/2025 10:55 PM, Richard Damon wrote:
On 3/12/25 8:28 PM, olcott wrote:
On 3/12/2025 5:46 PM, Richard Damon wrote:
On 3/12/25 10:50 AM, olcott wrote:
On 3/12/2025 8:03 AM, André G. Isaak wrote:
On 2025-03-11 20:29, Richard Heathfield wrote:
Look up "infinite". You keep using that word. I do not think it
means what you think it means.
If you continue to engage with Olcott, you will discover that a
great many words don't mean what he thinks they mean.
André
Incomplete[0] (base meaning)
Not having all the necessary or appropriate parts.
Provable[0] (base meaning)
Can be shown to be definitely true by some means.
Right, and the appropriate part for logic that it is missing is the
proofs of some of the statements.
Proofs, to SHOW something, must be finite, as we can not see
something that is infinite, as we are finite.
So then we know that G <is> TRUE because meta-math proves this.
If we are stupid enough to define a system that does not know
this then we are stupid.
Yes, we know that G is true, as from the additional information
provide in the meta-system we can reduce the infinite sequence that
can be built in the base system to a finite proof.
Note, PROOF belong to a system, and if they try to use something not
known to be true in the system, they fail to be a proof, as they don't
SHOW the needed result.
Note, the "System" can't contain all of the Meta-System, as one
important added part of the meta-system, as a set of axioms, was an
enumeration of all axioms in the base system. If we try to put that
enumeration into the base system, it becomes self-referential and we
have an infinite set of axioms, something not allowed in normal formal
logic.
It is possible to do in a meta-system, as the system has a finite
axiomization, so we just need to develope a numbering of that list of
axioms.
This seems to be part of your problem of not understanding why meta-
systems can exist and not be part of the original system, but does
describe it,
The only reason why the meta-system and the system
cannot be the same system is that semantically incorrect
expressions are not rejected as not truth bearers in
the system.
Op 12.mrt.2025 om 16:31 schreef olcott:
[snip]
When N steps of DDD are correctly emulated by every element
of the set of C functions named HHH that do x86 emulation and
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
In other words no HHH of the set of HHH/DDD pairs ever succeeds to
complete the simulation of a halting program. Failure to reach the end
of a halting program is not a great success. If all HHH in this set
fail, it would be better to change your mind and start working on
something more useful.
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
[snip]
When N steps of DDD are correctly emulated by every element
of the set of C functions named HHH that do x86 emulation and
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
In other words no HHH of the set of HHH/DDD pairs ever succeeds to
complete the simulation of a halting program. Failure to reach the end
of a halting program is not a great success. If all HHH in this set
fail, it would be better to change your mind and start working on
something more useful.
He seems to think that he's written a program that detects that
his thing hasn't 'reached its "return" instruction and
terminate[d] normally', given some number of steps, where that
number is ... the cardinality of the natural numbers.
I wonder if he knows that the set of natural numbers is
infintite, though I suspect he'd say something like, "but it's
countable!" To which I'd surmise that he has no idea what that
means.
void DDD()
{
HHH(DDD);
return;
}
Everyone here knows that when N steps of DDD are correctly
simulated by HHH that DDD never reaches its own "return"
instruction and terminates normally thus never halts.
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
[snip]
When N steps of DDD are correctly emulated by every element
of the set of C functions named HHH that do x86 emulation and
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
In other words no HHH of the set of HHH/DDD pairs ever succeeds to
complete the simulation of a halting program. Failure to reach the end
of a halting program is not a great success. If all HHH in this set
fail, it would be better to change your mind and start working on
something more useful.
He seems to think that he's written a program that detects that
his thing hasn't 'reached its "return" instruction and
terminate[d] normally', given some number of steps, where that
number is ... the cardinality of the natural numbers.
I wonder if he knows that the set of natural numbers is
infintite, though I suspect he'd say something like, "but it's
countable!" To which I'd surmise that he has no idea what that
means.
void DDD()
{
HHH(DDD);
return;
}
Everyone here knows that when N steps of DDD are correctly
simulated by HHH that DDD never reaches its own "return"
instruction and terminates normally thus never halts.
*AND THEY LIE ABOUT IT BY ENDLESSLY CHANGING THE SUBJECT*
My posthumous reviewers will condemn them.
When DDD is correctly simulated by HHH once the behavior
of DDD exactly matches the infinite recursion behavior
pattern.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
We have the exact same effect when N steps of DD
are correctly emulated by HHH. I created DDD because
some of my reviewers are not technically competent
enough to see that line 2 of DD is unreachable code
when N steps of DD are correctly simulated by HHH.
I plonked Olcott a few years ago, yet I see dozens of posts a
day a day of people replying to him.
I gather, based on reading the quoted text, that he is near the
end of a battle with cancer; that's very sad. Perhaps he should
spend what time remains to him with friends and family, and less
arguing with strangers on USENET. Maybe we could all help him
in this endeavor by not responding. I, for one, intend to take
my own advice after this post.
- Dan C.
On 3/13/2025 6:09 PM, Richard Damon wrote:
On 3/13/25 9:41 AM, olcott wrote:
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
[snip]
When N steps of DDD are correctly emulated by every element
of the set of C functions named HHH that do x86 emulation and
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
In other words no HHH of the set of HHH/DDD pairs ever succeeds to
complete the simulation of a halting program. Failure to reach the end >>>>> of a halting program is not a great success. If all HHH in this set
fail, it would be better to change your mind and start working on
something more useful.
He seems to think that he's written a program that detects that
his thing hasn't 'reached its "return" instruction and
terminate[d] normally', given some number of steps, where that
number is ... the cardinality of the natural numbers.
I wonder if he knows that the set of natural numbers is
infintite, though I suspect he'd say something like, "but it's
countable!" To which I'd surmise that he has no idea what that
means.
void DDD()
{
HHH(DDD);
return;
}
Everyone here knows that when N steps of DDD are correctly
simulated by HHH that DDD never reaches its own "return"
instruction and terminates normally thus never halts.
*AND THEY LIE ABOUT IT BY ENDLESSLY CHANGING THE SUBJECT*
No, the PARTIAL EMULATION done by HHH can't reach that point,
But a complete emulation can?
On 3/13/2025 10:03 PM, Richard Damon wrote:
On 3/13/25 10:07 PM, olcott wrote:
On 3/13/2025 6:09 PM, Richard Damon wrote:
On 3/13/25 9:41 AM, olcott wrote:
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
[snip]
When N steps of DDD are correctly emulated by every element
of the set of C functions named HHH that do x86 emulation and
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
In other words no HHH of the set of HHH/DDD pairs ever succeeds to >>>>>>> complete the simulation of a halting program. Failure to reach
the end
of a halting program is not a great success. If all HHH in this set >>>>>>> fail, it would be better to change your mind and start working on >>>>>>> something more useful.
He seems to think that he's written a program that detects that
his thing hasn't 'reached its "return" instruction and
terminate[d] normally', given some number of steps, where that
number is ... the cardinality of the natural numbers.
I wonder if he knows that the set of natural numbers is
infintite, though I suspect he'd say something like, "but it's
countable!" To which I'd surmise that he has no idea what that
means.
void DDD()
{
HHH(DDD);
return;
}
Everyone here knows that when N steps of DDD are correctly
simulated by HHH that DDD never reaches its own "return"
instruction and terminates normally thus never halts.
*AND THEY LIE ABOUT IT BY ENDLESSLY CHANGING THE SUBJECT*
No, the PARTIAL EMULATION done by HHH can't reach that point,
But a complete emulation can?
Yes, but an HHH that gives an answer doesn't do one, due to the
pathological design of the template used to build DD to the HHH it
calls (which is the only HHH that can exist, or you have violated the
basic rules of programing and logic).
We have two basic cases,
1) if HHH does the partial emulation you describe, then the complete
emulation of DD will see that DD call HHH, and it will emulate its
input for a while, then abort and theu return 0 to DD which will then
halt.
int main()
{
HHH(DDD); // No DDD can possibly ever return.
}
On 3/13/2025 2:20 PM, Fred. Zwarts wrote:
Op 13.mrt.2025 om 14:41 schreef olcott:
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
[snip]
When N steps of DDD are correctly emulated by every element
of the set of C functions named HHH that do x86 emulation and
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
In other words no HHH of the set of HHH/DDD pairs ever succeeds to
complete the simulation of a halting program. Failure to reach the end >>>>> of a halting program is not a great success. If all HHH in this set
fail, it would be better to change your mind and start working on
something more useful.
He seems to think that he's written a program that detects that
his thing hasn't 'reached its "return" instruction and
terminate[d] normally', given some number of steps, where that
number is ... the cardinality of the natural numbers.
I wonder if he knows that the set of natural numbers is
infintite, though I suspect he'd say something like, "but it's
countable!" To which I'd surmise that he has no idea what that
means.
void DDD()
{
HHH(DDD);
return;
}
Everyone here knows that when N steps of DDD are correctly
simulated by HHH that DDD never reaches its own "return"
instruction and terminates normally thus never halts.
Why would we be interested in your simulator that is not able to reach
the end of the program described in its input when direct execution
and world-class simulators are perfectly able to reach that end of
exactly the same input?
I am going to ignore all of your nonsense posts.
On 3/13/2025 10:03 PM, Richard Damon wrote:
On 3/13/25 10:07 PM, olcott wrote:
On 3/13/2025 6:09 PM, Richard Damon wrote:
On 3/13/25 9:41 AM, olcott wrote:
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
[snip]
When N steps of DDD are correctly emulated by every element
of the set of C functions named HHH that do x86 emulation and
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
In other words no HHH of the set of HHH/DDD pairs ever succeeds to >>>>>>> complete the simulation of a halting program. Failure to reach
the end
of a halting program is not a great success. If all HHH in this set >>>>>>> fail, it would be better to change your mind and start working on >>>>>>> something more useful.
He seems to think that he's written a program that detects that
his thing hasn't 'reached its "return" instruction and
terminate[d] normally', given some number of steps, where that
number is ... the cardinality of the natural numbers.
I wonder if he knows that the set of natural numbers is
infintite, though I suspect he'd say something like, "but it's
countable!" To which I'd surmise that he has no idea what that
means.
void DDD()
{
HHH(DDD);
return;
}
Everyone here knows that when N steps of DDD are correctly
simulated by HHH that DDD never reaches its own "return"
instruction and terminates normally thus never halts.
*AND THEY LIE ABOUT IT BY ENDLESSLY CHANGING THE SUBJECT*
No, the PARTIAL EMULATION done by HHH can't reach that point,
But a complete emulation can?
Yes, but an HHH that gives an answer doesn't do one, due to the
pathological design of the template used to build DD to the HHH it
calls (which is the only HHH that can exist, or you have violated the
basic rules of programing and logic).
We have two basic cases,
1) if HHH does the partial emulation you describe, then the complete
emulation of DD will see that DD call HHH, and it will emulate its
input for a while, then abort and theu return 0 to DD which will then
halt.
int main()
{
HHH(DDD); // No DDD can possibly ever return.
}
On 3/14/2025 9:10 AM, Richard Damon wrote:Important distinction.
On 3/13/25 11:53 PM, olcott wrote:
On 3/13/2025 10:03 PM, Richard Damon wrote:
On 3/13/25 10:07 PM, olcott wrote:
On 3/13/2025 6:09 PM, Richard Damon wrote:
On 3/13/25 9:41 AM, olcott wrote:
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
Since HHH doesn;t call DDD, the statement is vacuous and shows aint main()But a complete emulation can?Yes, but an HHH that gives an answer doesn't do one, due to the
pathological design of the template used to build DD to the HHH it
calls (which is the only HHH that can exist, or you have violated the
basic rules of programing and logic).
We have two basic cases,
1) if HHH does the partial emulation you describe, then the complete
emulation of DD will see that DD call HHH, and it will emulate its
input for a while, then abort and theu return 0 to DD which will then
halt.
{
HHH(DDD); // No DDD can possibly ever return.
}
fundamental ignorance of what is being talked about.
Oh, I thought it was an unconditional simulator.Yes, No HHH can emulated DDD to the end, but since halting is DEFINED
by the behavior of the program, and for every HHH that aborts and
returns, the program of DDD, as tested with:
int main()
{
DDD()
}
will return to main, that shows that every HHH that returns 0 fails to
be a Halt Decider or Termination Analyzer. PERIOD..
The only difference between HHH and HHH1 is that they are at different locations in memory. DDD simulated by HHH1 has identical behavior to
DDD() executed in main().
The semantics of the finite string input DDD to HHH specifies that itNo. DDD always specifies the one same thing.
will continue to call HHH(DDD) in recursive simulation.
The semantics of the finite string input DDD to HHH1 specifies to
simulate to DDD exactly once.
On 3/14/2025 9:10 AM, Richard Damon wrote:
On 3/13/25 11:53 PM, olcott wrote:
On 3/13/2025 10:03 PM, Richard Damon wrote:
On 3/13/25 10:07 PM, olcott wrote:
On 3/13/2025 6:09 PM, Richard Damon wrote:
On 3/13/25 9:41 AM, olcott wrote:
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
[snip]
When N steps of DDD are correctly emulated by every element >>>>>>>>>> of the set of C functions named HHH that do x86 emulation and >>>>>>>>>>
N is each element of the set of natural numbers
then no DDD of the set of HHH/DDD pairs ever reaches its
"return" instruction and terminates normally.
In other words no HHH of the set of HHH/DDD pairs ever succeeds to >>>>>>>>> complete the simulation of a halting program. Failure to reach >>>>>>>>> the end
of a halting program is not a great success. If all HHH in this >>>>>>>>> set
fail, it would be better to change your mind and start working on >>>>>>>>> something more useful.
He seems to think that he's written a program that detects that >>>>>>>> his thing hasn't 'reached its "return" instruction and
terminate[d] normally', given some number of steps, where that >>>>>>>> number is ... the cardinality of the natural numbers.
I wonder if he knows that the set of natural numbers is
infintite, though I suspect he'd say something like, "but it's >>>>>>>> countable!" To which I'd surmise that he has no idea what that >>>>>>>> means.
void DDD()
{
HHH(DDD);
return;
}
Everyone here knows that when N steps of DDD are correctly
simulated by HHH that DDD never reaches its own "return"
instruction and terminates normally thus never halts.
*AND THEY LIE ABOUT IT BY ENDLESSLY CHANGING THE SUBJECT*
No, the PARTIAL EMULATION done by HHH can't reach that point,
But a complete emulation can?
Yes, but an HHH that gives an answer doesn't do one, due to the
pathological design of the template used to build DD to the HHH it
calls (which is the only HHH that can exist, or you have violated
the basic rules of programing and logic).
We have two basic cases,
1) if HHH does the partial emulation you describe, then the complete
emulation of DD will see that DD call HHH, and it will emulate its
input for a while, then abort and theu return 0 to DD which will
then halt.
int main()
{
HHH(DDD); // No DDD can possibly ever return.
}
Since HHH doesn;t call DDD, the statement is vacuous and shows a
fundamental ignorance of what is being talked about.
Yes, No HHH can emulated DDD to the end, but since halting is DEFINED
by the behavior of the program, and for every HHH that aborts and
returns, the program of DDD, as tested with:
int main()
{
DDD()
}
will return to main, that shows that every HHH that returns 0 fails to
be a Halt Decider or Termination Analyzer. PERIOD.
The fact that it may meet your defintion of POOP says maybe you have
solvec the POOP problem, but it seems you can't even properly define
it in the nornal field of Computation Theory.
void DDD()
{
HHH(DDD);
return;
}
The only difference between HHH and HHH1 is that they are
at different locations in memory. DDD simulated by HHH1
has identical behavior to DDD() executed in main().
The semantics of the finite string input DDD to HHH specifies
that it will continue to call HHH(DDD) in recursive simulation.
The semantics of the finite string input DDD to HHH1 specifies
to simulate to DDD exactly once.
On 3/14/2025 10:55 AM, joes wrote:
Am Fri, 14 Mar 2025 10:13:41 -0500 schrieb olcott:
On 3/14/2025 9:10 AM, Richard Damon wrote:
On 3/13/25 11:53 PM, olcott wrote:
On 3/13/2025 10:03 PM, Richard Damon wrote:
On 3/13/25 10:07 PM, olcott wrote:
On 3/13/2025 6:09 PM, Richard Damon wrote:
On 3/13/25 9:41 AM, olcott wrote:
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
Since HHH doesn;t call DDD, the statement is vacuous and shows aint main()But a complete emulation can?Yes, but an HHH that gives an answer doesn't do one, due to the
pathological design of the template used to build DD to the HHH it >>>>>> calls (which is the only HHH that can exist, or you have violated
the basic rules of programing and logic).
We have two basic cases,
1) if HHH does the partial emulation you describe, then the
complete emulation of DD will see that DD call HHH, and it will
emulate its input for a while, then abort and theu return 0 to DD
which will then halt.
{
HHH(DDD); // No DDD can possibly ever return.
}
fundamental ignorance of what is being talked about.
Important distinction.
Yes, No HHH can emulated DDD to the end, but since halting is DEFINEDThe only difference between HHH and HHH1 is that they are at different
by the behavior of the program, and for every HHH that aborts and
returns, the program of DDD, as tested with:
int main()
{
DDD()
}
will return to main, that shows that every HHH that returns 0 fails
to be a Halt Decider or Termination Analyzer. PERIOD..
locations in memory. DDD simulated by HHH1 has identical behavior to
DDD() executed in main().
Oh, I thought it was an unconditional simulator. The same code cannot
produce different behaviour.
Uh no, there is only one call in either case. DD doesn't specify shitcounter-factual The semantics of the finite string input DDD to HHHThe semantics of the finite string input DDD to HHH specifies that itNo. DDD always specifies the one same thing.
will continue to call HHH(DDD) in recursive simulation.
The semantics of the finite string input DDD to HHH1 specifies to
simulate to DDD exactly once.
specifies that it will continue to call HHH(DDD) in recursive
simulation.
The semantics of the finite string input DDD to HHH1 specifies to
simulate to DDD exactly once.
The only difference between HHH and HHH1 is that they are at different locations in memory. DDD simulated by HHH1 has identical behavior toNow *that* is impossible if I swapped their addresses. Not that you
DDD() directly executed in main().
On 3/14/2025 3:02 PM, joes wrote:
Am Fri, 14 Mar 2025 10:58:39 -0500 schrieb olcott:
On 3/14/2025 10:55 AM, joes wrote:
Am Fri, 14 Mar 2025 10:13:41 -0500 schrieb olcott:
On 3/14/2025 9:10 AM, Richard Damon wrote:
On 3/13/25 11:53 PM, olcott wrote:
On 3/13/2025 10:03 PM, Richard Damon wrote:
On 3/13/25 10:07 PM, olcott wrote:
On 3/13/2025 6:09 PM, Richard Damon wrote:
On 3/13/25 9:41 AM, olcott wrote:
On 3/13/2025 6:18 AM, Dan Cross wrote:
In article <vqud4e$36e14$3@dont-email.me>,
Fred. Zwarts <F.Zwarts@HetNet.nl> wrote:
Op 12.mrt.2025 om 16:31 schreef olcott:
Since HHH doesn;t call DDD, the statement is vacuous and shows aint main()But a complete emulation can?Yes, but an HHH that gives an answer doesn't do one, due to the >>>>>>>> pathological design of the template used to build DD to the HHH it >>>>>>>> calls (which is the only HHH that can exist, or you have violated >>>>>>>> the basic rules of programing and logic).
We have two basic cases,
1) if HHH does the partial emulation you describe, then the
complete emulation of DD will see that DD call HHH, and it will >>>>>>>> emulate its input for a while, then abort and theu return 0 to DD >>>>>>>> which will then halt.
{
HHH(DDD); // No DDD can possibly ever return.
}
fundamental ignorance of what is being talked about.
Important distinction.
Yes, No HHH can emulated DDD to the end, but since halting is DEFINED >>>>>> by the behavior of the program, and for every HHH that aborts andThe only difference between HHH and HHH1 is that they are at different >>>>> locations in memory. DDD simulated by HHH1 has identical behavior to >>>>> DDD() executed in main().
returns, the program of DDD, as tested with:
int main()
{
DDD()
}
will return to main, that shows that every HHH that returns 0 fails >>>>>> to be a Halt Decider or Termination Analyzer. PERIOD..
Oh, I thought it was an unconditional simulator. The same code cannot
produce different behaviour.
counter-factual The semantics of the finite string input DDD to HHHThe semantics of the finite string input DDD to HHH specifies that it >>>>> will continue to call HHH(DDD) in recursive simulation.No. DDD always specifies the one same thing.
The semantics of the finite string input DDD to HHH1 specifies to
simulate to DDD exactly once.
specifies that it will continue to call HHH(DDD) in recursive
simulation.
The semantics of the finite string input DDD to HHH1 specifies to
simulate to DDD exactly once.
Uh no, there is only one call in either case. DD doesn't specify shit
"to HHH"; it doesn't know about its runtime environment.
Even though DDD does not know it is calling its own
simulator and HHH does not know that DDD is calling
itself, it remains a verified fact that DDD simulated
by HHH does not halt because it is calling its own
simulator in recursive simulation.
The only difference between HHH and HHH1 is that they are at differentNow *that* is impossible if I swapped their addresses. Not that you
locations in memory. DDD simulated by HHH1 has identical behavior to
DDD() directly executed in main().
could tell.
If you swapped the address that is encoded in DDD
then HHH1(DDD) would return 0 and HHH(DDD) would
return 1.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 150:09:38 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,787 |