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

--
Copyright 2022 Pete Olcott

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