Re: Olcott was simply wrong --- Try to prove otherwise

On 5/30/24 10:04 AM, olcott wrote:

On 5/30/2024 6:30 AM, Richard Damon wrote:

On 5/29/24 11:58 PM, olcott wrote:

On 5/29/2024 9:55 PM, Richard Damon wrote:

On 5/29/24 10:32 PM, olcott wrote:

On 5/29/2024 9:27 PM, Richard Damon wrote:

On 5/29/24 9:48 PM, olcott wrote:

On 5/29/2024 8:24 PM, Richard Damon wrote:

On 5/29/24 9:15 PM, olcott wrote:

On 5/29/2024 8:07 PM, Richard Damon wrote:

On 5/29/24 8:59 PM, olcott wrote:

On 5/29/2024 7:48 PM, Richard Damon wrote:

On 5/29/24 8:17 PM, olcott wrote:

On 5/29/2024 7:09 PM, Richard Damon wrote:

On 5/29/24 7:57 PM, olcott wrote:

On 5/29/2024 6:47 PM, Richard Damon wrote:

On 5/29/24 2:31 PM, olcott wrote:

On 5/29/2024 1:14 PM, Ben Bacarisse wrote:

Alan Mackenzie <acm@muc.de> writes:
>

How about a bit of respect?  Mike specifically asked you not to cite his
name as a back up for your points.  Why do you keep doing it?

>
He does it to try to rope more people in.  It's the same ploy as
insulting people by name.  It's hard to ignore being maligned in public
by a fool.
>

>
*Thanks for validating my simplified encoding of the Linz*
>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
I really did believe that Ben Bacarisse was lying when I said it.
>
At the time I was talking about the easily verified fact of the actual
execution trace of fully operational code and everyone was denying the
easily verified facts.
>
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       }
>
It turns out that two dozen people are easily proven wrong when
they claimed that the correct simulation of the input to H(D,D)
is the behavior of int main() { D(D); }
>

>
How is that?
>
>

When D is correctly simulated by H using an x86 emulator the only
way that the emulated D can reach its own emulated final state
at line 06 and halt is
(a) The x86 machine code of D is emulated incorrectly
(b) The x86 machine code of D is emulated in the wrong order
>

>
Which isn't a "Correct Simulation" by the definition that allow the relating of a "Simulation" to the behavior of an input.
>

>
Right the execution trace of D simulated by pure function H using
an x86 emulator must show that D cannot possibly reach its own
simulated final state and halt or the simulation of the machine
language of D is incorrect or in the wrong order.

>
So, you aren't going to resolve the question but just keep up with your contradiction that H is simulating a template (that doesn't HAVE any instrucitons of H in it) but also DOES simulate those non-existance instructions by LYING about what it does and simulating a SPECIFIC instance that it LIES behaves just like DIFFERENT specific instatces.

>
I will give you the benefit of the doubt and call that an honest
misunderstanding. I have much more empathy for you now that I found
that Linz really did say words that you could construe as you did.
>
The infinite set of every H/D pair specified by the template
where D is correctly simulated by pure simulator H or pure function
H never has any D reach its own simulated final state and halt.

>
But the question ISN'T about the SIMULATED D, but about the behavior of the actual PROGRAM/MACHINE D
>
This seems to be your blind spot.

>
∃H  ∈ Turing_Machines
∀x  ∈ Turing_Machines_Descriptions
∀y  ∈ Finite_Strings
such that H(x,y) = Halts(x,y)
>
Not really the above formalization does not can cannot
specify Turing Machines as the input to any decider H.
>

>
Then what is x representing?

>
x <is> a finite string Turing machine description that SPECIFIES behavior. The term: "representing" is inaccurate.
>

>
No, it specifies the machine, and thus, though that, the behavior.
>

>
If we assume that a decider takes an actual Turing machine as its
input that is correct otherwise that is one level of indirection
away from what we are really looking at.
>
The people have perpetuated this mistake for many decades never
actually made it not a mistake.
>

>
You need to define what you mean by "Indirection", because you aren't using it in the normal manner.
>

>
I have conclusively proven that the behavior of the correct
simulation of the x86 code of D by pure function H has
different behavior than the direct execution of D(D).

>
But the question isn't about the "Correcgt Simulation" and especially based on YOUR definition. So you haven't proven ANYTHING about the question except that you don't understand it and are just an ignorant pathological liar with a reckless disregard for the trutn.
>
You are just showing that you have successfully brainwashed yourself into beleiving your own lies.
>

>
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       }
>
Like I said *Try and Prove otherwise*
The actual fully operational code DOES INVOKE RECURSIVE SIMULATION.
>
Begin Local Halt Decider Simulation   Execution Trace Stored at:113075
[00001c22][00113061][00113065] 55         push ebp
[00001c23][00113061][00113065] 8bec       mov ebp,esp
[00001c25][0011305d][00103031] 51         push ecx
[00001c26][0011305d][00103031] 8b4508     mov eax,[ebp+08]
[00001c29][00113059][00001c22] 50         push eax       ; push DD
[00001c2a][00113059][00001c22] 8b4d08     mov ecx,[ebp+08]
[00001c2d][00113055][00001c22] 51         push ecx       ; push DD
[00001c2e][00113051][00001c33] e80ff7ffff call 00001342  ; call HH
New slave_stack at:14da95

>
The following doesn't actually happen per your latest definitions.
>

 Sure it does try and prove otherwise.

Since YOUR DEFINITION of a correct simulation says it follows the exact sequence of x86 instructions, GOING INTO H.
So, the call HH must be followd

 

call HH needs be followed by the instructions of HH that are being simulated.
>

 It does I just screen out the 250 pages of them so that we
can see exactly what D is doing. We have no actual need to
see these pages because the fact that D is correctly simulated
by H is proven by the provided execution trace of D.

And thus you LIE and commit logic errors as the two are not equivalent.

 

I guess you are just admitting that you are nothing but a LIAR.
>

 *Please quit calling me a Liar. Others here have called you out on this*
Calling me a liar without even being able to point out any mistake is a
pitiful lack of professional decorum.

I will point out that YOU started it.

 The professional way to handle this is this:
I believe that you are mistaken here is the mistake and
here are the reasons why I believe it is a mistake.

But you don't listen to that.
Tell you want, if you will start actually ANSWERING the errors pointed out, and stop just repeating your FALSE STATEMENTS, I will stop calling you a LIAR, (but will continue to point out statement you make that are clear lies, if they have already been pointed out in the past, so it can't be an "honest mistake"
Note, you need to make a clear and unambigous promise to not repeat statments that have had errors pointed out in them, EVEN IF YOU DON'T SEE THE ERROR, until that is resolved.
No claiming you can't get side-tracked, if your arguement depends on a statement that has been questioned, you can't just leave that behind.
Note, this means you can't say the refutation is just wrong because you must be right, you need to SHOW why you are right, with ACTUAL SOURCES for you claims.

 In some cases just calling someone a liar without even showing
that they are incorrect could result in monetary damages.
This just cost Fox "fake" news $787 million.

Except that every time I have called you a liar, it is after pointing out the lie you have repeated.

 

Maybe you just don't understand what the words you use actuually mean.
>

 What I actually found (and it was very reassuring) is that *you* don't
know what my words mean. It is very reassuring because now I know what
I was mistaking for head games and deception on your part was actually
ordinary misunderstanding.

I don't think YOU know what your words mean. You clearly don't know what the words mean as terms of the art.

 *Don't call me a liar, and don't even say that I am incorrect*
*until after you point out the exact error AND and provide the*
*complete reasoning why you believe it is an error*

I have, many times, and you just ignore it.

 On the very rare occasions where you did this we found that it
was your own misunderstanding all along.
 

Nope.
I will point out that you have admitted to having a mental disorder that gives you incorrect and only partial understanding of the world around you. It is incumberant on YOU to be mindful of this and not just ignore the facts that you don't want to face.