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.

Just because:

H1(P1,P1) == false
H2(P2,P2) == false
H3(P3,P3) == false
H4(P4,P4) == false
H5(P5,P5) == false
....

Doesn't mean all of them are correct.

>
> Any replies diverging from this will simply be ignored without comment
> as attempts to deceive using the strawman error

Projection. You're the one attempting to deceive by using "P" and "H" to refer to multiple different computations at the same time.

You can't talk about P without talking about the *specific* H that it calls. Ha(Pa,Pa) == false is wrong as proved by Hb(Pa,Pa) == true