On 5/25/22 8:25 PM, olcott wrote:
> On 5/25/2022 7:19 PM, Richard Damon wrote:
>> On 5/25/22 10:13 AM, 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.
>>
>> And since the input is the SAME to both of these, the correct
>> emulation of that input must be the same, at least if H is a computation.
> So you disagree with the x86 langugae?
>

Nope, but the x86 language doesn't say what you claim.

x86 says that P isn't fully defined as it uses a memory location with no
code defined for it.

Just shows that YOU don't really understand the x86 language.