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/2024 3:35 PM, Richard Damon wrote:

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.
 

No shit-for-brains that is not true.
An emulator is ALWAYS isomorphic to an interpreter.

HHH is not an "interpreter" or an "emulator" it is a decider, just like

HHH <is> an emulator shit-for-brains. That it is more
that an emulator does not mean it is not an emulator.
Not only is HHH an emulator it is a complete emulator
it correctly emulates the whole set of x86 instructions
that are in Halt7.obj.

all halt deciders / termination analyzers. It may use partial emulation as a method, but it fails to meet the definition of a full emulator.
 

No shit-for-brains. Your severe brain damage keeps
insisting that a non-terminating input be emulated
completely. It emulates terminating inputs completely.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer