On 5/9/2022 4:51 PM, wij wrote:
> On Tuesday, 10 May 2022 at 05:20:02 UTC+8, 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.
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> Your coding is invalid, because H is now shown to exist.

I provide all of the details proving that this H does exist.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer