On 5/25/2022 9:35 AM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote:
>> On 5/25/2022 9:20 AM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
>>>> On 5/25/2022 6:01 AM, Richard Damon wrote:
>>>>> On 5/24/22 11:00 PM, olcott wrote:
>>>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
>>>>>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
>>>>>>>>>>>>>>>>>>>>> a decider or it
>>>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
>>>>>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
>>>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>>>> specifies to
>>>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>>>> You continue to be a liar.
>>>>>>>>>>>
>>>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>>>> admit I'm right.
>>>>>>>>>>>
>>>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>>>> longer working on the halting problem?
>>>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>>>
>>>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>>>> disagreeing
>>>>>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>>>>>> that I
>>>>>>>>>> am correct.
>>>>>>>>>
>>>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>>>
>>>>>>>> Shows that they are not basing their decision on the execution trace
>>>>>>>> that is actually specified by the x86 source-code of P.
>>>>>>>>
>>>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
>>>>>>>> and H1(P,P). You can't even manage to tell the truth about the names
>>>>>>>> of functions.
>>>>>>>>
>>>>>>>
>>>>>>> The names really make that much difference?
>>>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>>>>> executed showing every detail of their correct simulation of their
>>>>>> inputs.
>>>>>>
>>>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
>>>>>> down to specifics. The only place that Dennis can hide his deception
>>>>>> is in deliberate vagnueness.
>>>>>>
>>>>>
>>>>> So, you don't understand what peeople are saying. For you it is just
>>>>> that you are right and others are wrong.
>>>> Ha(Pa,Pa) is fully operational code named H(P,P)
>>>> Hb(Pa,Pa) is fully operational code named H1(P,P)
>>>>
>>>> I can prove that the actual behavior of the correct x86 emulation of
>>>> actual input to H(P,P) never reaches its "ret" instruction with a full
>>>> execution trace of P.
>>>>
>>>> I can prove that the actual behavior of the correct x86 emulation of
>>>> actual input to H1(P,P) reaches its "ret" instruction with a full
>>>> execution trace of P.
>>>>
>>>> I can prove that both of these execution traces are correct on the basis
>>>> of the behavior that is specified by the x86 source-code for P.
>>>
>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>
>> If H(P,P) is proven to be correct then there is no need to look at
>> anything else. I am not writing a paper about every program that can
>> possibly ever be written. I am wring a paper about H(P,P). Once
>> H(P,P)==0 is proven to be correct then all of the HP proof are refuted.
>
> If your proof of H(P,P)==0 being correct also concludes that Ha3(N,5)==0 is correct, then you have an invalid proof as it creates nonsense results.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is an easily verified fact that the correct x86 emulation of the
input to H(P,P) would never reach the "ret" instruction of P in 0 to
infinity steps of the correct x86 emulation of P by H.

This can be verified entirely on the basis of the x86 source-code for P
by anyone that is sufficiently technically competent.

Even people that are not very bright can tell That H must emulate the
first 7 instructions of P.

Because we know that H(P,P) emulates the first 7 instructions of P we
know that when P calls H(P,P) that H emulates the first 7 instructions
of P.

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

H emulates the first 7 instructions of P
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

The emulated H emulates the first 7 instructions of P
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H

It is clear that the emulated P would never reach its "ret" instruction
and the emulation would never stop unless aborted.

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

--
Copyright 2022 Pete Olcott

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