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

That this computation halts when H(P,P) returns 0 has been proven many
times, and your denial of that just shows you can't see truth.

>
>
> Halt deciders only compute the mapping from their inputs to a accept or
> reject state on the basis of the actual behavior of this input.

No, Halt Deciders need to answer about the behavior of the machine their
input represents.

THAT IS DEFINITION.

"Inputs" are strings, and don't have any actual behavior, they only
represent things that do.

Your just proving your stupidity.

>
> The correct simulation of 1 to ∞ steps of a machine description provides
> the actual behavior of of 1 to ∞ steps of the underlying machine.

And only the simulation of the input for as many steps as it takes
represents the actual behavior of the machine that the input represents.

Your set Hx has no member that does that for the EXACT input to H, so it
proves nothing.

>
> int Hx(ptr x, ptr y);
>
> void Px(ptr x)
> {
>   int Halt_Status = Hx(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> There are zero Px elements of infinite set of Hx/Px pairs such that the
> correct simulation (of 1 to ∞ steps) or direct execution of Px by Hx
> reaches the final state of Px and halts.

So, there are zero elements of that set that determine the actual
behavior of rhe input.

There IS a simulation that does, UTM(P,P), which Halts since H(P,P)
return 0.

>
> Some of the Hx elements correctly recognize a correct non-halting
> behavior pattern proving that its Px never halts. These Hx elements
> correctly abort their simulation and correctly return 0 for non-halting.
>
> *This Hx/Px pair is named H/P and is fully operational*

And no other Hx is given this input, so you "proof" fails.

>
> Complete halt deciding system (Visual Studio Project)
> (a) x86utm operating system
> (b) complete x86 emulator adapted from libx86emu
> (c) Several halt deciders and their inputs contained within Halt7.c
> https://liarparadox.org/2022_09_07.zip
>
> The recursive simulation non-halting behavior pattern is slightly
> adapted from infinite recursion behavior pattern used to determine the
> halt status of void Infinite_Recursion(u32 N).
>
> Once the infinite recursion behavior pattern is understood to be correct
> then the recursive simulation behavior pattern is also understood to be
> correct. Both of these behavior patterns use the exact same non-halting
> criteria.
>

All you are proving is that you don't know what you are talking about.

Build a program that does:

void P(ptr x)
{ int status = H(x,x);
while(status) continue;
return;
}

int main() {
Output("H(P,P) = %d", H(P,P));
P(P);
Output("But P(P) Halts");
}

This will PROVE that H returns the wrong answer for the Halting Problem,
since H(P,P) is supposed to be asking if P(P) Halts.

All you have proven is that you are suffering from self-inflicted
ignorance, causing you to pathologically be stating idiotic lies.

You have wasted the last 18 years of your life and killed and buried
your reputation under your pile of falsehoods.

YOU FAIL.