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

Right, but P includes its COPY of H. YOU failed to maintain the line of
demarcation by having P call the same H that is deciding it, in
violation of the requirements. (Read the proof)

Thus, you can't blame the line of demarcation.

Your fundamental problem is you totally don't understand what the
problem is about, because you decided that you needed to remain ignorant
of the field to avoid being "brain-washed" by it.

THat means you just totally fail to understand what you are talking about.

You have wasted the last 18 years of your life becaue of this
self-imposed ignorance and have buried your reputation under the pile of
idiotic lies because you just don't understand the words you are saying.

FAIL.