On 5/3/22 6:32 PM, olcott wrote:
> On 5/3/2022 5:21 PM, Dennis Bush wrote:
>> On Tuesday, May 3, 2022 at 6:08:33 PM UTC-4, olcott wrote:
>>> On 5/3/2022 4:49 PM, Dennis Bush wrote:
>>>> On Tuesday, May 3, 2022 at 12:39:49 PM UTC-4, olcott wrote:
>>>>> On 5/3/2022 10:36 AM, Dennis Bush wrote:
>>>>>> On Tuesday, May 3, 2022 at 11:19:33 AM UTC-4, olcott wrote:
>>>>>>> On 5/3/2022 9:47 AM, Dennis Bush wrote:
>>>>>>>> On Tuesday, May 3, 2022 at 10:31:21 AM UTC-4, olcott wrote:
>>>>>>>>> On 5/3/2022 7:12 AM, wij wij wrote:
>>>>>>>>>> Richard Damon 在 2022年5月3日 星期二上午8:48:57 [UTC+8] 的信中
>>>>>>>>>> 寫道：
>>>>>>>>>>> On 5/2/22 8:35 PM, olcott wrote:
>>>>>>>>>>>> On 5/2/2022 5:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Mon, 2 May 2022 18:46:00 -0400
>>>>>>>>>>>>> Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 5/2/22 6:38 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Mon, 2 May 2022 18:32:16 -0400
>>>>>>>>>>>>>>> Richard Damon wrote:
>>>>>>>>>>>>>>>> On 5/2/22 11:47 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> Not all infinitely recursive definitions are invalid
>>>>>>>>>>>>>>>>> however
>>>>>>>>>>>>>>>>> infinitely recursive definitions that arise out of a
>>>>>>>>>>>>>>>>> category
>>>>>>>>>>>>>>>>> error (as is the case with the halting problem) are
>>>>>>>>>>>>>>>>> invalid.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The halting problem (as currently defined) is invalid
>>>>>>>>>>>>>>>>> due to the
>>>>>>>>>>>>>>>>> invalid "impossible program" [Strachey, 1965] that is
>>>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>>> impossible due to the category error present in its
>>>>>>>>>>>>>>>>> definition and
>>>>>>>>>>>>>>>>> *not* because of any function call-like recursion;
>>>>>>>>>>>>>>>>> confusion
>>>>>>>>>>>>>>>>> between these two types of recursion are why Olcott is
>>>>>>>>>>>>>>>>> having
>>>>>>>>>>>>>>>>> difficulty communicating his ideas with the rest of you
>>>>>>>>>>>>>>>>> shower.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The categories involved in the category error are the
>>>>>>>>>>>>>>>>> decider and
>>>>>>>>>>>>>>>>> that which is being decided. Currently extant attempts to
>>>>>>>>>>>>>>>>> conflate the decider with that which is being decided are
>>>>>>>>>>>>>>>>> infinitely recursive and thus invalid.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that the "impossible program" isn't part of the
>>>>>>>>>>>>>>>> definition
>>>>>>>>>>>>>>>> of the Halting Problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is according to [Wikipedia, 2022].
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, you comprehend worse that PO.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note, and Encyclopedic entery, like Wikipedia, is NOT just a
>>>>>>>>>>>>>> definition but a full article explaining the subject.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe if you look for a FORMAL source, that states what is
>>>>>>>>>>>>>> the ACTUAL
>>>>>>>>>>>>>> definition, you would learn something.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If Wikipedia is wrong then correct it and have your
>>>>>>>>>>>>> corrections
>>>>>>>>>>>>> reviewed; until then please shut the fuck up.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think that the problem is that Richard has disagreeably as
>>>>>>>>>>>> his highest
>>>>>>>>>>>> priority, thus doesn't really give a rat's ass for the
>>>>>>>>>>>> truth. An
>>>>>>>>>>>>
>>>>>>>>>>>> An impossible program C. Strachey
>>>>>>>>>>>> The Computer Journal, Volume 7, Issue 4, January 1965, Page
>>>>>>>>>>>> 313,
>>>>>>>>>>>> Published: 01 January 1965
>>>>>>>>>>>> https://academic.oup.com/comjnl/article/7/4/313/354243
>>>>>>>>>>>>
>>>>>>>>>>>> It is very common knowledge that the Wikipedia description
>>>>>>>>>>>> is true and
>>>>>>>>>>>> this is affirmed in Sipser.
>>>>>>>>>>>>
>>>>>>>>>>>> For any program f that might determine if programs halt, a
>>>>>>>>>>>> "pathological" program g, called with some input, can pass
>>>>>>>>>>>> its own
>>>>>>>>>>>> source and its input to f and then specifically do the
>>>>>>>>>>>> opposite of what
>>>>>>>>>>>> f predicts g will do.
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>
>>>>>>>>>>>> Now we construct a new Turing machine D with H as a
>>>>>>>>>>>> subroutine. This new
>>>>>>>>>>>> TM calls H to determine what M does when the input to M is
>>>>>>>>>>>> its own
>>>>>>>>>>>> description ⟨M⟩. Once D has determined this information, it
>>>>>>>>>>>> does the
>>>>>>>>>>>> opposite. https://www.liarparadox.org/Sipser_165_167.pdf
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Thus you have shown you don't even know what a "Definition"
>>>>>>>>>>> is, so it is
>>>>>>>>>>> impossible for you to reason by the meaning of the words.
>>>>>>>>>>>
>>>>>>>>>>> You have just proved yourself to be an IDIOT.
>>>>>>>>>>
>>>>>>>>>> PO is incapable of logic reasoning (PO had shown he cannot
>>>>>>>>>> even get the truth
>>>>>>>>>> table of logical implication/AND right). All he said is
>>>>>>>>>> delusion including when
>>>>>>>>>> words from him happen to be correct to others (no real meaning).
>>>>>>>>>>
>>>>>>>>>> IIRC, PO's revision that H(P,P) has no relation with P(P) is
>>>>>>>>>> deliberately
>>>>>>>>>> fabricated this recent year after PO ran out his reasons to
>>>>>>>>>> explain why HP is
>>>>>>>>>> wrong and he is correct. PO has no trouble to 'lie' to his
>>>>>>>>>> bible (he can read
>>>>>>>>>> it his way), the HP thing is just piece of cake.
>>>>>>>>> It is an easily verified fact that P(P) and the correct
>>>>>>>>> simulation of
>>>>>>>>> the input to H(P,P) specify different sequences of
>>>>>>>>> configurations, thus
>>>>>>>>> have different halting behavior.
>>>>>>>>
>>>>>>>> The easily verified fact is that the correct simulation to
>>>>>>>> H(P,P) is performed by Hb(P,P) (which simulates for k more steps
>>>>>>>> than H) which remains in UTM mode while simulating the same
>>>>>>>> input to a final state.
>>>>>>>>
>>>>>>> I have no idea what you mean.
>>>>>>
>>>>>> In other words you don't want to admit that this proves you are
>>>>>> wrong.
>>>>>>
>>>>> No I can't understand what you mean.
>>>>> I think that I see it now, I had forgotten the notation.
>>>>>
>>>>> An input having a pathological self-reference relationship to its
>>>>> decider H would necessarily derive a different halt status than an
>>>>> input
>>>>> not having a pathological self-reference relationship to its
>>>>> decider Hb.
>>>>>
>>>>> The P having a pathological self-reference relationship to H is not
>>>>> the
>>>>> same as the Px NOT having a pathological self-reference
>>>>> relationship to
>>>>> Hb. Because P.H calls itself and Px.Hb does not call itself P is
>>>>> not the
>>>>> same input as Px.
>>>>
>>>> The P we're talking about is a *specific* P, namely Pa which is
>>>> built from Ha, and Ha is a *specific* H. So Pa and Px are the *same*.
>>> Not at all because H(P,P) has itself as part of its input and Hb(P,P)
>>> does not have itself as part of its input.
>>>>
>>>> So just because Pa contains an embedded copy of Ha but not an
>>>> embedded copy of Hb doesn't means that it's not the same.
>>>>
>>> Sure it does. The correctly simulated input to H(P,P) specifies
>>> infinitely nested simulation where as correctly simulated input to
>>> Hb(P,P) DOES NOT specify infinitely nested simulation.
>>>
>>> How much longer are you going to continue the verified facts?
>>> This does make you look quite foolish or dishonest.
>>>> Ha(Pa,Pa) and Hb(Pa,Pa) have the *exact* same input.
>>>>
>>> The correctly simulated input to Ha(Pa,Pa) specifies infinitely nested
>>> simulation where as correctly simulated input to Hb(Pa,Pa) DOES NOT
>>> specify infinitely nested simulation.
>>>
>>> How much longer are you going to continue the verified facts?
>>> This does make you look quite foolish or dishonest.
>>>> Just because it appears from a glance that Ha is starting its
>>>> simulation of Pa "in the middle" doesn't mean that's what's actually
>>>> happening. That's just how the incorrect simulation is manifesting
>>>> itself. It's kind of like undefined behavior in a C program.
>>> You only have to do a correct execution trace of Ha(Pa,Pa) and Hb(Pa,Pa)
>>> to see that:
>>>
>>> The correctly simulated input to Ha(Pa,Pa) specifies infinitely nested
>>> simulation where as correctly simulated input to Hb(Pa,Pa) DOES NOT
>>> specify infinitely nested simulation.
>>>
>>> How much longer are you going to continue the verified facts?
>>> This does make you look quite foolish or dishonest.
>>>>>>
>>>>>>>> Because H and Hb and both simulating halt deciders and are given
>>>>>>>> the same input, they are deciding on the same sequence of
>>>>>>>> configurations (namely starting with the first instruction of
>>>>>>>> P). Because one answers false and one answers true, one must be
>>>>>>>> wrong.
>>>>>>>>
>>>>>>> It is ridiculously stupid to assume that an input having
>>>>>>> pathological
>>>>>>> self-reference to its decider would have the same behavior as an
>>>>>>> input
>>>>>>> NOT having pathological to its decider.
>>>>>>
>>>>>> Which is another way of saying that H can't give a correct answer
>>>>>> for (P,P).
>>>>>>
>>>>> Different computations must give different answers.
>>>>> That you don't fully understand all of the nuances of how this applies
>>>>> to H/P and Hb/Px is OK, it is difficult to understand.
>>>>
>>>> Just because Pa contains an embedded copy of Ha but not an embedded
>>>> copy of Hb doesn't means that it's not the same.
>>> You only have to do a correct execution trace of Ha(Pa,Pa) and Hb(Pa,Pa)
>>> to see that:
>>>
>>> The correctly simulated input to Ha(Pa,Pa) specifies infinitely nested
>>> simulation where as correctly simulated input to Hb(Pa,Pa) DOES NOT
>>> specify infinitely nested simulation.
>>>
>>> How much longer are you going to continue the verified facts?
>>> This does make you look quite foolish or dishonest.
>>>>>>>> Since a simulating halt decider that simulates its input to a
>>>>>>>> final state while remaining in UTM mode is necessarily correct,
>>>>>>>> this proves that Hb(P,P) == true is correct and that H(P,P) ==
>>>>>>>> false is incorrect, and that H(P,P) does *not* in fact perform a
>>>>>>>> correct simulation of its input because it aborts too soon.
>>>>>>>>
>>>>>>> It is very easy to verify the fact that the simulated input to
>>>>>>> H(P,P)
>>>>>>> would never stop unless aborted. It is pretty psychotic that many
>>>>>>> of my
>>>>>>> reviewers deny easily verified facts.
>>>>>>
>>>>>> There is no "unless". The fixed algorithm of H, which will
>>>>>> henceforth be referred to as Ha and similarly P will be referred
>>>>>> to as Pa, *does* abort.
>>>>> Which is *NOT* halting. A halting input must reach its own final
>>>>> state.
>>>>>> Because of this, Hb(Pa,Pa) explicitly shows that the simulated
>>>>>> input to Ha(Pa,Pa) *does* stop. The fact that Pn(Pn) does not halt
>>>>>> and that Hn(Pn,Pn) does not halt is irrelevant.
>>>>> It it not Hb(Pa,Pa) it is Hb(Px,Px). That P calls H makes it an
>>>>> entirely
>>>>> different input than Px that does not call Hb.
>>>>
>>>> No it is *exactly* Hb(Pa,Pa). The same encoding passed to Ha is
>>>> passed to Hb.
>>> You only have to do a correct execution trace of Ha(Pa,Pa) and Hb(Pa,Pa)
>>> to see that:
>>>
>>> The correctly simulated input to Ha(Pa,Pa) specifies infinitely nested
>>> simulation where as correctly simulated input to Hb(Pa,Pa) DOES NOT
>>> specify infinitely nested simulation.
>>
>> Hb(Pa,Pa) proves that Ha(Pa,Pa) does NOT perform a correct simulation.
> By looking at the actual execution trace of the simulation of Hb(Pa,Pa)
> and Ha(Pa,Pa) it is easy to determine that the simulations are correct
> on the basis of the x86 source code of Pa.

Nope. You are looking at a WRONG simulation.

Note, your "second" layer is incorrect as we really need to see the
simulation of Ha simulating Pa,Pa, not another execution of Pa

Note, there is a valid transform of UNCONDITIONAL simulation to
execution, but Pa does NOT unconditionally simulate its input, so that
transform is not valid.

And the concept of being "unconditional until", is just an oxymoron, and
your arguments about that just prove you are a regular one.

>
> I will see if I can create the execution of Hb(Pa,Pa) to derive this
> execution trace. We have had the one for Ha(Pa,Pa) for many months now.

No, you have an INCORRECT one that uses a false transform.

We need to see the trace of Ha actually simulating, not that part skipped.

>
> It is self evident that Hb will not see itself being called in
> infinitely nested simulation and the executuion trace of Ha(Pa,Pa) does
> see itself called in infinitely nested simulation. This difference would
> very obviously make the results of Ha and Hb differ.
>

Which just helps prove that Ha was WRONG.