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.