On 9/27/2022 8:15 PM, Richard Damon wrote:
> On 9/27/22 9:00 PM, olcott wrote:
>> On 9/27/2022 6:02 PM, Richard Damon wrote:
>>>
>>> On 9/27/22 11:19 AM, olcott wrote:
>>>> On 9/27/2022 6:00 AM, Richard Damon wrote:
>>>>> On 9/26/22 11:49 PM, olcott wrote:
>>>>>> On 9/26/2022 10:29 PM, Richard Damon wrote:
>>>>>>> On 9/26/22 11:04 PM, olcott wrote:
>>>>>>>> On 9/26/2022 9:58 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/26/22 10:41 PM, olcott wrote:
>>>>>>>>>> On 9/26/2022 9:23 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/26/22 10:18 PM, olcott wrote:
>>>>>>>>>>>> On 9/26/2022 8:49 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/26/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/26/2022 8:15 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/26/22 8:58 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/26/2022 7:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/26/22 8:25 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/26/2022 6:59 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/26/22 7:46 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/26/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/26/22 2:03 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 12:48 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:42:02 -0500
>>>>>>>>>>>>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 12:19 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, 26 Sep 2022 12:15:15 -0500
>>>>>>>>>>>>>>>>>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/26/2022 11:05 AM, Kaz Kylheku wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2022-09-26, Lew Pitcher
>>>>>>>>>>>>>>>>>>>>>>>>>>> <lew.pitcher@digitalfreehold.ca>
>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry, guy, but comp.lang.c is not the place
>>>>>>>>>>>>>>>>>>>>>>>>>>>> to discuss this
>>>>>>>>>>>>>>>>>>>>>>>>>>>> sort of thing. Why don't you try comp.theory ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Because Olcott postings will push you out of
>>>>>>>>>>>>>>>>>>>>>>>>>>> visibility?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If people would give me a fair and honest
>>>>>>>>>>>>>>>>>>>>>>>>>> review I could quit
>>>>>>>>>>>>>>>>>>>>>>>>>> posting. You gave up on me before I could
>>>>>>>>>>>>>>>>>>>>>>>>>> point out the error with
>>>>>>>>>>>>>>>>>>>>>>>>>> the diagonalization argument that you relied
>>>>>>>>>>>>>>>>>>>>>>>>>> on for your rebuttal:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The diagonalization argument merely proves
>>>>>>>>>>>>>>>>>>>>>>>>>> that no value returned
>>>>>>>>>>>>>>>>>>>>>>>>>> to P from its call to H can possibly be
>>>>>>>>>>>>>>>>>>>>>>>>>> correct. This argument
>>>>>>>>>>>>>>>>>>>>>>>>>> totally ignores that the return value from H
>>>>>>>>>>>>>>>>>>>>>>>>>> is unreachable by its
>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P caller when H is based on a
>>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>> This makes it impossible for P to do the
>>>>>>>>>>>>>>>>>>>>>>>>>> opposite of whatever H
>>>>>>>>>>>>>>>>>>>>>>>>>> decides.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Complete halt deciding system (Visual Studio
>>>>>>>>>>>>>>>>>>>>>>>>>> Project)
>>>>>>>>>>>>>>>>>>>>>>>>>> (a) x86utm operating system
>>>>>>>>>>>>>>>>>>>>>>>>>> (b) complete x86 emulator
>>>>>>>>>>>>>>>>>>>>>>>>>> (c) Several halt deciders and their inputs
>>>>>>>>>>>>>>>>>>>>>>>>>> contained within Halt7.c
>>>>>>>>>>>>>>>>>>>>>>>>>> https://liarparadox.org/2022_09_07.zip
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You keep making the same mistake again and
>>>>>>>>>>>>>>>>>>>>>>>>> again. H IS NOT SUPPOSED
>>>>>>>>>>>>>>>>>>>>>>>>> TO BE RECURSIVE.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) is not recursive.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Your H is recursive because P isn't recursive and
>>>>>>>>>>>>>>>>>>>>>>> yet you have to abort
>>>>>>>>>>>>>>>>>>>>>>> your infinite recursion: the recursion is caused
>>>>>>>>>>>>>>>>>>>>>>> by your H and not by
>>>>>>>>>>>>>>>>>>>>>>> P.  Nowhere in any halting problem proof does it
>>>>>>>>>>>>>>>>>>>>>>> state that the call to
>>>>>>>>>>>>>>>>>>>>>>> H by P is recursive in nature BECAUSE H IS NOT
>>>>>>>>>>>>>>>>>>>>>>> SUPPOSED TO EXECUTE P, H
>>>>>>>>>>>>>>>>>>>>>>> IS SUPPOSED TO *ANALYSE* P.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nowhere in any HP proof (besides mine) is the idea
>>>>>>>>>>>>>>>>>>>>>> of a simulating halt decider (SHD) ever thought
>>>>>>>>>>>>>>>>>>>>>> all the way through.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Because the proof doesn't care at all how the
>>>>>>>>>>>>>>>>>>>>> decider got the answer,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Because the definition of a UTM specifies that the
>>>>>>>>>>>>>>>>>>>>>> correct simulation of a machine description
>>>>>>>>>>>>>>>>>>>>>> provides the actual behavior of the underlying
>>>>>>>>>>>>>>>>>>>>>> machine whenever any simulating halt decider must
>>>>>>>>>>>>>>>>>>>>>> abort its simulation to prevent infinite
>>>>>>>>>>>>>>>>>>>>>> simulation it is necessarily correct to report
>>>>>>>>>>>>>>>>>>>>>> that this input does not halt.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Right, which means it CAN'T be a UTM, and thus
>>>>>>>>>>>>>>>>>>>>> *ITS* simulation does not define the "behavior of
>>>>>>>>>>>>>>>>>>>>> the input".
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The behavior of the correct simulation of the input
>>>>>>>>>>>>>>>>>>>> is its actual behavior. That H correctly predicts
>>>>>>>>>>>>>>>>>>>> that its correct simulation never stops running
>>>>>>>>>>>>>>>>>>>> unless aborted conclusively proves that this
>>>>>>>>>>>>>>>>>>>> correctly simulated input would never reach its own
>>>>>>>>>>>>>>>>>>>> final state in 1 to ∞ steps of correct simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But the behavior the halting problem is asking for is
>>>>>>>>>>>>>>>>>>> the behavior of the actual machine.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Only within the context that no one ever bothered to
>>>>>>>>>>>>>>>>>> think the application of a simulating halt decider all
>>>>>>>>>>>>>>>>>> the way through.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, the DEFINITION of a Halt Decider is to decide on
>>>>>>>>>>>>>>>>> the behavior of the Actual Machine.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That definition is made obsolete by a simulating halt
>>>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, the definition IS the definition.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You don't get to change it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I created a new concept that makes earlier ideas about
>>>>>>>>>>>>>> this obsolete:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because the definition of a UTM specifies that the correct
>>>>>>>>>>>>>> simulation of a machine description provides the actual
>>>>>>>>>>>>>> behavior of the underlying machine whenever any simulating
>>>>>>>>>>>>>> halt decider must abort its simulation to prevent infinite
>>>>>>>>>>>>>> simulation it is necessarily correct to report that this
>>>>>>>>>>>>>> input does not halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because the above is verified as correct on the basis of
>>>>>>>>>>>>>> the meaning of its words it is irrefutable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, but H isn't a UTM, so its simulation doesn't matter.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Unless you can specify that material difference between the
>>>>>>>>>>>> two, that would seem to prove that you are technically
>>>>>>>>>>>> incompetent.
>>>>>>>>>>>
>>>>>>>>>>> H doesn't correctly repoduce the behavior of a non-halting
>>>>>>>>>>> input.
>>>>>>>>>>>
>>>>>>>>>>> Thus, it isn't a UTM.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩      // subscripts indicate unique
>>>>>>>>>> finite strings
>>>>>>>>>> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>>>
>>>>>>>>>> Then these steps would keep repeating: (unless their
>>>>>>>>>> simulation is aborted)
>>>>>>>>>
>>>>>>>>> Note, you say "unless their simulation is aborted" but your
>>>>>>>>> defiition of H DOES abort its simulation, thus this doesn't occur.
>>>>>>>>>
>>>>>>>>> FAIL.
>>>>>>>>>
>>>>>>>>>> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>>>
>>>>>>>>>> This exact same behavior occurs when we replace H with a UTM.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But since H ISN'T a UTM, you can't assume that it is.
>>>>>>>>>
>>>>>>>>
>>>>>>>> H is designed to predict the result of 1 to ∞ correctly
>>>>>>>> simulated steps, thus predict the behavior of a UTM simulation.
>>>>>>>>
>>>>>>> Except it doesn't do that.
>>>>>>>
>>>>>> H does correctly predict the actual behavior of 1 to ∞ simulated
>>>>>> steps of P.
>>>>>>
>>>>>
>>>>> Nope, since we have shown that if H(P,P) returns 0, then P(P) will
>>>>> Halt.
>>>>>
>>>>
>>>> *That is false and you know it so you are a liar for the 500th time*
>>>> *You know that you are not referring to the behavior of an input to H*
>>>
>>> No, I am refering to the input to H.
>>>
>>> The input to H(P,P) represents the computation P(P), or your P isn't
>>> the required "impossible Program".
>>>
>>
>> You cannot find a competent source that agrees that the actual
>> behavior of the input is not provided by the correct simulation of
>> this input.
>>
>>
>
> Correct AND COMPLETE simulation of the input.
>
So like I said you have no source, you and most other are only going by
learned-by-rote so when a new issue comes up your flounder. The others
here not going by learned-by-rote are going by total cluelessness.

-
Copyright 2022 Pete Olcott

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