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

--
Copyright 2022 Pete Olcott

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