On 5/9/22 7:13 PM, olcott wrote:
> On 5/9/2022 5:56 PM, Dennis Bush wrote:
>> On Monday, May 9, 2022 at 6:24:46 PM UTC-4, olcott wrote:
>>> On 5/9/2022 4:30 PM, Dennis Bush wrote:
>>>> On Monday, May 9, 2022 at 5:20:02 PM UTC-4, olcott wrote:
>>>>> On 5/9/2022 3:59 PM, Dennis Bush wrote:
>>>>>> On Monday, May 9, 2022 at 4:51:57 PM UTC-4, olcott wrote:
>>>>>>> On 5/9/2022 3:27 PM, Dennis Bush wrote:
>>>>>>>> On Monday, May 9, 2022 at 4:18:04 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/9/2022 12:26 PM, Dennis Bush wrote:
>>>>>>>>>> On Monday, May 9, 2022 at 1:18:28 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 5/9/2022 11:52 AM, Dennis Bush wrote:
>>>>>>>>>>>> On Monday, May 9, 2022 at 12:39:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 5/9/2022 11:30 AM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Monday, May 9, 2022 at 12:06:01 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 5/9/2022 11:02 AM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Monday, May 9, 2022 at 11:31:16 AM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/7/2022 9:36 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>> On Saturday, May 7, 2022 at 10:20:27 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> On 5/7/2022 8:26 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Saturday, May 7, 2022 at 9:08:33 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>> On 5/7/2022 7:48 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>> On Saturday, May 7, 2022 at 8:19:40 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 5/7/2022 6:35 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, May 7, 2022 at 7:14:57 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 5/7/2022 5:47 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/6/2022 8:07 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/6/2022 7:11 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The halting theorem follows, trivially,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from lots of simpler theorems,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> none of which have you bothered to read.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In Linz, the theorem is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> presented as a corollary of a simpler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> theorem in chapter 11.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 11.3, 11.4, and 11.5. I will look at them.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Goodness! A good move. Why the change of heart?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> There is enough progress now that I don't
>>>>>>>>>>>>>>>>>>>>>>>>>>> have to have an absolutely
>>>>>>>>>>>>>>>>>>>>>>>>>>> single-minded focus.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Progress?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> THIS IS AN EASILY VERIFIABLE FACT:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Both H() and H1() take the machine code of P
>>>>>>>>>>>>>>>>>>>>>>>>>>> as input parameters and
>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly compute the mapping from this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> to an accept ore reject
>>>>>>>>>>>>>>>>>>>>>>>>>>> state on the basis of the actual behavior
>>>>>>>>>>>>>>>>>>>>>>>>>>> that these inputs actually
>>>>>>>>>>>>>>>>>>>>>>>>>>> specify.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But H does not decide the halting of P(P).
>>>>>>>>>>>>>>>>>>>>>>>>> int sum(int N , int M)
>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>> return (N + M);
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It is not supposed to in the same way that
>>>>>>>>>>>>>>>>>>>>>>>>> sum(3,4) is not supposed to
>>>>>>>>>>>>>>>>>>>>>>>>> provide the sum of (5,7).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Why is this so difficult for you?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You know that if anyone insisted that sum(3,4)
>>>>>>>>>>>>>>>>>>>>>>>>> must return the value of
>>>>>>>>>>>>>>>>>>>>>>>>> sum(5,7) that they are wrong.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Then why do you insist that H(P,P) must return
>>>>>>>>>>>>>>>>>>>>>>>> the value of H(Pn,Pn)?
>>>>>>>>>>>>>>>>>>>>>>> The definition of decider requires it to based
>>>>>>>>>>>>>>>>>>>>>>> its decision on whatever
>>>>>>>>>>>>>>>>>>>>>>> its input specifies.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Which in the case of H(P,P) is *defined* to be P(P)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In this case it is the same as if {dogs} are
>>>>>>>>>>>>>>>>>>>>> defined to be {cats}.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So no rebuttal, just a bad analogy.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Both H(P,P) and H1(P,P) use this exact literal
>>>>>>>>>>>>>>>>>>>>>>> byte string as their
>>>>>>>>>>>>>>>>>>>>>>> input therefore it seems enormously dishonest of
>>>>>>>>>>>>>>>>>>>>>>> you to refer to the
>>>>>>>>>>>>>>>>>>>>>>> same literal string using different subscripts
>>>>>>>>>>>>>>>>>>>>>>> indicating a difference
>>>>>>>>>>>>>>>>>>>>>>> of the same string with itself.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> What I was saying is that you think that H sees
>>>>>>>>>>>>>>>>>>>>>> infinite simulation which only exists in Pn(Pn)
>>>>>>>>>>>>>>>>>>>>> All that crazy bullshit about subscripted names of
>>>>>>>>>>>>>>>>>>>>> subscripts is
>>>>>>>>>>>>>>>>>>>>> extremely deceptive
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, just the opposite. It makes it clear *exactly*
>>>>>>>>>>>>>>>>>>>> which computation we're talking about, so it
>>>>>>>>>>>>>>>>>>>> prevents YOU from being deceptive.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I am ONLY referring to this literal string:
>>>>>>>>>>>>>>>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>>>>>>>>>>>>>>>> as x86 machine code correctly simulated by H(P,P)
>>>>>>>>>>>>>>>>>>>>> and H1(P,P).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No you're not. You're also referring to the literal
>>>>>>>>>>>>>>>>>>>> string which is the fixed code of H which aborts as
>>>>>>>>>>>>>>>>>>>> that is part of the program P. So from here on,
>>>>>>>>>>>>>>>>>>>> we'll refer to H as Ha and P as Pa to make that
>>>>>>>>>>>>>>>>>>>> point clear.
>>>>>>>>>>>>>>>>>>> I am only referring to this literal string:
>>>>>>>>>>>>>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> as an input to H(P,P) and H1(P,P). It is 100%
>>>>>>>>>>>>>>>>>>> perfectly concrete
>>>>>>>>>>>>>>>>>>> thus
>>>>>>>>>>>>>>>>>>> utterly impervious to even extremely well-crafted
>>>>>>>>>>>>>>>>>>> attempts at deception
>>>>>>>>>>>>>>>>>>> through the strawman error. Any attempt to get around
>>>>>>>>>>>>>>>>>>> this will be
>>>>>>>>>>>>>>>>>>> construed as (and labeled) a bald-faced lie by a
>>>>>>>>>>>>>>>>>>> bald-faced liar.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That string is 100% NOT concrete because it doesn't
>>>>>>>>>>>>>>>>>> specify the function that it is calling.
>>>>>>>>>>>>>>>>> I did not freaking say that this finite string
>>>>>>>>>>>>>>>>> specifies every freaking
>>>>>>>>>>>>>>>>> detail of the whole freaking system nitwit. This finite
>>>>>>>>>>>>>>>>> string as x86
>>>>>>>>>>>>>>>>> code specifies every one of its own bytes.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not the whole system, just the computation to be decided
>>>>>>>>>>>>>>>> on, and that computation includes the FIXED code of H
>>>>>>>>>>>>>>>> that aborts its simulation, i.e. Ha.
>>>>>>>>>>>>>>> Thee is no Pa, Pb, Pc, there is only this P:
>>>>>>>>>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So if that's enough information to decide on, then tell me
>>>>>>>>>>>>>> if this halts:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void F()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> X()
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I am only talking about H(P,P) and H1(P,P) where P is this
>>>>>>>>>>>>> literal
>>>>>>>>>>>>> string as x86 machine language:
>>>>>>>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>>>>>>>
>>>>>>>>>>>> Again, not a complete computation, so not enough information
>>>>>>>>>>>> to decide on. You seem to think that all "P" constructs are
>>>>>>>>>>>> the same no matter how different the H it is built on is.
>>>>>>>>>>> Within the context of my paper it is a complete computation
>>>>>>>>>>> for H(P,P).
>>>>>>>>>>> I am updating the paper to include H1(P,P).
>>>>>>>>>>
>>>>>>>>>> So if H is the *specific* decider that can detect infinite
>>>>>>>>>> simulation in Pn(Pn), then we'll refer to it as Ha to clarify
>>>>>>>>>> that point, and we'll refer to the P that calls it as Pa to
>>>>>>>>>> clarify.
>>>>>>>>>>
>>>>>>>>> I am talking about the literal string of "H" being applied to this
>>>>>>>>> literal string:
>>>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> The literal string of "H1" being applied to this literal string:
>>>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>>>
>>>>>>>> And to complete the computation being evaluated, what is the
>>>>>>>> *exact*, FIXED algorithm of H? If it is Ha, then Ha(Pa,Pa) ==
>>>>>>>> false is wrong as demonstrated by Hb(Pa,Pa) == true.
>>>>>>>>
>>>>>>>> If H is using some other algorithm, then specify the *exact*
>>>>>>>> algorithm.
>>>>>>> H and H1 are both literal byte strings that emulate their literal
>>>>>>> byte
>>>>>>> string input in pure x86 emulation mode until the behavior of this
>>>>>>> emulated literal byte string input shows that it would never
>>>>>>> reach its
>>>>>>> own final state (0xc3 ret instruction).
>>>>>>
>>>>>> So in other words, the fixed algorithm of H looks for what it
>>>>>> thinks is infinite simulation. So H is Ha, which means P is Pa.
>>>>>>
>>>>>> Hb can then be constructed to simulate for k more steps than Ha
>>>>>> and calculate Hb(Pa,Pa) == true, proving Ha(Pa,Pa) == false wrong.
>>>>> Begin Local Halt Decider Simulation
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> ...[000009d6][00211368][0021136c] 55 push ebp // enter P
>>>>> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
>>>>> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
>>>>> ...[000009dc][00211364][000009d6] 50 push eax // Push P
>>>>> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[000009e0][00211360][000009d6] 51 push ecx // Push P
>>>>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
>>>>> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
>>>>> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
>>>>> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
>>>>> ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
>>>>> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
>>>>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>
>>>>> The fact that P calls the same function from its same machine address
>>>>> with identical input parameters conclusively proves that P is stuck in
>>>>> infinite recursion.
>>>>
>>>> First, it's not recursion, infinite or otherwise. It's nested
>>>> simulation, and the conditions that are part of the simulation are
>>>> relevant.
>>> Infinitely nested simulation matches the infinite recursion infinite
>>> behavior pattern. If H verified that the function that P calls is itself
>>> then H could distinguish the difference. It need not do this infinite
>>> behavior is all that it needs to know.
>>
>> Pa doesn't call itself.  It calls Ha which simulates Pa, and the
>> simulation performed by Ha *will* abort.
>>
>>>>
>>>> And it's not infinite nested simulation because Hb simulates Pa past
>>>> the point where Ha aborts, sees that the embedded copy of Ha aborts,
>>>> and sees Pa halt. So Ha is wrong.
>>> This is factually incorrect. The outermost H sees the infinite behavior
>>> pattern first and knows that if it doesn't abort the simulation of its
>>> input after a fixed number of simulations that the input will never
>>> stop. I set this fixed number at the minimum of 2.
>>
>> There is no "if it doesn't abort" because then you're talking about Pn
>> instead of Pa.  Because Pa contains a copy of Ha, you can't talk about
>> what would happen if Ha did something different.  Ha has a *fixed*
>> algorithm,  so it *does* abort, meaning the embedded copy in Pa will
>> also abort.  So there is no infinite simulation pattern to be found
>> and Ha aborts too soon as Hb demonstrates.
>
> I am only talking about the actual behavior of the literal string H and
> H1 applied to the literal string P. If you talk about anything else you
> are talking to yourself and not me.

Except we don't apply the "string" H to the input P, we apply the
PROGRAM H to the string P

And if you are only looking at the behavior of H when applied to the
string P, you aren't talking about the Halting of P, but of H.

>
> The literal string H could have hypothetically been defined with any
> element of an infinite set of different behaviors.
>
> H always bases its halt status decision on what the behavior of its
> input would be if no H ever aborted the simulation of its input.

And then it is wrong, because H does abort, so you are using unsound
logic or a invalid definiton.

>
> If in this case the input would never reach its own final state then H
> rejects this input.
>

So you are just talking about POOP.