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.
H1(P,P)==1 is the non-pathological instance.

>>
>> 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.

--
Copyright 2022 Pete Olcott

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