Re: HHH(DDD) computes the mapping from its input to HHH emulating itself emulating DDD --- anyone that says otherwise is a liar

On 11/22/24 9:50 AM, olcott wrote:

On 11/22/2024 6:20 AM, joes wrote:

Am Thu, 21 Nov 2024 15:19:43 -0600 schrieb olcott:

On 11/21/2024 3:11 PM, joes wrote:

Am Thu, 21 Nov 2024 09:19:03 -0600 schrieb olcott:

On 11/20/2024 10:00 PM, Richard Damon wrote:

On 11/20/24 9:57 PM, olcott wrote:

On 11/20/2024 5:51 PM, Richard Damon wrote:

On 11/20/24 5:03 PM, olcott wrote:

On 11/20/2024 3:53 AM, Mikko wrote:

On 2024-11-20 03:23:12 +0000, olcott said:

On 11/19/2024 4:12 AM, Mikko wrote:

On 2024-11-18 20:42:02 +0000, olcott said:

On 11/18/2024 3:41 AM, Mikko wrote:

The "the mapping" on the subject line is not correct. The
subject line does not specify which mapping and there is no
larger context that could specify that. Therefore it should
be "a mapping".
On 2024-11-17 18:36:17 +0000, olcott said:

>

My code is one example of the infinite set of every possible HHH
that emulates DDD according to the semantics of the x86 language.

Like all of them, it is unable to simulate DDD to its undeniable
halting state.

In your case you may simply not even understand what infinite recursion
is, thus cannot see the isomorphism.

>
>

But it gets the wrong answer for the halting problem, as DDD dpes
halt.

DDD emulated by HHH does not halt.

Whatever. DDD halts and HHH should return that.

IT IS NOT THE SAME INSTANCE OF DDD.

All instances of DDD behave the same (if it is a pure function and
the HHH called from it doesn't switch behaviour by a static variable).
>

 Only HHH is required to be a pure function, DDD is expressly
allowed to be any damn thing. The actual behavior of DDD
emulated by HHH is different than the actual behavior of DDD
emulated by HHH1.

But that means your question doesn't HAVE an answer, as if you can't tell the answer from JUST the input DDD, then that input doesn't have an answer.
You are just proving you don't don't understand the basics of truth.

 *ONLY BECAUSE DDD CALLS HHH AND DDD DOES NOT CALL HHH1*
Even Mike does not seem to be able to understand this.

But that is just part of the definition of DDD. If HHH is defined as to what it is, then DDD calling HHH is FULLY DEFINED and now an answer exists.
If DDD is allowed to change what it calls even if that new thing has the "same name" (which is just a form of lying by equivocation) then the behavior of DDD is just not defined.

 Note we have been on this one point about the behavior of
DDD emulated by HHH for many months and have not yet even
begun to talk about how HHH would report this behavior.
 

And, as has been pointed out to you for just as long, your question is just invalid, and to actually ask the question, you need to FULLY include the definiton of DDD, which means it includes the code for HHH, and omitting it just proves your stupidity.

The question does DDD halt?

Right, and that is a SEMANTIC property of the input, which REQUIRES it to be an actual computation, which means ALL its code must be fully defined, which your DDD doesn't do, so the question is just invalid.
That is like asking what is the sum of 1 and?
Or how tall is green.
It is just nonsense, and your failure to understand that just proves your own stupidity,

Is answered by Can DDD emulated by any HHH reach its own
"return" instruction final state?

Nope, because "Not Halting" is only defined by the inability of an UNBOUNDED emulation of the input not reaching a final state.
You are just using the wrong definition of "Halting", and making it a non-semantic property.
You are just admitting that your whole premise is just a decietful strawman arguement.
But since your idea of logic seems to include seeing how many fallacies you can use, that isn't surprising.

 The question: How could HHH determine whether or not DDD
emulated by HHH can possibly reach its own final state?
is another entirely different question.
 

Yes, but since yoiu