On 5/24/22 11:04 PM, olcott wrote:
> On 5/24/2022 9:57 PM, Dennis Bush wrote:
>> On Tuesday, May 24, 2022 at 10:50:51 PM UTC-4, 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)
>>
>> There absolutely is because I stipulated them to be so.
>
> Then run Hb(Pa,Pa) and show me the excution trace of its input.
> You make things deliberately vague to hide your deception.
>
> I can prove that the behavior of the input to H(P,P) and H1(P,P) is not
> the same and this can be proved to be correct on the basis of the
> behavior that the x86 source-code of P specifies.
>

Then you prove your system inconsistent, and the inputs are the
representation of the same computation, and thus must always be the same
thing.

Of course, if H and H1 aren't Halt Deciders, then their inputs might not
be representations of computation.

> All that you can do is say that you really really imagine that they must
> be the same.
>
>

Because they are DEFINED that way. You are just showing your IGNORANCE
of what the problem statement is and the basic laws of computations.