Re: Verified facts regarding the software engineering of DDD, HHH, and HHH1 --- TYPO

On 10/26/24 9:29 PM, olcott wrote:

On 10/26/2024 8:04 PM, Richard Damon wrote:

On 10/26/24 12:26 PM, olcott wrote:

On 10/26/2024 10:55 AM, Richard Damon wrote:

On 10/26/24 11:46 AM, olcott wrote:

On 10/26/2024 10:35 AM, Richard Damon wrote:

On 10/26/24 9:55 AM, olcott wrote:

On 10/25/2024 11:07 PM, Richard Damon wrote:

On 10/25/24 7:22 PM, olcott wrote:

On 10/25/2024 5:17 PM, Richard Damon wrote:>>>

No, I said a PARTIAL emulation is an incorrect basis.
>
You are just a proven liar that twists peoples words because you don't know what you are talking about.
>

>
It is ridiculously stupid to require a complete emulation
of a non-terminating input. No twisted words there.

>
HHH doesn't need to to the complete emulation, just show that the complete emulation doesn't reach an end.
>

>
Then you admit that DDD emulated by HHH according to the
semantics of the x86 language cannot possibly reach its
own "return" instruction?
>

IF you want to call that rediculously stupid, you are just showing your own stupidity, as that IS the requirement, and you can't show anything that proves it otherwise, because you just don't know anything about the fundamental facts of what you talk about.
>

>
I am not the one stupidly requiring the compete emulation
of a non-terminating input.
>

>

The problem is that any HHH that answers for the input built on it, must have been a decider that aborts when emulating that input, and thus only does a partial emulation.
>

>
It is ridiculously stupid to require a complete emulation
of a non-terminating input. No twisted words there.

>
HHH doesn't need to to the complete emulation, just show that the complete emulation doesn't reach an end.
>
IF you want to call that rediculously stupid, you are just showing your own stupidity, as that IS the requirement, and you can't show anything that proves it otherwise, because you just don't know anything about the fundamental facts of what you talk about.
>

>
Then you admit that DDD emulated by HHH according to the
semantics of the x86 language cannot possibly reach its
own "return" instruction?
>

>
The problem is that your HHH doesn't do that,

>
Of course it doesn't do that. It is ridiculously stupid for
an emulating termination analyzer to emulate a non-terminating
input forever.
>

>
Right, but it needs to answer about what the unaborted emulation would do,

>
Exactly !!!
>

>
And the unaborted emulation HALTS, since DDD calls the HHH that does abort and return,
>
You keep on trying to lie by playing a shell game and changing the imput to the system, which includes the code of the HHH that DDD calls.
>
Sorry, you are just proving your utter stupdity.

 No you are merely contradicting yourself, thus an objective
measure of your error opposed to a subjective opinion of me.

WHERE did I contradict myself?
The CORRECT answer is based on the actual beahvior of the direct exectution of the program. That is the definition.
It is a provable fact, that the COMPLETE (and correct) emulation of the input will give the same answer as that, so is an proper equivalent for that definition.
A partial/aborted emulation does NOT meet that requirement, and thus, by itself, doesn't show the right answer.
If you can logically prove from a partial emulation, that the full emulation OF THIS EXACT INPUT, would not stop, then you can use that, BECAUSE it actually proves the criteria would be met.
Note too, "the input" must be a FULL specification of the program, and thus include ALL of the instructions it will use, and thus includes the code for HHH, so that code can not be changed. Any "Hypothetical" alternater version can not change the code that DDD is using.
Since your "logic" proceeds to change it, it is INVALID logic and doesn't prove anything.

 DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not HHH ever aborts its emulation of DDD.
 

But only if HHH does actually correctly emulate its input, which means it NEVER aborts its emulation.
Sonce that isn't the HHH that you claim to be correct, your claim is built on  a LIE,
Soorry, you are the one working with contradictions.
The Correct x86 emulation of the input to the HHH that gives the answer (which isn't what it does, so your criteria becomes a contradiciton to itself) will reach the final state, and thus your HHH is just wrong.
Sorry, you are just proving your utter stupidity, and your inability to understand what Truth actually means