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.

--
Copyright 2022 Pete Olcott

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