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.

That just makes YOU, the one who is wrong.

It shows that you are just a legend in your own mind.

YOU FAIL.