On 5/25/2022 6:04 AM, Richard Damon wrote:
>
> 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.

The only thing that the system is required to do is to correctly
simulate enough steps of its input that it (a) correctly determines that
this input would never reach its "ret" instruction (b) that the input
has reached its "ret" instruction.

That you imagine other properties that the system should have is merely
your own confusion.

>
> 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.

--
Copyright 2022 Pete Olcott

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