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.