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

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, and thus that isn't the DDD that we are looking at.
The ONLY HHH that woud emulate DDD according to the sematics of the x86 language is the one that doesn't abort, and if that case, and ONLY that case, DDD will not reach its return instruction, but by the conditions on that case, HHH will not answer.
This ONLY applies to the DDD that calls the HHH that does that,
If HHH does abort its emulation, then it is just a category error to try to talk about it showing that the Program DDD doesn't reach the return, and you lie creates an equivocation.
Do you mean the behavior of DDD itself doesn't reach the return, then the answer is clearly that it does, as the HHH that it calls will return to it and it will halt.
If you mean the behavior of the emulation of DDD by HHH, then the emulation doesn't reach that point, but that doesn't mean that "DDD" itself doesn't, as that is just invalid logic.

>

>

That is why HHH1 can get the right answer, because, not actually being an exact copy, it is able to emulate the input to the end, and see that it will halt.
>

>
It is an exact copy AND THE ONLY RELEVANT DIFFERENCE
IS THAT DDD CALLS HHH AND DOES NOT CALL HHH1. This
was even over Mike's head.
>
>

>
Nope, It just proves that your HHH is not a "pure function" of its input, as it uses a "hidden input" and thus just fails to even be of the right form to be a decider.
>

 We have not got to the point in the conversation where
we begin to talk about pure functions because you insist
on dodging a mandatory prerequisite point.
 

Which has an equivocation.
And, if we are not talking about "pure functions" then we can go back to the version of HHH that are not pure functions to prove you claim is false.
There exists HHH that are not pure functions that can actually fully emulate the input DDD based on themselves to the final return statement, thus disproving your claim.
Sorry, you keep on forgetting what has been shown.