On 5/9/22 6:24 PM, 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.
>
>>
>> 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.
>
>

Nope, you are using incorrect logic. Yes, H can prove that if all copies
of H never abort their simulation of the input, then P would be
non-halting, but that doesn't mean that if all copies of H do abort
their simulation of the input that it is still non-halting.

You basically have this erroneous logic arguement

p: H doesn't abort its simulation
q: P will be non-halting

H has shown that: p -> q

Then H decides that: !p (Because H WILL abort its simulation)

and you are from that concluding:

q

That isn't sound logic.