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.

On 9/26/2022 9:12 PM, Richard Damon wrote:
> On 9/26/22 9:55 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.
>>>
>>
>> The concept of a UTM defines that the correct simulation of a machine
>> description provides the actual behavior of this machine description
>> thus the correct x86 emulation of the machine language of a C function
>> also provides the actual behavior of this function.
>>
>
> Not  C *Function*, but C *PROGRAM*. Functions that call something
> outside themselves are NOT "Computation" by themselves, but only when
> you INCLUDE what they call.
>

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

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)

On 9/26/22 10:36 PM, olcott wrote:
> On 9/26/2022 9:12 PM, Richard Damon wrote:
>> On 9/26/22 9:55 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.
>>>>
>>>
>>> The concept of a UTM defines that the correct simulation of a machine
>>> description provides the actual behavior of this machine description
>>> thus the correct x86 emulation of the machine language of a C
>>> function also provides the actual behavior of this function.
>>>
>>
>> Not  C *Function*, but C *PROGRAM*. Functions that call something
>> outside themselves are NOT "Computation" by themselves, but only when
>> you INCLUDE what they call.
>>
>
> None-the-less we still must maintain the line-of-demarcation between
> what is being tested: P, and what is doing the testing: H.
>
>

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

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.

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.

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

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

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*

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

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

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.

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

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.

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

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.

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.

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.

On 9/27/22 11:04 PM, olcott wrote:
> 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?
>
>

On 9/28/2022 6:28 AM, Richard Damon wrote:
> On 9/27/22 11:04 PM, olcott wrote:
>> 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?
>>
>>
>
> So, what SINGLED EXACT INPUT have you done this for?
>
> Remember, exact of your members of Px are DIFFERENT!
>
> You only "correctly simulate" a given input once, for a single number
> between 1 and infinity, so you never have a valuation of 1 to infinite
> steps for any input except those that are basd on an Hx that never stops
> them, and thos Hx never abort.
>