On Sun, 26 Jun 2022 15:37:43 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/26/2022 3:15 PM, Mr Flibble wrote:
> > On Sun, 26 Jun 2022 14:54:22 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/26/2022 2:43 PM, Mr Flibble wrote:
> >>> On Sun, 26 Jun 2022 14:37:36 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/26/2022 2:26 PM, Mr Flibble wrote:
> >>>>> On Sun, 26 Jun 2022 14:11:02 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/26/2022 2:00 PM, Mr Flibble wrote:
> >>>>>>> On Sun, 26 Jun 2022 11:27:06 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> On 6/26/2022 6:15 AM, Mr Flibble wrote:
> >>>>>>>>> On Sun, 26 Jun 2022 05:31:53 -0500
> >>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 6/25/2022 9:03 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Sat, 25 Jun 2022 20:58:23 -0500
> >>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 6/25/2022 6:55 PM, Ben Bacarisse wrote:
> >>>>>>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben
> >>>>>>>>>>>>>> Bacarisse wrote:
> >>>>>>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> "Dry run" means that a human programmer looks at the
> >>>>>>>>>>>>>>>> code, and determines what it does, without actually
> >>>>>>>>>>>>>>>> executing it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Going back, now, to what you think needs to be
> >>>>>>>>>>>>>>> resolved: | He's dry-run P(P) and established that it
> >>>>>>>>>>>>>>> doesn't halt. He's invoked H | on it and H reports
> >>>>>>>>>>>>>>> that it doesn't halt. He's run P(P) and it halts. The
> >>>>>>>>>>>>>>> obvious conclusion is that PO's dry run (if he has
> >>>>>>>>>>>>>>> indeed done such a thing) is incorrect.
> >>>>>>>>>>>>>> Exactly.
> >>>>>>>>>>>>>> We do our little energy budget on tigers, and find that
> >>>>>>>>>>>>>> tigers spend more energy than they take in. Well
> >>>>>>>>>>>>>> potentially this is dynamite. One explanation is that
> >>>>>>>>>>>>>> the law of conservation of energy is wrong. Except,
> >>>>>>>>>>>>>> before we countenance that explanation, we need to
> >>>>>>>>>>>>>> rule out a much simpler explanation. Which is that our
> >>>>>>>>>>>>>> measurements are wrong.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Obviously.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Similarly, PO has worked out what he thinks P(P) should
> >>>>>>>>>>>>>> be doing, by dry-running it, and then actually run P(P)
> >>>>>>>>>>>>>> and obtained a different result. He also found that H
> >>>>>>>>>>>>>> agreed with the dry run. It's hard to paraphrase his
> >>>>>>>>>>>>>> conclusion, but it is extensive and far-reaching in its
> >>>>>>>>>>>>>> implications.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> He is just waffling. There is no conclusion, just a
> >>>>>>>>>>>>> constant twisting and turning to find some why to
> >>>>>>>>>>>>> persuade people that the wrong answer is the right one.
> >>>>>>>>>>>>> He's being doing this for years with various degrees
> >>>>>>>>>>>>> of obfuscation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> H does not report the correct result for P(P) and PO is
> >>>>>>>>>>>>> putting up anything he can think of to keep the
> >>>>>>>>>>>>> discussion going. It should simply have stopped once
> >>>>>>>>>>>>> he'd been clear that H(P,P) == 0 is correct "even
> >>>>>>>>>>>>> though P(P) halts" but the traces and the verbiage is
> >>>>>>>>>>>>> keeping people keen.
> >>>>>>>>>>>>>> The behaviour of code when run is different from the
> >>>>>>>>>>>>>> correct behaviour of the code when simulated. If that's
> >>>>>>>>>>>>>> true, then it has similar implications for computer
> >>>>>>>>>>>>>> science that disproving the conservation law has for
> >>>>>>>>>>>>>> physics.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> When a student comes to me and says that her program to
> >>>>>>>>>>>>> add 5 and 6 gives 12, I don't, even for a moment,
> >>>>>>>>>>>>> imagine that the laws of logic and mathematics are in
> >>>>>>>>>>>>> doubt.
> >>>>>>>>>>>>>> But the obvious explanation is that the dry-run was
> >>>>>>>>>>>>>> incorrect. Lots of people have suggested why it is
> >>>>>>>>>>>>>> incorrect. But they can't actually see the code. PO
> >>>>>>>>>>>>>> needs to understand that no-one will accept the
> >>>>>>>>>>>>>> complicated, far-reaching explanation, until the
> >>>>>>>>>>>>>> simple explanation has been ruled out.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For what it's worth, I don't think there is any "dry
> >>>>>>>>>>>>> run" going on here at all. PO decide years ago that
> >>>>>>>>>>>>> H(H_Hat, H_Hat) would be 0 because he knew (correctly)
> >>>>>>>>>>>>> that H could spot what would happen if H did not
> >>>>>>>>>>>>> "intervene". Everything since then -- the "it only halt
> >>>>>>>>>>>>> because...", the "it wouldn't halt if line 15 were
> >>>>>>>>>>>>> commented out" and the rather less explicitly stated
> >>>>>>>>>>>>> "H_Hat does not get to its ret instruction because a
> >>>>>>>>>>>>> non top-level H aborts" are just the various attempt at
> >>>>>>>>>>>>> after-the-fact justification.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I agree it's never quite so simple because PO is usually
> >>>>>>>>>>>>> fractally wrong, so he's not correct about almost
> >>>>>>>>>>>>> everything he says at almost every level. For example,
> >>>>>>>>>>>>> at one level he now admits that a halt decider is
> >>>>>>>>>>>>> impossible because H(X,Y) must report "on its input" and
> >>>>>>>>>>>>> the call X(Y) is not an input! He did this to explain
> >>>>>>>>>>>>> why H(P,P) is permitted to return 0 "even though P(P)
> >>>>>>>>>>>>> halts", but it also makes it clear that what he one
> >>>>>>>>>>>>> thought was that halting problem is not solvable.
> >>>>>>>>>>>>
> >>>>>>>>>>>> YOU KNOW THAT THIS IS TRUE
> >>>>>>>>>>>> A halt decider must compute the mapping from its inputs
> >>>>>>>>>>>> to an accept or reject state on the basis of the actual
> >>>>>>>>>>>> behavior that is actually specified by these inputs.
> >>>>>>>>>>>>
> >>>>>>>>>>>> BECAUSE THIS IS PROVABLY TRUE
> >>>>>>>>>>>> P(P) is provably not the actual behavior of the actual
> >>>>>>>>>>>> input.
> >>>>>>>>>>>>
> >>>>>>>>>>>> YOU ARE THE ONE FUDGING WITH THE TRUTH
> >>>>>>>>>>>
> >>>>>>>>>>> The issue is what constitutes a pathological input: the
> >>>>>>>>>>> pathological input at issue here are YOUR PATHOLOGICAL
> >>>>>>>>>>> LIES, Olcott.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Computable functions are the basic objects of
> >>>>>>>>>> study in computability theory.
> >>>>>>>>>> Computable functions are the formalized
> >>>>>>>>>> analogue of the intuitive notion of
> >>>>>>>>>> algorithms, in the sense that a function is
> >>>>>>>>>> computable if there exists an algorithm
> >>>>>>>>>> that can do the job of the function, i.e. given
> >>>>>>>>>> an input of the function domain it
> >>>>>>>>>> can return the corresponding output.
> >>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
> >>>>>>>>>>
> >>>>>>>>>> void P(u32 x)
> >>>>>>>>>> {
> >>>>>>>>>> if (H(x, x))
> >>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>> return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> That you reject that the above proves that H and P have a
> >>>>>>>>>> pathological relationship to each other seem to be your
> >>>>>>>>>> lack of technical competence rather than dishonesty.
> >>>>>>>>>
> >>>>>>>>> There is nothing wrong with my technical competence however
> >>>>>>>>> yours *is* suspect.
> >>>>>>>>>
> >>>>>>>>> Nobody is denying that P is pathological input as its comes
> >>>>>>>>> from [Strachey, 1965]'s "Impossible Program";
> >>>>>>>>
> >>>>>>>> // rec routine P
> >>>>>>>> // §L :if T[P] go to L
> >>>>>>>> // Return §
> >>>>>>>> // https://academic.oup.com/comjnl/article/7/4/313/354243
> >>>>>>>> void Strachey_P()
> >>>>>>>> {
> >>>>>>>> L:if (T(Strachey_P))
> >>>>>>>> goto L;
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> Output("Input_Halts = ", T(Strachey_P));
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> _Strachey_P()
> >>>>>>>> [000015b2](01) 55 push ebp
> >>>>>>>> [000015b3](02) 8bec mov ebp,esp
> >>>>>>>> [000015b5](05) 68b2150000 push 000015b2 // push
> >>>>>>>> Strachey_P [000015ba](05) e813fdffff call 000012d2 //
> >>>>>>>> call T [000015bf](03) 83c404 add esp,+04
> >>>>>>>> [000015c2](02) 85c0 test eax,eax
> >>>>>>>> [000015c4](02) 7402 jz 000015c8
> >>>>>>>> [000015c6](02) ebed jmp 000015b5
> >>>>>>>> [000015c8](01) 5d pop ebp
> >>>>>>>> [000015c9](01) c3 ret
> >>>>>>>> Size in bytes:(0024) [000015c9]
> >>>>>>>>
> >>>>>>>> _main()
> >>>>>>>> [000015d2](01) 55 push ebp
> >>>>>>>> [000015d3](02) 8bec mov ebp,esp
> >>>>>>>> [000015d5](05) 68b2150000 push 000015b2 // push
> >>>>>>>> Strachey_P [000015da](05) e8f3fcffff call 000012d2 //
> >>>>>>>> call T [000015df](03) 83c404 add esp,+04
> >>>>>>>> [000015e2](01) 50 push eax
> >>>>>>>> [000015e3](05) 6833040000 push 00000433
> >>>>>>>> [000015e8](05) e895eeffff call 00000482
> >>>>>>>> [000015ed](03) 83c408 add esp,+08
> >>>>>>>> [000015f0](02) 33c0 xor eax,eax
> >>>>>>>> [000015f2](01) 5d pop ebp
> >>>>>>>> [000015f3](01) c3 ret
> >>>>>>>> Size in bytes:(0034) [000015f3]
> >>>>>>>>
> >>>>>>>> machine stack stack machine assembly
> >>>>>>>> address address data code language
> >>>>>>>> ======== ======== ======== ========= ============> >>>>>>>> [000015d2][001025c6][00000000] 55 push ebp
> >>>>>>>> [000015d3][001025c6][00000000] 8bec mov ebp,esp
> >>>>>>>> [000015d5][001025c2][000015b2] 68b2150000 push 000015b2 //
> >>>>>>>> push Strachey_P [000015da][001025be][000015df] e8f3fcffff
> >>>>>>>> call 000012d2 // call T
> >>>>>>>>
> >>>>>>>> Begin Simulation Execution Trace Stored at:21267a
> >>>>>>>> Address_of_T:12d2
> >>>>>>>> [000015b2][0021266a][0021266e] 55 push ebp
> >>>>>>>> [000015b3][0021266a][0021266e] 8bec mov ebp,esp
> >>>>>>>> [000015b5][00212666][000015b2] 68b2150000 push 000015b2 //
> >>>>>>>> push Strachey_P [000015ba][00212662][000015bf] e813fdffff
> >>>>>>>> call 000012d2 // call T Infinitely Recursive Simulation
> >>>>>>>> Detected Simulation Stopped
> >>>>>>>>
> >>>>>>>> T knows its own machine address and on this basis it can
> >>>>>>>> easily examine its stored execution_trace of Strachey_P (see
> >>>>>>>> above) to determine: (a) Strachey_P is calling T with the
> >>>>>>>> same arguments that T was called with. (b) No instructions
> >>>>>>>> in Strachey_P could possibly escape this otherwise
> >>>>>>>> infinitely recursive emulation.
> >>>>>>>
> >>>>>>> There is no recursion in [Strachey, 1965] or the proofs based
> >>>>>>> on it that you are attempting to refute. Fail.
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> In other words you are saying that because a non-simulating
> >>>>>> halt decider (that has no recursive emulation) cannot correctly
> >>>>>> determine the halt status of its input that a simulating halt
> >>>>>> decider (that has recursive emulation) cannot correctly
> >>>>>> determine the halt status of its input.
> >>>>>
> >>>>> We have already established that your simulating halt decider
> >>>>> gets the answer wrong if P calls H but isn't pathological.
> >>>>>
> >>>>
> >>>> We have not established that at all.
> >>>
> >>> Yes we have:
> >>>
> >>> void Px(u32 x)
> >>> {
> >>> H(x, x);
> >>> return;
> >>> }
> >>>
> >>> int main()
> >>> {
> >>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>> }
> >>>
> >>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>> ...[000013eb][00102353][00000000] 50 push eax
> >>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>> Input_Halts = 0
> >>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>> ...[000013fc][0010235f][00000004] c3 ret
> >>> Number of Instructions Executed(16120)
> >>>
> >>> As can be seen above Olcott's H decides that Px does not halt but
> >>> it is obvious that Px should always halt if H is a valid halt
> >>> decider that always returns a decision to its caller (Px).
> >>> Olcott's H does not return a decision to its caller (Px) and is
> >>> thus invalid.
> >>>> H1(P,P)==1 is the non-pathological instance.
> >>>
> >>> See above.
> >>>
> >>>>
> >>>>>>
> >>>>>> In other words if there are no black dogs in the kitchen this
> >>>>>> proves that there are no white cats in the living room.
> >>>>>
> >>>>> You are the one trying to redefine H to be something else.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> Not something else at all.
> >>>>
> >>>> It is merely the case that no one besides me every bothered to
> >>>> fully investigate the effects of applying a simulating halt
> >>>> decider to the wide open (any pure function of its inputs will
> >>>> do) specification of the halting problem proofs.
> >>>
> >>> A simulating halt decider is invalid as it cannot return an answer
> >>> of non-halting in finite time for all non-halting inputs as there
> >>> is no proven algorithm that can detect non-halting behaviour for
> >>> the general case.
> >>>
> >>> /Flibble
> >>>
> >>>
> >>
> >> We are back to your lack of sufficient software engineering skill.
> >> You still don't understand that everything after P's function call
> >> to H(P,P) is unreachable by P from:
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H1((u32)P, (u32)P));
> >> }
> >>
> >> This means that erasing the infinite loop can have no effect.
> >> Here is the actual non-pathological input to H1(P,P):
> >>
> >> void P(u32 x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H1((u32)P, (u32)P));
> >> }
> >>
> >> H1(P,P)==1.
> >
> > The only reason erasing the infinite loop has no effect is because
> > your H aborts the simulation which is an invalid thing to do.
> >
> > /Flibble
> >
>
> A simulating halt decider must always abort every simulation that
> would otherwise never stop running.
>
> It does the same thing for:
> (a) Infinite loops
> (b) Infinite recursion
> (c) Infinitely recursive emulation
It is wrong to do that. Why? Because you have no way of knowing if the
simulation would never stop running as there is no known algorithm for
detecting non-halting behaviour for the general case.

/Flibble