Re: Proof that H(D,D) meets its abort criteria --self-evident truth--

On 3/17/2024 11:00 AM, Richard Damon wrote:

On 3/17/24 6:11 AM, olcott wrote:

On 3/17/2024 12:22 AM, Richard Damon wrote:

On 3/16/24 10:04 PM, olcott wrote:

On 3/17/2024 12:00 AM, Richard Damon wrote:

On 3/16/24 9:42 PM, olcott wrote:

On 3/16/2024 11:28 PM, Richard Damon wrote:

On 3/16/24 9:13 PM, olcott wrote:

On 3/16/2024 10:57 PM, Richard Damon wrote:

On 3/16/24 7:52 PM, olcott wrote:

On 3/16/2024 9:43 PM, Richard Damon wrote:

On 3/16/24 5:50 PM, olcott wrote:

On 3/16/2024 7:21 PM, Richard Damon wrote:

On 3/16/24 8:29 AM, olcott wrote:

On 3/15/2024 11:29 PM, Richard Damon wrote:

On 3/15/24 8:45 PM, olcott wrote:

H(D,D) fails to make the required mistake of reporting on what it does not see.

>
But it DOES make a mistake, because it does answer the question correctly.
>
You are just PROVING you think lying is ok.
>
You TOTALLY don't understand the meaning of truth.
>
You are REALLY just a Pathological Liar, as you have no concept of real truth,
>

>
The original halt status criteria has the impossible requirement
that H(D,D) must report on behavior that it does not actually see.
Requiring H to be clairvoyant is an unreasonable requirement.
*The criteria shown below eliminate the requirement of clairvoyance*
>
(a) If simulating halt decider H correctly simulates its input D until
H correctly determines that its simulated D would never stop running
unless aborted then
>
*H correctly simulates its input D until*
Means H does a correct partial simulation of D until H correctly
matches the recursive simulation non-halting behavior pattern.
>
>

>
But turning out to be impposible, doesn't make it incorrect or invalid.

>
*You seems to be ridiculously disingenuous about the self-evident truth*
For every possible way that H can be encoded and D(D) calls H(D,D) either H(D,D) aborts its simulation or D(D) never stops running.
>
>

>
And you are incredably stupid to not see this doesn't prove what you need it to.
>
Yes, if you define H to not abort, the we get a non-haltig D(D), but H doesn't answwer.
>
But, if you define H to abort, then,

>
We see that you changed the subject away from:
[Proof that H(D,D) meets its abort criteria]
>

>
Nope.

>
H is an algorithm that simulates its input and correctly
determines whether or not it needs to abort this simulation.
That is all that this thread's H does.
>
>
>

And what defines "Need"?
>

It is the set of every implementation of its spec:
(a) H(D,D) Simulate input.
(b) Determine if it needs to stop simulating its input to prevent
the simulated D(D) from never halting.
>

>
And thus not a specific algorithm?
>
Again, HOW do you determine NEED?
>
That is not an algorithmic step.
>
We can only verify that in retrospect.

>
Do you fully understand the spec?
>
>

>
Yes, but I think not the way you do.
>
To me, for H to NEED to abort its simulation, that means that when giving the input to a correct simulator, that simulator will not halt.
>

Yes that is correct.

 And THIS input (that used the H that aborts), when given to a correct simulator, will reach an end.
 Since you just agreed to my definition, you agree that this H didn't need to abort.
 

>

I say this isn't the way you do, as I have shown that H fails to meet this specification.
>

(a) If abort halt decider H correctly simulates its input D until H correctly determines that its simulated D would never stop running unless aborted then
>
This is the way that I do it and you have never shown otherwise.

 Nope, you use an H that aborts because it non-aborting brother needed to abort the brother of your input
 

>

You can't seem to actually define it the way you want, likely because you don't actually understand what you are doing.
>

It seems to me that the issue is your persistence in remaining in
rebuttal mode even when this contradicts the verified facts.

 No, you are stuck it trying to call two things that are different as if they were the same.
 

>

This seems clear as your "implementation" isn't actually an implementation as it includes non-algorithmic steps.
>

My C code provably does do this and I can show a TM equivalent.

 Nope.
 DO IT if you can.
 

>

There is no "Get the right answer" instruction, or look into the future (or even look into an alternate future) instruction.

>
  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[00001d22][00102fc9][00000000] 55         push ebp
[00001d23][00102fc9][00000000] 8bec       mov ebp,esp
[00001d25][00102fc5][00001b32] 68321b0000 push 00001b32 ; push Sipser_D
[00001d2a][00102fc1][00001b32] 68321b0000 push 00001b32 ; push Sipser_D
[00001d2f][00102fbd][00001d34] e8eef8ffff call 00001622 ; call Sipser_H
>
Sipser_H: Begin Simulation   Execution Trace Stored at:113075
Address_of_Sipser_H:1622
[00001b32][00113061][00113065] 55         push ebp
[00001b33][00113061][00113065] 8bec       mov ebp,esp
[00001b35][00113061][00113065] 8b4508     mov eax,[ebp+08]
[00001b38][0011305d][00001b32] 50         push eax      ; push Sipser_D
[00001b39][0011305d][00001b32] 8b4d08     mov ecx,[ebp+08]
[00001b3c][00113059][00001b32] 51         push ecx      ; push Sipser_D
[00001b3d][00113055][00001b42] e8e0faffff call 00001622 ; call Sipser_H
Sipser_H: Recursive Simulation Detected Simulation Stopped

 And that is becase your Sipser_H deterined that Sipser_H won't halt unless aborted, not Sipser_D.
 Sipser_D will ALWAYS halt if Sipser_H returns a value, as it is required.
 

>
[00001d34][00102fc9][00000000] 83c408     add esp,+08
[00001d37][00102fc5][00000000] 50         push eax
[00001d38][00102fc1][00000743] 6843070000 push 00000743
[00001d3d][00102fc1][00000743] e820eaffff call 00000762
Input_Halts = 0
[00001d42][00102fc9][00000000] 83c408     add esp,+08
[00001d45][00102fc9][00000000] 33c0       xor eax,eax
[00001d47][00102fcd][00000018] 5d         pop ebp
[00001d48][00102fd1][00000000] c3         ret
Number of Instructions Executed(868) == 13 Pages
>
We can see that Sipser_D(Sipser_D) cannot stop running unless
Sipser_H(Sipser_D, Sipser_D) aborts its simulation.
>

 No, it shows that a Sipser_H that doesn't figure out when to abort its simulations will fail to meet its requirements.
 Since your Sipser_H DOES abort (as your trace shows the outer one does) it needs to figure out what Sipser_D will do with its answers, but it can't just use "brute-force" simulation.
 

It is an empirically verified fact that either
Sipser_H(Sipser_D, Sipser_D) aborts its simulation or neither
Sipser_H(Sipser_D, Sipser_D) nor Sipser_D(Sipser_D) ever stops
running (not counting stack overflow).
Your pathological thinking incorrectly denies this
empirically verified fact.

The problem with your logic is you don't look at the input you actually have, and thus are just lying to yourself.
 Because you don't follow the definition you just agreed to above!
 So, you are just admitting to being a liar.

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer