Re: D correctly simulated by pure function H cannot possibly reach its, own line 06

On 5/25/24 5:29 PM, olcott wrote:

On 5/25/2024 4:18 PM, Richard Damon wrote:

On 5/25/24 5:13 PM, olcott wrote:

On 5/25/2024 4:04 PM, Richard Damon wrote:

On 5/25/24 4:20 PM, olcott wrote:

On 5/25/2024 3:16 PM, Richard Damon wrote:

On 5/25/24 3:55 PM, olcott wrote:

On 5/25/2024 2:23 PM, Richard Damon wrote:

On 5/25/24 2:27 PM, olcott wrote:

As soon as you first hit the strawman deception change-the-subject
fake rebuttal I pint this pout and erase everything else that you say.
>
*Thread renamed to be 100% precisely accurate*
Any divergence from the subject of the thread gets boilerplate reply.
>

>
In other words, you refuse to accept the meaning of your words, admitting that you plan to change them.
>

>
<snip so that *Usenet Article Lookup* finds the whole message>
http://al.howardknight.net/
>
Not at all. I simply utterly reject the dishonest dodge
of the strawman deception change-the-subject rebuttal.
>
typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }
>
The above template refers to an infinite set of H/D pairs where D is
correctly simulated by pure function H. This was done because many
reviewers used the shell game ploy to endlessly switch which H/D pair
was being referred to.
>
*Correct Simulation Defined*
    This is provided because many reviewers had a different notion of
    correct simulation that diverges from this notion.
>
    A simulator is an x86 emulator that correctly emulates at least one
    of the x86 instructions of D in the order specified by the x86
    instructions of D.
>
    This may include correctly emulating the x86 instructions of H in the
    order specified by the x86 instructions of H thus calling H(D,D) in
    recursive simulation.
>
*Execution Trace*
Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 03 of
D. This invokes H(D,D) again to repeat the process in endless recursive
simulation.
>
>

In other words, you refuse to accept the meaning of your words, admitting that you plan to change them.
>

>
Not at all and you cannot show that I disagree with the above
words to the slightest trace of any degree what-so-ever.
>
*Liar Liar Pants on fire? Will assume so until proven otherwise*
>

>
A don't say that you disagree woth them,

>
 >>> In other words, you refuse to accept the meaning of your words,
YES YOU DID, LOOK AT YOUR OWN WORDS ABOVE.
>

>
No, I accept that you want to use your stipulated definition of the words,

 Then why the Hell did you say otherwise?
Then why the Hell did you say otherwise?
Then why the Hell did you say otherwise?
Then why the Hell did you say otherwise?
Then why the Hell did you say otherwise?
 

Did you not read what I wrote?
You need to agree to the implications of those definitions before we can go on.
YOu keep on snipping them, so I presume the problem is you don't agree to them, but can't refute them.
Maybe I need to keep quoting them so you can see
The implications of your specifications are:
1) That your H is NOT a computation equivalent for a Turing machine.
2) That you simulations do NOT say anything about the actual behavior of the machine given on the input, especially about its halting status.
3) That you "infinite set of H/D pairs" does NOT correspond to the concept of the behavior of a machine, and
4) That you D and H are NOT eqivalents of the corresponding things in the Linz or Sipser proofs.
5) You are not interested in Honest Dialog, but are hoping someone will agree to baddly defined terms so you can claim support for your lies.
If you want to disagree, try to present some source for your claims.