On Monday, July 25, 2022 at 11:47:05 PM UTC-4, olcott wrote:
> On 7/25/2022 10:43 PM, Dennis Bush wrote:
> > On Monday, July 25, 2022 at 11:34:23 PM UTC-4, olcott wrote:
> >> On 7/25/2022 10:15 PM, Dennis Bush wrote:
> >>> On Monday, July 25, 2022 at 11:13:11 PM UTC-4, olcott wrote:
> >>>> On 7/25/2022 9:59 PM, Dennis Bush wrote:
> >>>>> On Monday, July 25, 2022 at 10:55:14 PM UTC-4, olcott wrote:
> >>>>>> On 7/25/2022 9:42 PM, Dennis Bush wrote:
> >>>>>>> On Monday, July 25, 2022 at 9:56:49 PM UTC-4, olcott wrote:
> >>>>>>>> On 7/25/2022 7:51 PM, Dennis Bush wrote:
> >>>>>>>>> On Monday, July 25, 2022 at 8:30:15 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 7/25/2022 4:54 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Mon, 25 Jul 2022 16:39:41 -0500
> >>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 7/25/2022 3:25 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Mon, 25 Jul 2022 15:20:39 -0500
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Mon, 25 Jul 2022 15:14:21 -0500
> >>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
> >>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 7/25/2022 2:22 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> How can we help Olcott understand that his "infinite
> >>>>>>>>>>>>>>>>>>> recursion" is a property of his simulating halting decider
> >>>>>>>>>>>>>>>>>>> and NOT a property of the input passed to his decider? His
> >>>>>>>>>>>>>>>>>>> error is compounded by him incorrectly mapping his decider's
> >>>>>>>>>>>>>>>>>>> recursion to the input being non-halting.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *People that don't comprehend that this is true*
> >>>>>>>>>>>>>>>>>> *don't comprehend that I am correct*
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In every case where the simulation would never stop unless
> >>>>>>>>>>>>>>>>>> aborted a non-halting behavior pattern is specified by the
> >>>>>>>>>>>>>>>>>> input.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> If a simulating halt decider continues to correctly simulate
> >>>>>>>>>>>>>>>>>> its input until it correctly matches a non-halting behavior
> >>>>>>>>>>>>>>>>>> pattern then this SHD is necessarily correct when it aborts its
> >>>>>>>>>>>>>>>>>> simulation and reports non-halting.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But I have designed an SHD that has no recursion at all:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem#readme
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So you are wrong to claim that infinite recursion is necessary
> >>>>>>>>>>>>>>>>> property for SHDs.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Yes you are definitely clueless on these things.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H correctly determines that Infinite_Recursion() never halts
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> void Infinite_Recursion(int N)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> Infinite_Recursion(N);
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Infinite_Recursion, 0x777));
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> _Infinite_Recursion()
> >>>>>>>>>>>>>>>> [000010f2](01) 55 push ebp
> >>>>>>>>>>>>>>>> [000010f3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>> [000010f5](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>> [000010f8](01) 50 push eax
> >>>>>>>>>>>>>>>> [000010f9](05) e8f4ffffff call 000010f2
> >>>>>>>>>>>>>>>> [000010fe](03) 83c404 add esp,+04
> >>>>>>>>>>>>>>>> [00001101](01) 5d pop ebp
> >>>>>>>>>>>>>>>> [00001102](01) c3 ret
> >>>>>>>>>>>>>>>> Size in bytes:(0017) [00001102]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But P isn't recursive; your H is.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In every case where the simulation would never stop unless aborted
> >>>>>>>>>>>>>> a non-halting behavior pattern is specified by the input.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> FALSE. The following input specifies a halting "behavior pattern":
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> void Px()
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> (void)H(Px, Px);
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> H(Px,Px); // simulated input is infinitely recursive.
> >>>>>>>>>>>> Px(Px); // halts
> >>>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> And there's the rub: everyone except you can see a problem there.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> Everyone besides me simply assumes that the behavior must be the same
> >>>>>>>>>> while not bothering to verify that it is proven fact that the behavior
> >>>>>>>>>> is not the same.
> >>>>>>>>>>
> >>>>>>>>>> In example 05 shown in my paper
> >>>>>>>>>>
> >>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>>>>>>>>>
> >>>>>>>>>> When we look at the line-by-line execution trace of P(P) and the
> >>>>>>>>>> simulation of the input to H(P,P) we see that in both cases this exactly
> >>>>>>>>>> matches the line-by-line x86 source-code listing of P.
> >>>>>>>>>
> >>>>>>>>> FALSE. A line-by-line comparison shows that the trace of both are *identical* up to the point where the simulation by H aborts. Then the direct execution continues past that point to a final state,
> >>>>>>>> Yes that much is true.
> >>>>>>>>> demonstrating that H aborted too soon.
> >>>>>>>> No that is counter-factual.
> >>>>>>>
> >>>>>>> Not according to a UTM simulation of the same input, i.e. UTM(Pa,Pa)
> >>>>>>>
> >>>>>>>>
> >>>>>>>> I know that you are smart enough to know that it is an easily verified
> >>>>>>>> fact (for every master of the x86 language) to see that if H(P,P) never
> >>>>>>>> aborted the simulation of its input
> >>>>>>>
> >>>>>>> Is irrelevant because it DOES abort. And because it does, there is no infinite recursion.
> >>>>>> In other words you are saying there is no infinite loop because the
> >>>>>> simulated infinite loop is aborted.
> >>>>>
> >>>>> Again, there is no simulated infinite loop. Ha thinks there is but there is not. UTM(Pa,Pa) demonstrates this fact.
> >>>>>
> >>>> So when H0 simulates Infinite_Loop() there is no partial simulation of
> >>>> any infinite loop?
> >>>
> >>>
> >>> The difference is that UTM(Infinite_Loop) does not halt, while UTM(Pa,Pa) does halt. That means there is no infinite loop in Pa(Pa), contrary to what Ha might think.
> >> I just looked up your profile again. I was born in Orange New Jersey.
> >> Your profile seems to indicate that you have great technical competence:
> >>
> >> "I develop primarily in C and Java, with interests in network
> >> programming, encryption, network security, and multicast."
> >>
> >> *It does not indicate any competence with the x86 language*
> >>
> >> Simulate(P,P) halts
> >> P(P) halts
> >> H1(P,P) reports 1 for halting
> >>
> >> The correctly simulated input to H(P,P) does not halt only because H and
> >> P have the following pathological relationship to each other:
> >>
> >> For any program H that might determine if programs halt, a
> >> "pathological" program P, called with some input, can pass its own
> >> source and its input to H and then specifically do the opposite of what
> >> H predicts P will do. No H can exist that handles this case.
> >> https://en.wikipedia.org/wiki/Halting_problem
> >>
> >> The execution trace of the correct simulation of the input to H(P,P)
> >> proves that it never reaches its "return" instruction and halts whether
> >> or not it is aborted.
> >>
> >> It seems that no one understands the x86 language well enough to see
> >> this, and tries to bluff through their ignorance and claim that I am
> >> incorrect anyway.
> >
> > You are claiming that no implementation of the function H can simulate the function P to completion.
> Go back and carefully read what I said and see that I already answered
> this.

So if Ha is a halt decider, what input must be passed to it to determine if Pa(Pa) halts?