Op 10.aug.2024 om 19:37 schreef olcott:

On 8/10/2024 12:23 PM, Richard Damon wrote:

On 8/10/24 10:24 AM, olcott wrote:

On 8/10/2024 9:00 AM, Fred. Zwarts wrote:

Op 10.aug.2024 om 15:37 schreef olcott:

On 8/10/2024 8:21 AM, Fred. Zwarts wrote:

Op 10.aug.2024 om 14:06 schreef olcott:

On 8/10/2024 6:57 AM, Richard Damon wrote:

On 8/10/24 7:30 AM, olcott wrote:

On 8/10/2024 3:29 AM, Mikko wrote:

On 2024-08-09 14:51:51 +0000, olcott said:

On 8/9/2024 4:03 AM, Mikko wrote:

On 2024-08-08 13:18:34 +0000, olcott said:

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

Each HHH of every HHH that can possibly exist definitely >>>>>>>>>>>>> *emulates zero to infinity instructions correctly* In >>>>>>>>>>>>> none of these cases does the emulated DDD ever reach >>>>>>>>>>>>> its "return" instruction halt state.

The ranges of "each HHH" and "every HHH" are not defined above >>>>>>>>>>>> so that does not really mean anything.

Here is something that literally does not mean anything: >>>>>>>>>>> "0i34ine ir m0945r (*&ubYU  I*(ubn)I*054 gfdpodf["

Looks like encrypted text that might mean something.

"Colorless green ideas sleep furiously"

This could be encrypted text, too, or perhaps refers to some >>>>>>>>>> inside knowledge or convention.

I defined an infinite set of HHH x86 emulators.

Maybe somewnete but not in the message I commented.

I stipulated that each member of this set emulates
zero to infinity instructions of DDD.

That doesn't restrict much.

*I can't say it this way without losing 90% of my audience* >>>>>>>>>>> Each element of this set is mapped to one element of the >>>>>>>>>>> set of non-negative integers indicating the number of
x86 instructions of DDD that it emulates.

It is easier to talk about mapping if is given a name.

*This one seems to be good*
Each element of this set corresponds to one element of
the set of positive integers indicating the number of
x86 instructions of DDD that it emulates.

That would mean that only a finite number (possibly zero) of >>>>>>>>>> instructions is emulated. But the restriction to DDD does not >>>>>>>>>> seem reasonable.

*The set of HHH x86 emulators are defined such that*

I thopught HHH was a deider?

Each element of this set corresponds to one element of
the set of positive integers indicating the number of
x86 instructions of DDD that it correctly emulates.

And only those element of the set that either reach the final
state, or simulate forever are "correct" emulators of the whole >>>>>>>> program, suitable to show halting.

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

In other words even though it is dead obvious to
us that a complete simulation of DDD simulated by HHH

is impossible, because HHH is programmed to abort and, therefore,
it is unable to do a complete simulation.

A complete simulation of DDD by a pure x86 emulator
named HHH cannot possibly reach its own "return"
instruction halt state.

Indeed, HHH fails to reach its own halt state. HHH cannot possibly
simulate itself up to its halt state.
Which proves that the simulation is incomplete and, therefore,
incorrect.

That an emulation of an input is necessary correct no matter
what-the-Hell it does as long as it conforms to the semantics
of the x86 language is either over your head or you persistently
lie about it.

Which isn't "what the hell it does". but a correct x86 emulation by
the semantic of the x86 language will ALWAYS and ONLY behave EXACTLY
like that input when run as a program,

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its simulated D would never
    stop running unless aborted then

    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

That is true in every case except when an input calls its
own simulating halt decider.

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

*The set of HHH x86 emulators are defined such that*
Each element of this set corresponds to one element of the set
of positive integers indicating the number of  x86 instructions
of DDD that it emulates.

In the above set no DDD ever reaches its own “return”
instruction halt state thus every HHH can correctly report this.

If they report 'the simulation failed', then the report is correct.
But it is easy to make a simulator that always returns 'the simulation
failed'. It would be correct, nevertheless.
But that has nothing to do with a halt decider, or a correct simulation.

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

On 8/10/24 2:11 PM, olcott wrote:

On 8/10/2024 12:51 PM, Richard Damon wrote:

On 8/10/24 1:37 PM, olcott wrote:

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then

     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

That is true in every case except when an input calls its
own simulating halt decider.

Nope. No exeptions. That is just another of your "I made it up but
can't prove it but it must be true" lies.

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

*The set of HHH x86 emulators are defined such that*
Each element of this set corresponds to one element of the set
of positive integers indicating the number of  x86 instructions
of DDD that it emulates.

But every one that emulates for a finite number of steps, and then
returns create a halting DDD, so you claim is just disproven.

Changing the title indicates a reply that I can ignore.
I am only replying to a single thread of communication
with you.

I just sometimes correct your title, because it is wrong.

For instance, if HHH is defined to be a Halt Decider, it MUST map the
input to the behavior of the direct execution of the machine represented
by the input, which if HHH(DDD) returns to main, in returns to DDD, so
the mapping it is REQUIRED to compute (to be correct) is Halting.

If HHH computes a mapping based on its aborted simulation of its input,
then it is NOT a "Halt Decider", but something else. Since the mapping
it is computing differs based on the decider, it isn't even a fixed
property of the input, so isn't even a valid "property" for a decider
unless you define the property for THAT PARTICUAL HHHs simulaiton, and
thus you infinite set of "deciders" is looking at an infinite set of "properties", which isn't something that is normally considered valid.

Sorry, you are just showing you don't know what you are talking about.

*Maybe your ADD has always been much worse than I ever expected*
We have been over all of these same points hundreds of times.

Right, you have made the same LIES over and over, and I keep on
correcting you, but you seem too stupid to be able to learn. I pity the
angel that has been assigned to keep your behavior books in heaven and
has to keep track of all your lies.

When each element of the outer-most directly executed SHH
corresponds to one element of the set of positive integers
indicating the number of x86 instructions of DDD that it
emulates none of the emulated instances of HHH ever returns.

And EVERY ONE Of them doesn't get the right answer.

The ones that do a finite number of instructions, and then return create
a HALTING DDD, because the DDD they are looking at calls THEM, so if
they return to their caller of main, they return to their caller of DDD,
and thus DDD is halting.

The fact that their simulation didn't get to that point, just shows that
it was just a PARTIAL simulation which doesn't actually show the full
behavior fo the input, and then the programmer (YOU) gave them faulty
logic to try to compute the behavior.

Your problem is you conflate the behavior of the program emulated, with
the partial emulation of that program. Once you talk about "halting",
partial emulations are no longer determinative of that property, only
direct exectution or complete emulations.

THAT IS WHAT THE C SOURCE CODE MEANS
THAT IS WHAT THE X86 CODE MEANS

Well, the x86 instruction of DDD says that it will do exactly what its
direct execution does, and says that the code of HHH is PARRT of the
code of DDD, as that comes out of the semantics of the x86 langugage.

It also comes out of the C programming language, which says that a
program consists of ALL the translation units that define the program,
and DDD isn't a valid program if we don't have the translation unit with
HHH.

This also means that changing the translation unit with HHH, changes the program DDD, whether you want to consdier that or not, and thus the
correct interpreation of the program DDD if dependent on the behavior of
HHH, and thus you can't look at the behavior of one DDD while assuming a different HHH then the one that DDD actually was calling.

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

On 8/10/24 3:15 PM, olcott wrote:

On 8/10/2024 1:58 PM, Richard Damon wrote:

On 8/10/24 2:11 PM, olcott wrote:

On 8/10/2024 12:51 PM, Richard Damon wrote:

On 8/10/24 1:37 PM, olcott wrote:

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

*The set of HHH x86 emulators are defined such that*
Each element of this set corresponds to one element of the set
of positive integers indicating the number of  x86 instructions
of DDD that it emulates.

*This is the mistake that I corrected*

But since none of your traces show more that 4, that is a lie, since you haven't been able to establish the HHH itself correctly emulates ANY of
the instructions of the program DDD after the call HHH, as everything
says it jumps to something other than the correct x86 emulation of the
program DDD that it was given.

But, we can overlook that, since you fail otherways.

But every one that emulates for a finite number of steps, and then
returns create a halting DDD, so you claim is just disproven.

<snip>

And it still does. If HHH emulates for a finite number of steps, then
returns, then the PROGRAM DDD that calls that HHH will halt.

PERIOD.

PROVEN.

Only the PARTIAL emulation by HHH of that input doesn't reach that
point, because HHH has been programmed to give up too soon.

When each element of the outer-most directly executed SHH
corresponds to one element of the set of positive integers
indicating the number of x86 instructions of DDD that it
emulates none of the emulated instances of HHH ever returns.

And EVERY ONE Of them doesn't get the right answer.

*Yes it does seem to be your ADD*
We are not even talking about the right answer.

We are talking about your mistake that at least one
element of the emulated HHH returns.
*None of them ever returns no-matter-what*

No, we are talking abort the right answer to your question.

IF the topic of the sentence is "DDD", then the answer is based on the
full behavior of the program DDD, which is to halt if HHH returns.

To get the answer you want, you have to be talking about the emulation
by HHH of DDD where the topic is the emulation.


The problem seems to be that you don't understand that aspect of
grammer. the Simulation of DDD by HHH and the DDD that HHH emulated are fundamentally two different concepts, even if they look at the same code.

The emulation of DDD by HHH is a subjective property of the input, while
the behavior of DDD is an objective property that is independent of who
looks at it (but of course is a function of what HHH is put into DDD,
the tying of these together is outside that logic and just restricts
what you can actually show).

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

On 8/10/24 3:50 PM, olcott wrote:

On 8/10/2024 2:39 PM, Richard Damon wrote:

On 8/10/24 3:15 PM, olcott wrote:

On 8/10/2024 1:58 PM, Richard Damon wrote:

On 8/10/24 2:11 PM, olcott wrote:

On 8/10/2024 12:51 PM, Richard Damon wrote:

On 8/10/24 1:37 PM, olcott wrote:

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

*The set of HHH x86 emulators are defined such that*
Each element of this set corresponds to one element of the set
of positive integers indicating the number of  x86 instructions >>>>>>> of DDD that it emulates.

*This is the mistake that I corrected*

But since none of your traces show more that 4, that is a lie, since
you haven't been able to establish the HHH itself correctly emulates
ANY of the instructions of the program DDD after the call HHH, as
everything says it jumps to something other than the correct x86
emulation of the program DDD that it was given.

But, we can overlook that, since you fail otherways.

But every one that emulates for a finite number of steps, and then >>>>>> returns create a halting DDD, so you claim is just disproven.

<snip>

And it still does. If HHH emulates for a finite number of steps, then
returns, then the PROGRAM DDD that calls that HHH will halt.

*Yes this is your ADD*
We have only been talking about DDD emulated by HHH.

If you mean the emulation of DDD by HHH, you need to say so.

DDD is one and only one thing, and that is the PROGRAM DDD. The fact
that you want the DDD that is emulated by HHH doesn't change it.

You seem to need the sloppy words so you can play your shell games.

Sorry, but you are just too stupid to know the meaning of the English words.

That after hundreds of messages you can't keep track of
that seems to indicate that you are ADD is much worse
that I ever suspected. I am happy for you that you can
keep this hidden from your employer.

No, I keep on pointing out the LIE that you are trying to perpetrate.

Since you have proven that is your method, I will insist on using the
proper terms.

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

On 8/10/24 4:15 PM, olcott wrote:

On 8/10/2024 3:01 PM, Richard Damon wrote:

On 8/10/24 3:50 PM, olcott wrote:

On 8/10/2024 2:39 PM, Richard Damon wrote:

On 8/10/24 3:15 PM, olcott wrote:

On 8/10/2024 1:58 PM, Richard Damon wrote:

On 8/10/24 2:11 PM, olcott wrote:

On 8/10/2024 12:51 PM, Richard Damon wrote:

On 8/10/24 1:37 PM, olcott wrote:

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

*The set of HHH x86 emulators are defined such that*
Each element of this set corresponds to one element of the set >>>>>>>>> of positive integers indicating the number of  x86 instructions >>>>>>>>> of DDD that it emulates.

*This is the mistake that I corrected*

But since none of your traces show more that 4, that is a lie, since
you haven't been able to establish the HHH itself correctly emulates
ANY of the instructions of the program DDD after the call HHH, as
everything says it jumps to something other than the correct x86
emulation of the program DDD that it was given.

But, we can overlook that, since you fail otherways.

But every one that emulates for a finite number of steps, and
then returns create a halting DDD, so you claim is just disproven. >>>>>

<snip>

And it still does. If HHH emulates for a finite number of steps,
then returns, then the PROGRAM DDD that calls that HHH will halt.

*Yes this is your ADD*
We have only been talking about DDD emulated by HHH.

If you mean the emulation of DDD by HHH, you need to say so.

DDD is one and only one thing, and that is the PROGRAM DDD. The fact
that you want the DDD that is emulated by HHH doesn't change it.

It is a tautology that DDD correctly emulated by any HHH
cannot possibly reach its "return" instruction halt state.

But that only applies for the HHH that DOES (Completely) correctly
emulate its input DDD, and thus doesn't apply to DDD built on ANY other
of your HHH that only partially emulate their input and then returns,
those do reach the their final return instruction even though the
emulation by their HHH doesn't make it there.

You are just caught with two contradictory definitions of HHH, and thus
proof that you are a liar.

May God have mercy on those souls that lie about this
as trollish head games.

You need to be more concerned about your soul. Remember, you just told
an infinite number of lies, and repeat them every time you repeat that
claim.

It seems your one hope is that God might consider you mentally
incompetent, but being self-inflicted it probably doesn't count.

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

On 8/10/24 4:36 PM, olcott wrote:

On 8/10/2024 3:30 PM, Richard Damon wrote:

On 8/10/24 4:15 PM, olcott wrote:

On 8/10/2024 3:01 PM, Richard Damon wrote:

On 8/10/24 3:50 PM, olcott wrote:

On 8/10/2024 2:39 PM, Richard Damon wrote:

On 8/10/24 3:15 PM, olcott wrote:

On 8/10/2024 1:58 PM, Richard Damon wrote:

On 8/10/24 2:11 PM, olcott wrote:

On 8/10/2024 12:51 PM, Richard Damon wrote:

On 8/10/24 1:37 PM, olcott wrote:

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

*The set of HHH x86 emulators are defined such that*
Each element of this set corresponds to one element of the set >>>>>>>>>>> of positive integers indicating the number of  x86 instructions >>>>>>>>>>> of DDD that it emulates.

*This is the mistake that I corrected*

But since none of your traces show more that 4, that is a lie,
since you haven't been able to establish the HHH itself correctly
emulates ANY of the instructions of the program DDD after the call >>>>>> HHH, as everything says it jumps to something other than the
correct x86 emulation of the program DDD that it was given.

But, we can overlook that, since you fail otherways.

But every one that emulates for a finite number of steps, and >>>>>>>>>> then returns create a halting DDD, so you claim is just
disproven.

<snip>

And it still does. If HHH emulates for a finite number of steps,
then returns, then the PROGRAM DDD that calls that HHH will halt.

*Yes this is your ADD*
We have only been talking about DDD emulated by HHH.

If you mean the emulation of DDD by HHH, you need to say so.

DDD is one and only one thing, and that is the PROGRAM DDD. The fact
that you want the DDD that is emulated by HHH doesn't change it.

It is a tautology that DDD correctly emulated by any HHH
cannot possibly reach its "return" instruction halt state.

But that only applies for the HHH that DOES (Completely) correctly
emulate its input DDD,

As I have countlessly proven it only requires enough correctly
emulated steps to correctly infer that the input would never
reach is "return" instruction halt state.

Except that HHH does't do that, since if HHH decides to abort and
return, then the DDD that it is emulating WILL return, just after HHH
has stopped its emulation.

You just confuse the behavior of DDD with the PARTIAL emulation that HHH
does, because you lie about your false "tautology".

Denying a tautology seems to make you a liar. I only
say "seems to" because I know that I am fallible.

Claiming a false statement is a tautology only make you a liar.

In this case, you lie is that the HHH that you are talking about do the "correct emulation" you base you claim on.

That is just a deception like the devil uses, has just a hint of truth,
but the core is a lie.

*You are stuck in repeat mode with nothing new*
You either
(a) Deny tautologies
(b) Change the subject with the strawman deception
(c) Pure ad hominem with no reasoning at all.

The problem is (a) your "tautolgy" only applies to the HHHs that you

don't then talk about, the ones that only emulate forever and never answer.

All other DDDs do halt.

(b) YOU logic is the strawman deception, because YOU are the one
changing the meanig.

(c) You just don't understand what the ad hominem falacy is. I don't say
you must be wrong because you are "stupid" or some other attribute, I
logically show that you are wrong, with a logical arguement, and then
point out how your refusal to understand that error demonstartes your
mental and moral condition.

Now, the fact that you try to justify YOUR unsubstantiated position by
trying to stick labels on me, but not try to actually defend your work,
just shows that YOU are the one doing the fallacy, and that you are
effectively admitting you have nothing to base you defense on, so are
just trying to get away with a fallacy.

Sorry, you are just proving how stupid you are, and that you are so
stupid you can't even understand your error, which is the worse kind of
stupid you can be.

The fact that you don't even try to base you logic on ANY actual
accepted basis just proves you have nothing to work from.

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

On 8/10/24 5:18 PM, olcott wrote:

On 8/10/2024 3:58 PM, Richard Damon wrote:

On 8/10/24 4:36 PM, olcott wrote:

As I have countlessly proven it only requires enough correctly
emulated steps to correctly infer that the input would never
reach is "return" instruction halt state.

Except that HHH does't do that, since if HHH decides to abort and
return, then the DDD that it is emulating WILL return, just after HHH
has stopped its emulation.

You just confuse the behavior of DDD with the PARTIAL emulation that
HHH does, because you lie about your false "tautology".

Denying a tautology seems to make you a liar. I only
say "seems to" because I know that I am fallible.

Claiming a false statement is a tautology only make you a liar.

In this case, you lie is that the HHH that you are talking about do
the "correct emulation" you base you claim on.

That is just a deception like the devil uses, has just a hint of
truth, but the core is a lie.

What I say is provably correct on the basis of the
semantics of the x86 language.

Nope.

The x86 language says DDD will Halt if HHH(DDD) returns a value.

*You are stuck in repeat mode with nothing new*
You either
(a) Deny tautologies
(b) Change the subject with the strawman deception
(c) Pure ad hominem with no reasoning at all.

The problem is (a) your "tautolgy" only applies to the HHHs that you

don't then talk about, the ones that only emulate forever and never
answer.

Each element of this set corresponds to one element of
the set of positive integers indicating the number of
x86 instructions of DDD that it correctly emulates.

Right, and for EVERY finite number N, your HHH(DDD) will return to DDD,
so DDD will return, it just returns after HHH has aborted its emulation
of that DDD.

In other words you forgot that the set of positive numbers has no end.

Right, but true for all is true for all.

Given the full details of your set of HHH, we can compute the number of instructions that DDD will execute before it halts as a function of the
number of actual x86 instructions that HHH emulates.

Remember, every HHH creates a NEW program DDD, so you can't use one
trace to try to support the others.

All other DDDs do halt.

In other words you forgot that never reaching a final
halt state does not count as halting.

But it does reach its final halt state, it is just the partial emulation
of it by HHH didn't.

Rememver

(b) YOU logic is the strawman deception, because YOU are the one
changing the meanig.

(c) You just don't understand what the ad hominem falacy is.

When your whole "rebuttal" is nothing besides insults.

But it isn't, unless you consider it an insult to point out the actual definitions of wrods, or the actual behavior of a program.

The rebuttal stand on their own without the statments where I use the
fact that you are wrong to show the clear state of your mind,

I don't say you must be wrong because you are "stupid" or some other
attribute, I logically show that you are wrong, with a logical
arguement, and then point out how your refusal to understand that
error demonstartes your mental and moral condition.

Now, the fact that you try to justify YOUR unsubstantiated position by
trying to stick labels on me, but not try to actually defend your work,

I have totally proven my work, you can't keep track
of this proof from one message to the next.

Nope. You haven't proven anything.

You have made CLAIMS, not PROOF.

Where is your reference to the base accepted truths of the system that
you built your argument on.

Where is the statement of the truth preserving operations to combine
those statement to get to you claim.

Nowhere, because you don't have a proof, and I am not sure you know how
to make one. It seems you just know some phylosophical arguement
techniques, which are NOT "proofs" in a formal system.

It seems you just don't understand what you are working in, and are
jusdt totally lost in it, just as you are lost in life since you base
you life on lies and deceit.

You try to claim some tautologies, but refuse to clean up your sloppy
language that makes the statements not actually tautologies under the definitions that you are trying to use.

just shows that YOU are the one doing the fallacy, and that you are
effectively admitting you have nothing to base you defense on, so are
just trying to get away with a fallacy.

Sorry, you are just proving how stupid you are, and that you are so
stupid you can't even understand your error, which is the worse kind
of stupid you can be.

The fact that you don't even try to base you logic on ANY actual
accepted basis just proves you have nothing to work from.

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

On 8/10/24 5:37 PM, olcott wrote:

On 8/10/2024 4:33 PM, Richard Damon wrote:

On 8/10/24 5:18 PM, olcott wrote:

On 8/10/2024 3:58 PM, Richard Damon wrote:

On 8/10/24 4:36 PM, olcott wrote:

As I have countlessly proven it only requires enough correctly
emulated steps to correctly infer that the input would never
reach is "return" instruction halt state.

Except that HHH does't do that, since if HHH decides to abort and
return, then the DDD that it is emulating WILL return, just after
HHH has stopped its emulation.

You just confuse the behavior of DDD with the PARTIAL emulation that
HHH does, because you lie about your false "tautology".

Denying a tautology seems to make you a liar. I only
say "seems to" because I know that I am fallible.

Claiming a false statement is a tautology only make you a liar.

In this case, you lie is that the HHH that you are talking about do
the "correct emulation" you base you claim on.

That is just a deception like the devil uses, has just a hint of
truth, but the core is a lie.

What I say is provably correct on the basis of the
semantics of the x86 language.

Nope.

The x86 language says DDD will Halt if HHH(DDD) returns a value.

HHH is called by main() there is no directly executed DDD()
any where in the whole computation.

Except in your requirements, and we can see what it does by adding a
call to DDD from main, since nothing in your system calls main.

Sorry, you don't get to say that DDD doesn't have directly executed
behavior because you never called it.

You are just showing you utter ignorance of what you talk about.

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

On 8/10/24 6:41 PM, olcott wrote:

On 8/10/2024 4:53 PM, Richard Damon wrote:

On 8/10/24 5:37 PM, olcott wrote:

On 8/10/2024 4:33 PM, Richard Damon wrote:

On 8/10/24 5:18 PM, olcott wrote:

On 8/10/2024 3:58 PM, Richard Damon wrote:

On 8/10/24 4:36 PM, olcott wrote:

As I have countlessly proven it only requires enough correctly
emulated steps to correctly infer that the input would never
reach is "return" instruction halt state.

Except that HHH does't do that, since if HHH decides to abort and
return, then the DDD that it is emulating WILL return, just after
HHH has stopped its emulation.

You just confuse the behavior of DDD with the PARTIAL emulation
that HHH does, because you lie about your false "tautology".

Denying a tautology seems to make you a liar. I only
say "seems to" because I know that I am fallible.

Claiming a false statement is a tautology only make you a liar.

In this case, you lie is that the HHH that you are talking about
do the "correct emulation" you base you claim on.

That is just a deception like the devil uses, has just a hint of
truth, but the core is a lie.

What I say is provably correct on the basis of the
semantics of the x86 language.

Nope.

The x86 language says DDD will Halt if HHH(DDD) returns a value.

HHH is called by main() there is no directly executed DDD()
any where in the whole computation.

Except in your requirements, and we can see what it does by adding a
call to DDD from main, since nothing in your system calls main.

All that you need to know is that there is not any
directly executed DDD() anywhere in the computation.

But there ccould be, and the behavior of it is what matters.

I guess you just don't understand what the field is talking about, it
doesn't matter what is or isn't done in that one exection environment,
but what can be done.

If we can't direct run DDD, then you are just admiting your whole system
is a lie and just isn't Turing Complete.

Sorry, you don't get to say that DDD doesn't have directly executed
behavior because you never called it.

You are just showing you utter ignorance of what you talk about.

What I said is perfectly true. Your weasel word intentional
misinterpretation of what I said is NOT what I actually said.

Nope, it is a just a lie.

Want to try to show a reference for your claims?

You haven't done any yet, so you are currectly batting 0.000 on the
truth meter.

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