On 9/27/2022 9:46 PM, Richard Damon wrote:
>
> On 9/27/22 10:30 PM, olcott wrote:
>> On 9/27/2022 9:24 PM, Richard Damon wrote:
>>> On 9/27/22 10:02 PM, olcott wrote:
>>>> On 9/27/2022 8:50 PM, Richard Damon wrote:
>>>>> On 9/27/22 9:33 PM, olcott wrote:
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>> What about the Linz definition of a Halt Decider, the one YOU quote.
>>>>
>>>> He does not say that the correct simulation of an input does not
>>>> provide the actual behavior of this input. You will find no
>>>> competent person that will disagree with me on this point.
>>>>
>>>>
>>>
>>> But he DOES say that the DEFINITION of the right answer is the
>>> behavior of the machine that input describes, so THAT is the behavior
>>> that counts.
>>>
>> People that know these things more deeply than learned-by-rote will
>> understand that my alternative definition is sound.
>
> No, it is WRONG, since it doesn't match.
>
> That is like saying Two is the right answer to the question of How many
> cats you have, when you have one cats and one dog, because dogs are
> really pretty much like a cat.
>
> FAIL.
>
>>
>> We can know that it is sound by simply knowing that the correct
>> simulation of the input does provide the actual behavior of this
>> input. We know this on the basis of the definition of a UTM.
>>
>>
>
> The CORRECT AND COMPLETE.
>
> Not being complete, it CAN'T show the actual behavior.
>
> That is like getting off the highway at the second exit, well before you
> get into the city, and announce that traffic is clear into the city,
> because you didn't see any traffic.
>
> You are just PROVING our stupidity.

Mike already corrected you on this.
The correct simulation of 1 to ∞ steps of the input *is* computationally
equivalent to the direct execution of 1 to ∞ steps of the input.

How can you disagree with this besides lying?

--
Copyright 2022 Pete Olcott

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