XPost: comp.theory

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
  HHH(DDD);
  return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

Except your DDD *CAN'T BE EMULTATED* by *ANY* HHH, as it is IMPOSSIBLE
to emulate the Call HHH per the x86 language from your input, as the
data isn't tnere.

This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.

But since NO HHH can do the first part of your requirements, that of
actually emulating the input, you are just proved to be an lying idiot.

Also, Computation Theory isn't interested in Subjective Non-semantic
problems like yours, but only objective problems, especially those that
are semantic (which means one that actually IS based on the FINAL
behavior, after an unbounded number of steps) properties.

Your ignorance of that fact just shows your utter stupidity.

It doesn't what the emulation of HHH is, if it is only finite, only the unbounded emulation of that input (Which will be halting if that DDD is
based on an HHH that answers after finite time).

THe HHH that DOES a semantic emulation unfortunately never answers, so
fails to be the needed decider.

So, you just struck out twice.

You then keep on lying about it, which gets your ejected from the logic
pool..

Sorry, that is just the facts, you are showing you are just too stupid
to have your idea have any merits, and thus even if there was something
to your ideas, you have probably successfully killed them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
  HHH(DDD);
  return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.

I will also add, that since you have dropped your requirements on HHH
(or are seeming to try to divorse yourself from previous assumptions)
there are MANY HHH that can complete the emulation, they just fail to be
"pure functions".

And once you define HHH to need to be a "pure function", you hit the
impass that your are trying to define DDD by a DIFFERENT definition of a "Program" which is what emulation is normally defined to be on, as your
DDD is missing code that is needed to actually make it a program.

All this adds up to showing that you don't really understand the basics
of the field you are talking about, as you keep on making "rookie" errors.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/17/24 3:49 PM, olcott wrote:

On 11/17/2024 1:56 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

Except your DDD *CAN'T BE EMULTATED* by *ANY* HHH, as it is IMPOSSIBLE
to emulate the Call HHH per the x86 language from your input, as the
data isn't tnere.

In patent law this is called incorporation by reference.

And you need to PRECISELY specify what you are referencing.

I referred to every element of an infinite set of encodings
of HHH. You already know that it is ridiculously stupid
that you suggest I should write them all down.

And thus admit that you are not talking sense, as each HHH that you
think of creates a DIFFERENT program DDD

When each of them correctly emulates N instructions of its
input then N instructions have been correctly emulated. It
is despicably dishonest of you to say that when N instructions
have been correctly emulated that no instructions have been
correctly emulating.

No, it is dishonest for you to lie.

I never said that N instructions correctly emulated is no instructions correctly emulated, just that it isn't a correct emulation that provides
the answer for the semantic property of halting, which requires
emulating to the final state or an unbounded number of steps.

So, all I am saying is that just N steps correctly emulated is less that
an unbounded number of steps, which is at TRUE statement, and you
disagreement just shows that you are just a stupid liar.

The problem seems to stem from the fact that you are just ignorant of
the rules, and ignorance of the rules is not an excuse, particularly
after you have been warned about it.

You are just proving how little you know by insisting on keeping to your strawmen.

This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.

But since NO HHH can do the first part of your requirements, that of
actually emulating the input, you are just proved to be an lying idiot.

Also, Computation Theory isn't interested in Subjective Non-semantic
problems like yours, but only objective problems, especially those
that are semantic (which means one that actually IS based on the FINAL
behavior, after an unbounded number of steps) properties.

Your ignorance of that fact just shows your utter stupidity.

It doesn't what the emulation of HHH is, if it is only finite, only
the unbounded emulation of that input (Which will be halting if that
DDD is based on an HHH that answers after finite time).

THe HHH that DOES a semantic emulation unfortunately never answers, so
fails to be the needed decider.

So, you just struck out twice.

You then keep on lying about it, which gets your ejected from the
logic pool..

Sorry, that is just the facts, you are showing you are just too stupid
to have your idea have any merits, and thus even if there was
something to your ideas, you have probably successfully killed them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.

I will also add, that since you have dropped your requirements on HHH
(or are seeming to try to divorse yourself from previous assumptions)
there are MANY HHH that can complete the emulation, they just fail to
be "pure functions".

The damned liar despicably dishonest attempt to get away
with changing the subject away from DDD reaching its final
halt state.

Which is just what YOU are doing, as "Halting" and what a "Program" is
are DEFINED, and you can't change it.

DDD "Reaching its final state" is a property of the UNBOUNDED emulation
of the input, not your LIE about the finite emulation that your deciders do.

For EVERY HHH that you have that answers non-halting, the ACTUAL
PROPERTY about Halting for the input DDD is that it HALTS. PERIOD.

Your "But HHH didn't get there" is just your attempt to LIE with a
strawman. The Emulation by HHH is just not a valid property to be asking
about, because it is not an OBJECTIVE property.

Truth is based on OBJECTIVE properties, which don't depend on who you ask.

You are just proving you are too stupid to talk about the field, in
pargt because you just don't undetstand what Truth is, or how logic works.

Sorry, but that is just the FACTS.

You just project exactly like Trump, everything you accuse others of
doing is exactly what you do yourself, so you seem to think that
everyone does it.

Sorry, but you are just killing your reputation and leaving a legacy of
your deceit and stupidity.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.

I will also add, that since you have dropped your requirements on
HHH (or are seeming to try to divorse yourself from previous
assumptions) there are MANY HHH that can complete the emulation,
they just fail to be "pure functions".

The damned liar despicably dishonest attempt to get away
with changing the subject away from DDD reaching its final
halt state.

Which is just what YOU are doing, as "Halting" and what a "Program" is
are DEFINED, and you can't change it.

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT
PROGRAM WHEN I ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as both of
those are operations done on PROGRAMS.

You are just admitting that what you are talking about has NOTHING to do
with the field of study you are trying to talk about, because you are
just too confused about what things mean.

Sorry, but the words you are trying to use have technical meanings are
terms of art, and to ignore that meaning just makes you into a LIAR.

You are of course welcome to try to fully define another field that you
are working in, but until you actually do that, you are stuck in the
official classical field.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/17/24 9:35 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:44 PM, olcott wrote:

On 11/17/2024 4:03 PM, Richard Damon wrote:

On 11/17/24 3:49 PM, olcott wrote:

On 11/17/2024 1:56 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

Except your DDD *CAN'T BE EMULTATED* by *ANY* HHH, as it is
IMPOSSIBLE to emulate the Call HHH per the x86 language from your
input, as the data isn't tnere.

In patent law this is called incorporation by reference.

And you need to PRECISELY specify what you are referencing.

I referred to every element of an infinite set of encodings
of HHH. You already know that it is ridiculously stupid
that you suggest I should write them all down.

And thus admit that you are not talking sense, as each HHH that you
think of creates a DIFFERENT program DDD

When each of them correctly emulates N instructions of its
input then N instructions have been correctly emulated. It
is despicably dishonest of you to say that when N instructions
have been correctly emulated that no instructions have been
correctly emulating.

No, it is dishonest for you to lie.

I never said that N instructions correctly emulated is no
instructions correctly emulated, just that it isn't a correct
emulation that provides the answer for the semantic property of
halting, which requires emulating to the final state or an unbounded
number of steps.

void Infinite_Recursion()
{
   Infinite_Recursion();
   return;
}

You are stupid liar. A smart liar would not be caught
in a lie with such a simple counter-example
THAT IS NEITHER EMULATED TO THE FINAL STATE NOR AN
UNBOUNDED NUMBER OF STEPS TO DETERMINE NON-HALT STATUS.

No, but it is the fact that it CAN be emulated for an unbounded number
of steps that makes it non-halting.

Your rebuttals are stupid.
It cannot be emulated for an unbounded number of steps.
That is a stupid thing to say.

So, you mean a UTM doesn't exist?

HHH can't emulate for an unbounded number of steps and give an answer,
but a UTM can, since it isn't required to "give an answer" just to
emulate the input.

If you were not stupid you could say that it cannot possibly
reach its "return" instruction final halt state even in a
hypothetical number of steps.

Why would I say that, when it has been shown that it CAN reach its
return instruction in a finite number of steps (for the complete and
correct emulation of any DDD that calls an HHH that answers).

Your problem is somehow you mind thinks that only HHH can do an
emulation, whkch is just a falsehood based on your mind thinking that
truth is subjective.

Sorry, but you are just showing hwo STUPID you are and how little you understand what you are talking about.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.

I will also add, that since you have dropped your requirements >>>>>>>> on HHH (or are seeming to try to divorse yourself from previous >>>>>>>> assumptions) there are MANY HHH that can complete the emulation, >>>>>>>> they just fail to be "pure functions".

The damned liar despicably dishonest attempt to get away
with changing the subject away from DDD reaching its final
halt state.

Which is just what YOU are doing, as "Halting" and what a
"Program" is are DEFINED, and you can't change it.

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT
PROGRAM WHEN I ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as both of
those are operations done on PROGRAMS.

No stupid I provided a published paper that includes the
termination analysis of C functions.

Look again at what they process. C functions that include all the
functions they call.

You stupidly claimed termination analysis is only done
on programs. I proved that you were stupidly wrong on
pages 24-27 of the PDF of this paper.

Automated Termination Analysis of C Programs https://publications.rwth-aachen.de/record/972440/files/972440.pdf

The problem here is you are mixing language between domains. Just read
the TITLE of that paper, it is doing analysis on PROGRAMS in the
computation sense.

Yes, a computational program might be a "function" in the programing
language side, but not just any function, but only functions when you
include all the functions they call.

If you gave that analyzer your DDD input (and not include a copy of HHH)
it will almost certainly reject the input as not complete.

All you are doing is proving that you are just totally ignorant of the
material you are talking about, and just quoting by rote
non-understanding things you have seen.

Sorry, but that is the cost of claiming to be doing "important" work in
a field you do not actually understand, you just prove your stupidity.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.

I will also add, that since you have dropped your requirements >>>>>>>> on HHH (or are seeming to try to divorse yourself from previous >>>>>>>> assumptions) there are MANY HHH that can complete the emulation, >>>>>>>> they just fail to be "pure functions".

The damned liar despicably dishonest attempt to get away
with changing the subject away from DDD reaching its final
halt state.

Which is just what YOU are doing, as "Halting" and what a
"Program" is are DEFINED, and you can't change it.

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT
PROGRAM WHEN I ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as both of
those are operations done on PROGRAMS.

No stupid I provided a published paper that includes the
termination analysis of C functions.

Look again at what they process. C functions that include all the
functions they call.

You stupidly claimed termination analysis is only done
on programs. I proved that you were stupidly wrong on
pages 24-27 of the PDF of this paper.

Automated Termination Analysis of C Programs https://publications.rwth-aachen.de/record/972440/files/972440.pdf

The problem here is you are mixing language between domains. Just read
the TITLE of that paper, it is doing analysis on PROGRAMS in the
computation sense.

Yes, a computational program might be a "function" in the programing
language side, but not just any function, but only functions when you
include all the functions they call.

If you gave that analyzer your DDD input (and not include a copy of HHH)
it will almost certainly reject the input as not complete.

All you are doing is proving that you are just totally ignorant of the
material you are talking about, and just quoting by rote
non-understanding things you have seen.

Sorry, but that is the cost of claiming to be doing "important" work in
a field you do not actually understand, you just prove your stu

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/18/24 1:41 PM, olcott wrote:

On 11/18/2024 10:16 AM, Richard Damon wrote:

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.

I will also add, that since you have dropped your requirements >>>>>>>>>> on HHH (or are seeming to try to divorse yourself from
previous assumptions) there are MANY HHH that can complete the >>>>>>>>>> emulation, they just fail to be "pure functions".

The damned liar despicably dishonest attempt to get away
with changing the subject away from DDD reaching its final
halt state.

Which is just what YOU are doing, as "Halting" and what a
"Program" is are DEFINED, and you can't change it.

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT
PROGRAM WHEN I ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as both
of those are operations done on PROGRAMS.

No stupid I provided a published paper that includes the
termination analysis of C functions.

Look again at what they process. C functions that include all the
functions they call.

You stupidly claimed termination analysis is only done
on programs. I proved that you were stupidly wrong on
pages 24-27 of the PDF of this paper.

Automated Termination Analysis of C Programs
https://publications.rwth-aachen.de/record/972440/files/972440.pdf

The problem here is you are mixing language between domains.

I said the termination analysis applies to C functions
you said that it does not. No weasel words around it
YOU WERE WRONG!

Termination analysis applies to FUNCTIONS, FULL FUNCTIONS, ones that
include everything that is part of them. Those things, in computation
theory, are called PROGRAMS.

Your DDD doesn't meet that requirement, as you explicityly try to
exclude the HHH that it calls as part of it.

Thus, you are just proving that you ane nothing but a liar.

Which you prove even by your own definitions, as you trim off the parts
you can't handle to take things out of context.

You are just proving your utter stupidity and complete ignoracne of what
you talk about.

You have ABSOLUTELY ZERO references about "Just C Functions, even one
that call parts that aren't included", just like you have zero evidence
for your claims and zero brains that you can apply to the problem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/18/24 2:07 PM, olcott wrote:

On 11/18/2024 1:02 PM, Richard Damon wrote:

On 11/18/24 1:41 PM, olcott wrote:

On 11/18/2024 10:16 AM, Richard Damon wrote:

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.

This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.

I will also add, that since you have dropped your
requirements on HHH (or are seeming to try to divorse
yourself from previous assumptions) there are MANY HHH that >>>>>>>>>>>> can complete the emulation, they just fail to be "pure >>>>>>>>>>>> functions".

The damned liar despicably dishonest attempt to get away >>>>>>>>>>> with changing the subject away from DDD reaching its final >>>>>>>>>>> halt state.

Which is just what YOU are doing, as "Halting" and what a
"Program" is are DEFINED, and you can't change it.

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT
PROGRAM WHEN I ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as
both of those are operations done on PROGRAMS.

No stupid I provided a published paper that includes the
termination analysis of C functions.

Look again at what they process. C functions that include all the
functions they call.

You stupidly claimed termination analysis is only done
on programs. I proved that you were stupidly wrong on
pages 24-27 of the PDF of this paper.

Automated Termination Analysis of C Programs
https://publications.rwth-aachen.de/record/972440/files/972440.pdf

The problem here is you are mixing language between domains.

I said the termination analysis applies to C functions
you said that it does not. No weasel words around it
YOU WERE WRONG!

Termination analysis applies to FUNCTIONS, FULL FUNCTIONS, ones that
include everything that is part of them. Those things, in computation
theory, are called PROGRAMS.

The top of PDF page 24 are not programs defection for brains. https://publications.rwth-aachen.de/record/972440/files/972440.pdf

Those *ARE* "Computation Theory" Programs.

They are also LEAF functions, unlike your DDD.

NOTHING in that paper (form what I can see) talks about handling non-leaf-functions with including all the code in the routines it calls.

Therefore, to match, your input DDD needs to include ALL the code for
HHH and everything it calls to be handled by this system.


You are just proving your ignorance of what you are talking about.

Sorry, but you reputation is down there at the bottom, and you are just smashing it into smaller pieces.

Hope you like things on the hot side, since that seems to be where you
are headed,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/18/24 3:21 PM, olcott wrote:

On 11/18/2024 1:23 PM, Richard Damon wrote:

On 11/18/24 2:07 PM, olcott wrote:

On 11/18/2024 1:02 PM, Richard Damon wrote:

On 11/18/24 1:41 PM, olcott wrote:

On 11/18/2024 10:16 AM, Richard Damon wrote:

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>>>>>>> [0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N >>>>>>>>>>>>>>> to infinity number of steps of DDD cannot possibly >>>>>>>>>>>>>>> reach its "return" instruction final halt state. >>>>>>>>>>>>>>>
This applies to every DDD emulated by any HHH no >>>>>>>>>>>>>>> matter the recursive depth of emulation. Thus it is >>>>>>>>>>>>>>> a verified fact that the input to HHH never halts. >>>>>>>>>>>>>>>

I will also add, that since you have dropped your
requirements on HHH (or are seeming to try to divorse >>>>>>>>>>>>>> yourself from previous assumptions) there are MANY HHH >>>>>>>>>>>>>> that can complete the emulation, they just fail to be >>>>>>>>>>>>>> "pure functions".

The damned liar despicably dishonest attempt to get away >>>>>>>>>>>>> with changing the subject away from DDD reaching its final >>>>>>>>>>>>> halt state.

Which is just what YOU are doing, as "Halting" and what a >>>>>>>>>>>> "Program" is are DEFINED, and you can't change it.

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT
PROGRAM WHEN I ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as >>>>>>>>>> both of those are operations done on PROGRAMS.

No stupid I provided a published paper that includes the
termination analysis of C functions.

Look again at what they process. C functions that include all
the functions they call.

You stupidly claimed termination analysis is only done
on programs. I proved that you were stupidly wrong on
pages 24-27 of the PDF of this paper.

Automated Termination Analysis of C Programs
https://publications.rwth-aachen.de/record/972440/files/972440.pdf >>>>>>>

The problem here is you are mixing language between domains.

I said the termination analysis applies to C functions
you said that it does not. No weasel words around it
YOU WERE WRONG!

Termination analysis applies to FUNCTIONS, FULL FUNCTIONS, ones that
include everything that is part of them. Those things, in
computation theory, are called PROGRAMS.

The top of PDF page 24 are not programs defection for brains.
https://publications.rwth-aachen.de/record/972440/files/972440.pdf

Those *ARE* "Computation Theory" Programs.

They are also  LEAF functions, unlike your DDD.

NOTHING in that paper (form what I can see) talks about handling non-
leaf-functions with including all the code in the routines it calls.

Since the halting problem is defined to have the input
call its own termination analyzer and the termination
analyzer is itself required to halt then any sequence
of this input that would prevent it from halting IS A
NON-HALTING SEQUENCE THAT MUST BE ABORTED AND CANNOT
BE ALLOWED TO CONTINUE.

It is like I say that all black cows are black and
are cows and you disagree.

Nope, just shows your stupidity,

The "Halting Problem" is the problem about giving the decider a
representation of a program and its input, and seeing if such a decider
can be found that answers correct about the halting behavior of that program/data given to it.

It says NOTHING about the program reperesented by the input "calling"
its own termination analyzer, thought that would be a valid input, since
that is a valid program, and the correct decider needs to handle ALL inputs.

The proof takes any specific decider, (arbitrarily chosen) and build an
input using a copy of the decider which that one decider, no matter how
it processes its input, will give the wrong answer. Note, each decider
gets a DIFFERENT input, there isn't just one input that defeats them all.

If that ONE SPECIFIC decider says that the input built that way will
halt, then that input will be of a program that loops forever, and the
decider is proven to be incorrect.

If that ONE SPECIFIC decider says that the input built that way will
never halt, then that input will be a program that halts, and the
decider is proven to be incorrect.

If that ONE SPEICIFIC "decider" ends up never halting on that input,
then the "decider" is shown to not be a decider.

If that ONE SPECIFIC decider ends up "crashing" and halting on a
non-answer, then that decider is proven to be incorrect.

The decider a given input will show broken is fixed an unchangable
before we build the input, and it behavior for this input fixed by the
nature of programs. That it doesn't give the correct answer isn't the
fault of the input, but of the programmer that wrote it and claimed it
was correct.

You just don't seem to know enough about programs to understand that
their behavior is determined by their code, they do not have "choice" to
change their "mind".


YOU are the one claiming that the field full of white cows has black
cows because you are wearing blackout glasses and can't see anything.


Soryy, but that is just the simple truth, but a simple truth that seems
to be beyond your ability to understand, because it requires you to
understand the concept of following the rules.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/18/24 6:18 PM, olcott wrote:

On 11/18/2024 3:36 PM, Richard Damon wrote:

On 11/18/24 3:21 PM, olcott wrote:

On 11/18/2024 1:23 PM, Richard Damon wrote:

On 11/18/24 2:07 PM, olcott wrote:

On 11/18/2024 1:02 PM, Richard Damon wrote:

On 11/18/24 1:41 PM, olcott wrote:

On 11/18/2024 10:16 AM, Richard Damon wrote:

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>>>>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>>>>>>>>> [0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

DDD emulated by any encoding of HHH that emulates N >>>>>>>>>>>>>>>>> to infinity number of steps of DDD cannot possibly >>>>>>>>>>>>>>>>> reach its "return" instruction final halt state. >>>>>>>>>>>>>>>>>
This applies to every DDD emulated by any HHH no >>>>>>>>>>>>>>>>> matter the recursive depth of emulation. Thus it is >>>>>>>>>>>>>>>>> a verified fact that the input to HHH never halts. >>>>>>>>>>>>>>>>>

I will also add, that since you have dropped your >>>>>>>>>>>>>>>> requirements on HHH (or are seeming to try to divorse >>>>>>>>>>>>>>>> yourself from previous assumptions) there are MANY HHH >>>>>>>>>>>>>>>> that can complete the emulation, they just fail to be >>>>>>>>>>>>>>>> "pure functions".

The damned liar despicably dishonest attempt to get away >>>>>>>>>>>>>>> with changing the subject away from DDD reaching its final >>>>>>>>>>>>>>> halt state.

Which is just what YOU are doing, as "Halting" and what a >>>>>>>>>>>>>> "Program" is are DEFINED, and you can't change it. >>>>>>>>>>>>>>

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT
PROGRAM WHEN I ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as >>>>>>>>>>>> both of those are operations done on PROGRAMS.

No stupid I provided a published paper that includes the >>>>>>>>>>> termination analysis of C functions.

Look again at what they process. C functions that include all >>>>>>>>>> the functions they call.

You stupidly claimed termination analysis is only done
on programs. I proved that you were stupidly wrong on
pages 24-27 of the PDF of this paper.

Automated Termination Analysis of C Programs
https://publications.rwth-aachen.de/record/972440/files/972440.pdf >>>>>>>>>

The problem here is you are mixing language between domains.

I said the termination analysis applies to C functions
you said that it does not. No weasel words around it
YOU WERE WRONG!

Termination analysis applies to FUNCTIONS, FULL FUNCTIONS, ones
that include everything that is part of them. Those things, in
computation theory, are called PROGRAMS.

The top of PDF page 24 are not programs defection for brains.
https://publications.rwth-aachen.de/record/972440/files/972440.pdf

Those *ARE* "Computation Theory" Programs.

They are also  LEAF functions, unlike your DDD.

NOTHING in that paper (form what I can see) talks about handling
non- leaf-functions with including all the code in the routines it
calls.

Since the halting problem is defined to have the input
call its own termination analyzer and the termination
analyzer is itself required to halt then any sequence
of this input that would prevent it from halting IS A
NON-HALTING SEQUENCE THAT MUST BE ABORTED AND CANNOT
BE ALLOWED TO CONTINUE.

It is like I say that all black cows are black and
are cows and you disagree.

Nope, just shows your stupidity,

The "Halting Problem" is the problem about giving the decider a
representation of a program and its input, and seeing if such a
decider can be found that answers correct about the halting behavior
of that program/data given to it.

It says NOTHING about the program reperesented by the input "calling"
its own termination analyzer, thought that would be a valid input,
since that is a valid program, and the correct decider needs to handle
ALL inputs.

When DDD calls HHH(DDD) THIS CANNOT BE F-CKING IGNORED.
DDD emulated by HHH does specify that HHH must emulate
itself emulating DDD.

Right, it calls HHH(DDD) and since it has been shown that HHH(DDD) does
return, DDD must return.

You can't ignore that HHH is what HHH is, and assume that the HHH that
DDD calls is something differnt.

That is just a LIE.

That you insist on playing trollish head games prevents
my formalization of True(L,x) from being accepted thus
enables hired liars to get away with climate change denial.

No, you play LYING Games, where you assume things are what they are not, because you just don't understand what truth is.

If we had a mathematically sound way if discerning truth from
lies then the Earth need not be killed by liars. You are
causing the actual death of the whole planet to get some
trollish thrills.

And wishing and hoping for the impossible is what gets us into some of
these problems.

YOU are one of the liars we need to

Severe anthropogenic climate change proven entirely with verifiable facts https://www.researchgate.net/ publication/336568434_Severe_anthropogenic_climate_change_proven_entirely_with_verifiable_facts

And by putting your name on it you taint the claims.

And of course your logic being "I can't think of anything else that
could do it" is of course great logic.

Sorry, but you are your own worse enemy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

Am Mon, 18 Nov 2024 14:21:04 -0600 schrieb olcott:

On 11/18/2024 1:23 PM, Richard Damon wrote:

On 11/18/24 2:07 PM, olcott wrote:

On 11/18/2024 1:02 PM, Richard Damon wrote:

On 11/18/24 1:41 PM, olcott wrote:

On 11/18/2024 10:16 AM, Richard Damon wrote:

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

Which is just what YOU are doing, as "Halting" and what a >>>>>>>>>>>> "Program" is are DEFINED, and you can't change it.

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT PROGRAM WHEN I >>>>>>>>>>> ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as >>>>>>>>>> both of those are operations done on PROGRAMS.

No stupid I provided a published paper that includes the
termination analysis of C functions.

Look again at what they process. C functions that include all the >>>>>>>> functions they call.

You stupidly claimed termination analysis is only done on
programs. I proved that you were stupidly wrong on pages 24-27 of >>>>>>> the PDF of this paper.
Automated Termination Analysis of C Programs
https://publications.rwth-aachen.de/record/972440/files/972440.pdf >>>>>>>

The problem here is you are mixing language between domains.

I said the termination analysis applies to C functions you said that >>>>> it does not. No weasel words around it YOU WERE WRONG!

Termination analysis applies to FUNCTIONS, FULL FUNCTIONS, ones that
include everything that is part of them. Those things, in computation
theory, are called PROGRAMS.

The top of PDF page 24 are not programs defection for brains.
https://publications.rwth-aachen.de/record/972440/files/972440.pdf

Those *ARE* "Computation Theory" Programs.
They are also  LEAF functions, unlike your DDD.
NOTHING in that paper (form what I can see) talks about handling non-
leaf-functions with including all the code in the routines it calls.

Since the halting problem is defined to have the input call its own termination analyzer and the termination analyzer is itself required to
halt then any sequence of this input that would prevent it from halting
IS A NON-HALTING SEQUENCE THAT MUST BE ABORTED AND CANNOT BE ALLOWED TO CONTINUE.

What happens when we run HHH(HHH)?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/19/24 9:44 AM, olcott wrote:

On 11/19/2024 5:56 AM, joes wrote:

Am Mon, 18 Nov 2024 14:21:04 -0600 schrieb olcott:

On 11/18/2024 1:23 PM, Richard Damon wrote:

On 11/18/24 2:07 PM, olcott wrote:

On 11/18/2024 1:02 PM, Richard Damon wrote:

On 11/18/24 1:41 PM, olcott wrote:

On 11/18/2024 10:16 AM, Richard Damon wrote:

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

Which is just what YOU are doing, as "Halting" and what a >>>>>>>>>>>>>> "Program" is are DEFINED, and you can't change it. >>>>>>>>>>>>>>

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT PROGRAM WHEN I >>>>>>>>>>>>> ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as >>>>>>>>>>>> both of those are operations done on PROGRAMS.

No stupid I provided a published paper that includes the >>>>>>>>>>> termination analysis of C functions.

Look again at what they process. C functions that include all the >>>>>>>>>> functions they call.

You stupidly claimed termination analysis is only done on
programs. I proved that you were stupidly wrong on pages 24-27 of >>>>>>>>> the PDF of this paper.
Automated Termination Analysis of C Programs
https://publications.rwth-aachen.de/record/972440/files/972440.pdf >>>>>>>>>

The problem here is you are mixing language between domains.

I said the termination analysis applies to C functions you said that >>>>>>> it does not. No weasel words around it YOU WERE WRONG!

Termination analysis applies to FUNCTIONS, FULL FUNCTIONS, ones that >>>>>> include everything that is part of them. Those things, in computation >>>>>> theory, are called PROGRAMS.

The top of PDF page 24 are not programs defection for brains.
https://publications.rwth-aachen.de/record/972440/files/972440.pdf

Those *ARE* "Computation Theory" Programs.
They are also  LEAF functions, unlike your DDD.
NOTHING in that paper (form what I can see) talks about handling non-
leaf-functions with including all the code in the routines it calls.

Since the halting problem is defined to have the input call its own
termination analyzer and the termination analyzer is itself required to
halt then any sequence of this input that would prevent it from halting
IS A NON-HALTING SEQUENCE THAT MUST BE ABORTED AND CANNOT BE ALLOWED TO
CONTINUE.

What happens when we run HHH(HHH)?

The ONLY thing that it relevant is that DDD emulated by
HHH according to the semantics of the x86 language specifies
that HHH must emulate itself emulating DDD and

No, that is IRRELEVENT as it isn't a proper question to ask a decider.

DDD emulated by HHH1 DOES NOT SPECIFY THAT HHH1 must
emulate itself emulating DDD.

But "itself" isn't the criteria, it is the emulation of DDD calling the
HHH that you claim to be correct.

Other details that are logically entailed by the above
key facts are also relevant. EVERYTHING ELSE IS IRRELEVANT.

No, the fact that you criteria is INVALID as a criteria for a decider
because it is SUBJECTIVE, not a function of just DDD, and non-semantic,
means your arguement is just invalide.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory

On 11/19/24 10:25 PM, olcott wrote:

On 11/19/2024 5:36 PM, Richard Damon wrote:

On 11/19/24 9:44 AM, olcott wrote:

On 11/19/2024 5:56 AM, joes wrote:

Am Mon, 18 Nov 2024 14:21:04 -0600 schrieb olcott:

On 11/18/2024 1:23 PM, Richard Damon wrote:

On 11/18/24 2:07 PM, olcott wrote:

On 11/18/2024 1:02 PM, Richard Damon wrote:

On 11/18/24 1:41 PM, olcott wrote:

On 11/18/2024 10:16 AM, Richard Damon wrote:

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 11/17/24 1:36 PM, olcott wrote:

Which is just what YOU are doing, as "Halting" and what a >>>>>>>>>>>>>>>> "Program" is are DEFINED, and you can't change it. >>>>>>>>>>>>>>>>

YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT PROGRAM WHEN I >>>>>>>>>>>>>>> ALWAYS SPECIFIED A C FUNCTION.

But then you can talk about "emulation" or x86 semantics, as >>>>>>>>>>>>>> both of those are operations done on PROGRAMS.

No stupid I provided a published paper that includes the >>>>>>>>>>>>> termination analysis of C functions.

Look again at what they process. C functions that include >>>>>>>>>>>> all the
functions they call.

You stupidly claimed termination analysis is only done on >>>>>>>>>>> programs. I proved that you were stupidly wrong on pages >>>>>>>>>>> 24-27 of
the PDF of this paper.
Automated Termination Analysis of C Programs
https://publications.rwth-aachen.de/record/972440/
files/972440.pdf

The problem here is you are mixing language between domains. >>>>>>>>>

I said the termination analysis applies to C functions you said >>>>>>>>> that
it does not. No weasel words around it YOU WERE WRONG!

Termination analysis applies to FUNCTIONS, FULL FUNCTIONS, ones >>>>>>>> that
include everything that is part of them. Those things, in
computation
theory, are called PROGRAMS.

The top of PDF page 24 are not programs defection for brains.
https://publications.rwth-aachen.de/record/972440/files/972440.pdf >>>>>>>

Those *ARE* "Computation Theory" Programs.
They are also  LEAF functions, unlike your DDD.
NOTHING in that paper (form what I can see) talks about handling non- >>>>>> leaf-functions with including all the code in the routines it calls. >>>>>>

Since the halting problem is defined to have the input call its own
termination analyzer and the termination analyzer is itself
required to
halt then any sequence of this input that would prevent it from
halting
IS A NON-HALTING SEQUENCE THAT MUST BE ABORTED AND CANNOT BE
ALLOWED TO
CONTINUE.

What happens when we run HHH(HHH)?

The ONLY thing that it relevant is that DDD emulated by
HHH according to the semantics of the x86 language specifies
that HHH must emulate itself emulating DDD and

No, that is IRRELEVENT as it isn't a proper question to ask a decider.

It has been the correct question to ask a simulating halt decider
for more than two years now. My treatment for cancer will be every
day for a year beginning next week.

Nope. IT may be what you WANT it to be, but you don't get to change the question.

It may be the correct quesiton for your POOP in PO-nonsense theory, but
it isn't the correct question for a Halt Decider, and isn't even valid
for a decider in computation theory.

The fact that you keep on trying to claim it just proves that you are
just an ignorant idiot that turned himself into a pathological liar
because of his reckless disregard to the truth.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)