On 6/26/2022 3:40 PM, Mr Flibble wrote:
> 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
>

That is no rebuttal what-so-ever that it is incorrect on the cases that
it does decide. Refuting the HP proofs only requires correctly deciding
this one single case: H(P,P);

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer