On 5/24/22 10:34 PM, 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.
>

Your problem is a "Higher Caliber" review is going to point out the same
mistakes.

You need to find a "Lower Caliber" (ie more guilible) reviewer that is
able to be snowed by your faulty logic. But that won't help you get
published, not in any Journal with a reputation, as they don't use that
sort of reviewer.