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.

>> It therefore doesn't specify a complete computation,
> It knows you screwy and deceptive naming conventions on their ass.

You're projecting. The naming convention prevents YOU from being deceptive and claiming that P is the same computation no matter what the implementation of the called H is.

The P to be decided on has a fixed algorithm. This means the H it calls / has a copy of also has a fixed algorithm. So we refer to that fixed H as Ha and the fixed P that calls it is referred to as Pa.

Ha(Pa,Pa) does not perform a correct simulation because it doesn't simulate for long enough. Hb(Pa,Pa) does simulate that same input to a final state..

> These hexadecimal bytes are the stipulated as the input to H and H1.
> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

FALSE. The input to a halt decider is the representation of a COMPLETE program/computation, and that is incomplete.

Just because a bunch of completely unrelated H's cannot simulate the completely unrelated P's built on them to a final state doesn't mean that all of them are correct.

> > so NO that is not the only thing you're referring to. The H that it calls is a part of it and is therefore immutable. So YES, H is Ha and P is Pa because the fixed algorithm of H aborts and P calls this fixed H.
> >
> These are verified facts:
> H(P,P)==false is provably correct.
> Ha(P,P)==true is provably correct.

As proved previously, Hb(Pa,Pa) == true proves that Ha(Pa,Pa) == false is wrong. If you disagree then that means you agree that Ha3(N,5) == false is correct because Ha7(N,5) == true doesn't disprove it.

> > You seem to be using this to say:
> >
> > For each i: because each Hi(Pi,Pi) == false, and because Hn(Pn,Pn) does not halt, then each Hi(Pi,Pi) == false is correct.
> >
> > Each Pi is distinct from each other, and each Hi is distinct from each other. That each Hi is unable to simulate the Pi built from it to a final state proves nothing regarding whether each of them is correct to return false. "Hello world" and Minesweeper are not the same program, so one can't be used to make conclusions about the other.
> >
> >
> >>>
> >>> For a separate H that never aborts which we'll call Hn, and Pn which calls that Hn, infinite simulation *does* happens so Ha(Pn,Pn) does correctly report non-halting. Your error is that you think this has anything to do with Ha(Pa,Pa) which is the case that matters.
> >>>
> >>>>>>
> >>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
> >>>>>>
> >>>>>> _P()
> >>>>>> [000009d6](01) 55 push ebp
> >>>>>> [000009d7](02) 8bec mov ebp,esp
> >>>>>> [000009d9](03) 8b4508 mov eax,[ebp+08]
> >>>>>> [000009dc](01) 50 push eax // push P
> >>>>>> [000009dd](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>> [000009e0](01) 51 push ecx // push P
> >>>>>> [000009e1](05) e840feffff call 00000826 // call H
> >>>>>> [000009e6](03) 83c408 add esp,+08
> >>>>>> [000009e9](02) 85c0 test eax,eax
> >>>>>> [000009eb](02) 7402 jz 000009ef
> >>>>>> [000009ed](02) ebfe jmp 000009ed
> >>>>>> [000009ef](01) 5d pop ebp
> >>>>>> [000009f0](01) c3 ret // Final state
> >>>>>> Size in bytes:(0027) [000009f0]
> >>>>>>>>
> >>>>>>>> Why is it so hard to understand that H(P,P) must provide the halt status
> >>>>>>>> of its actual input on the basis of the actual behavior specified by
> >>>>>>>> this actual input?
> >>>>>>>
> >>>>>>> The *definition* of the problem states that the actual behavior of the actual input to H(P,P) is P(P).
> >>>>>> Whomever wrote that definition also knows that
> >>>>>>
> >>>>>> THIS IS SET IN STONE:
> >>>>>> All deciders only compute the mapping from their input parameters to an
> >>>>>> accept/reject state on the basis of the actual properties actually
> >>>>>> specified by this input
> >>>>>
> >>>>> 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}.
> >>>
> >>> Again, no rebuttal, just a bad analogy.
> >>>
> >>>>>
> >>>>>>
> >>>>>> THIS LOGICALLY FOLLOWS FROM THAT:
> >>>>>> Since a halt decider is a type of decider this means that all halt
> >>>>>> deciders only compute the mapping from their input parameters to an
> >>>>>> accept/reject state on the basis of the actual behavior actually
> >>>>>> specified by this input.
> >>>>>
> >>>>> 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}.
> >>>> If anyone assigns non-decider properties to a decider they are wrong in
> >>>> the same way that it is wrong to assign {cat} properties to a {dog}.
> >>>
> >>> And again no rebuttal, just a bad analogy. Given that this is the third time you've done this, I'll take this as an admission of defeat.
> >> It is a verified fact that at least Linz claims that H must report on Ĥ
> >> applied to ⟨Ĥ⟩.
> >
> > As it is required to.
> >
> >>
> >>
> >> It is also a verified fact that this same requirement directly
> >> contradicts the definition of decider that must map its actual inputs to
> >> an accept/reject state based on the actual behavior of these actual inputs.
> >
> > It does not, because the actual behavior of the actual inputs is defined to be the machine that those inputs represent.
> I have a guy that I want you to arrest, his name is in my head.
> I am going to write down the name of some other guy, but I want
> you to arrest the guy who is named in my head. I won't tell you
> his name.

Another bad analogy with no explanation.

>
> All halt deciders only compute the mapping from their inputs to their
> own accept/reject state on the basis of the actual behavior actually
> specified by the correct simulation of this input

Which is performed by an actual UTM, or alternately by a simulator that can simulate the input to a final state.

> by the halt decider.

Assuming the halt decider does a correct simulation

> >
> >>
> >> When the author or a textbook disagrees with computer science
> >> definitions it is not computer science that is on the losing side of this.
> >
> > It doesn't. You just don't understand the definitions.
> >
> >