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.

--
Copyright 2022 Pete Olcott

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