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

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

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

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

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

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

On 11/18/2024 8:56 AM, Richard Damon wrote:

On 11/18/24 8:49 AM, olcott wrote:

On 11/18/2024 3:19 AM, joes wrote:

Am Sun, 17 Nov 2024 20:35:43 -0600 schrieb olcott:

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:

>

I referred to every element of an infinite set of encodings of HHH.

>
Do you mean they are parameterised by the number of steps they simulate?
>

>
No I do not mean that.

>
Then your arguement is based on an equivocation.
>

Whether or not DDD emulated by HHH ever reaches its
own "return" instruction final halt state has nothing
to do with any of the internal working of HHH as long
as each HHH emulates N steps of its input according
to the semantics of the x86 language.

>
Except that the behavior DOES depend on if that HHH returns.
>
Of course, your subjective, non-semantic property of "emulated by HHH" is just a meaningless term, so doesn't really mean anything, so your statement is just nonsense anyway.
>

>
You are a damned liar trying to get away with lying about
the effect of the pathological relationship that DDD specifies.
>
>

>
Nope, you are a just a damned liar making claims without any form of actual logic behind them.
>
Do you have ANY source that backs your claims about what you claim?
>

>
DEFECTION FOR BRAINS
DDD emulated by HHH specifies that HHH emulates
itself emulating DDD such that no such DDD can ever
reach its "return" instruction final halt state.
>
*Professor Hehner recognized this repeating process before I did*
   From a programmer's point of view, if we apply an interpreter to a
   program text that includes a call to that same interpreter with that
   same text as argument, then we have an infinite loop. A halting
   program has some of the same character as an interpreter: it applies
   to texts through abstract interpretation. Unsurprisingly, if we apply
   a halting program to a program text that includes a call to that same
   halting program with that same text as argument, then we have an
   infinite loop. (Hehner:2011:15)
>
[5] E C R Hehner. Problems with the Halting Problem, COMPUTING2011 Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe Germany, invited, 2011 October 20-21; Advances in Computer Science and Engineering v.10 n.1 p.31-60, 2013
https://www.cs.toronto.edu/~hehner/PHP.pdf
>

>
Note, HHH is not a "interpreter" tasked with recreating the behavior of the input.
>

 An emulator is isomorphic to an interpreter shit-for-brains.

But both are only that if they never stop.
HHH is not an "interpreter" or an "emulator" it is a decider, just like all halt deciders / termination analyzers. It may use partial emulation as a method, but it fails to meet the definition of a full emulator.
So, you are just caught in your lies.
Which is HHH?
Is it an emulator/simulator/interpretor, in which case to do its job it must not stop its processing till it reaches an end, or
Is it a decider/analyzer that MUST after finite time stop its processing to answer.
It can not be both unless you thing there is a finite but unbounded number which will just blow up your logic system to smithereens.

 

Thus, the arguement does not hold.
>
If HHH aborts, then the CORRECT interpreation of the input is non- halting, as DDD calls HHH which will return to DDD and thus DDD Halts.
>
>
HHH is just an incorrect decider, because it wasn't smart enough to handle this non-pathological case.