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.

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

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.

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

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.

Click here to read the complete article

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
>

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

Click here to read the complete article

Mr Flibble <flibble@reddwarf.jmc> writes:

> On Sun, 26 Jun 2022 14:40:26 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
<a typically accurate refutation>

> If I reply to you Olcott will see your post. :)

Why would you do that?!! Being ignored by PO is blessing bestowed on
very few. He's said he'll ignore me a few times but, alas, he has not
yet done so. Imagine a world in which he never replies to anything you
post!

Of course he will never ignore every critic because talking down to
people who know the subject is how he feeds his fragile sense of
self-worth, but a few of us can live in hope.

--
Ben.

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
>

On 6/26/2022 3:42 PM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc> writes:
>
>> On Sun, 26 Jun 2022 14:40:26 -0400
>> Richard Damon <Richard@Damon-Family.org> wrote:
> <a typically accurate refutation>
>
>> If I reply to you Olcott will see your post. :)
>
> Why would you do that?!! Being ignored by PO is blessing bestowed on
> very few. He's said he'll ignore me a few times but, alas, he has not
> yet done so. Imagine a world in which he never replies to anything you
> post!
>
> Of course he will never ignore every critic because talking down to
> people who know the subject is how he feeds his fragile sense of
> self-worth, but a few of us can live in hope.
>

Mere rhetoric is the only form of rebuttal available to those not
technically qualified to provide a basis in reasoning.

I don't say this as any put down, I merely want other reviewers to
understand the actual truth.

*This is the outline of the complete refutation*
*of the only rebuttal that anyone has left*

(a) and (b) are proven to be verified facts entirely on the basis of the
semantics of the x86 language. (Most people here do not seem to "believe
in" the semantics of the x86 language otherwise they would have no basis
to disagree).

(a) The complete and correct x86 emulation of the input to H(P,P) by H
never reaches the "ret" instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

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.

P(P) is provably not the actual behavior of the actual input.

--
Copyright 2022 Pete Olcott

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

On Sunday, 26 June 2022 at 11:43:07 UTC+1, olcott wrote:
> On 6/26/2022 5:14 AM, Malcolm McLean wrote:
> > On Sunday, 26 June 2022 at 00:56:03 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@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.
> > If the tiger experimenters kick up a fuss about showing you their
> > notebooks, when the notebooks are available and there's no logistical
> > reason for the refusal, then you can dismiss the idea that they've disproved
> > the law of conservation of energy out of hand. The two things, together,
> > an impossible claim and a shifty, evasive attitude make up an overwhelming
> > case against.
> So basically you are utterly clueless that I conclusively proved that
> the correct and complete x86 emulation of the input to H(P,P) by H would
> never reach its "ret" instruction and the direct execution of P(P) does
> reach it "ret" instruction.
>
You dry run P(P) and determined that it never halted.
You ran H on P(P) and it reported non-halting. So that's extremely surprising,
since we've good reasons for supposing that H cannot classify P(p) correctly.
You ran P(P) and it halted.

Now one explanation, which you don't offer, is that something is wrong with
the computer. The halting theorem is false, H is correct, and P(P) halted
because of a hardware error.
It is extremely unlikely that computer would malfunction like that. And it would
be a massive coincidence for it to so malfunction just at the moment
you needed to verify it disprove an established theorem. So that can be rejected.
And, in fairness, you don't offer that explanation.

Another explanation is that there is some difference between P(P), the call,
and P,P, the input to H. Now what sort of insanity is this? However I agree that
we are forced to that type of explanation is we accept that the dry run of P(P)
is correct, the actual run of P(P) doesn't match the dry run, and the computer
is not malfunctioning.

But the obvious explanation is that the dry run of P(P) was not correct, H is
not correct, as predicted by the theorem, and the computer is working correctly.

In fact, if H works on the principles that you have described, then the dry run
cannot be correct. This has been pointed out many times.

So at this point, you need to show H. Otherwise no-one will accept that dry run is
correct.

Just as, if your experiments on tigers show that they use more energy than they
consume, you have to show your notebooks. People will go through them with
a toothcomb, and, even if they can't find an error, they will still say that there must
be a simple measurement error somewhere, but they can't quite identify it. But
eventually, if you are right, more data will come in.

On 6/26/2022 3:58 PM, Malcolm McLean wrote:
> On Sunday, 26 June 2022 at 11:43:07 UTC+1, olcott wrote:
>> On 6/26/2022 5:14 AM, Malcolm McLean wrote:
>>> On Sunday, 26 June 2022 at 00:56:03 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@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.
>>> If the tiger experimenters kick up a fuss about showing you their
>>> notebooks, when the notebooks are available and there's no logistical
>>> reason for the refusal, then you can dismiss the idea that they've disproved
>>> the law of conservation of energy out of hand. The two things, together,
>>> an impossible claim and a shifty, evasive attitude make up an overwhelming
>>> case against.
>> So basically you are utterly clueless that I conclusively proved that
>> the correct and complete x86 emulation of the input to H(P,P) by H would
>> never reach its "ret" instruction and the direct execution of P(P) does
>> reach it "ret" instruction.
>>
> You dry run P(P) and determined that it never halted.
> You ran H on P(P) and it reported non-halting. So that's extremely surprising,
> since we've good reasons for supposing that H cannot classify P(p) correctly.
> You ran P(P) and it halted.
>
> Now one explanation, which you don't offer, is that something is wrong with
> the computer. The halting theorem is false, H is correct, and P(P) halted
> because of a hardware error.
> It is extremely unlikely that computer would malfunction like that. And it would
> be a massive coincidence for it to so malfunction just at the moment
> you needed to verify it disprove an established theorem. So that can be rejected.
> And, in fairness, you don't offer that explanation.
>
> Another explanation is that there is some difference between P(P), the call,
> and

the behavior

This is the outline of the proof of that.

(a) and (b) are proven to be verified facts entirely on the basis of the
semantics of the x86 language. (Most people here do not seem to "believe
in" the semantics of the x86 language otherwise they would have no basis
to disagree).

(a) The complete and correct x86 emulation of the input to H(P,P) by H
never reaches the "ret" instruction of P.

(b) The direct execution of P(P) does reach its "ret" instruction.

Every "rebuttal" of this is entirely anchored in insufficient technical
competence of semantics of the x86 language.

> P,P, the input to H. Now what sort of insanity is this? However I agree that
> we are forced to that type of explanation is we accept that the dry run of P(P)
> is correct, the actual run of P(P) doesn't match the dry run, and the computer
> is not malfunctioning.
>

> But the obvious explanation is that the dry run of P(P) was not correct, H is
> not correct, as predicted by the theorem, and the computer is working correctly.
>

It is intuitively obvious that the behavior of the simulated input to
H(P,P) must be the same as the behavior of the direct execution of P(P).
It is correctly mathematically proven that they are not the same.

> In fact, if H works on the principles that you have described, then the dry run
> cannot be correct. This has been pointed out many times.
>
> So at this point, you need to show H. Otherwise no-one will accept that dry run is
> correct.
>
> Just as, if your experiments on tigers show that they use more energy than they
> consume, you have to show your notebooks. People will go through them with
> a toothcomb, and, even if they can't find an error, they will still say that there must
> be a simple measurement error somewhere, but they can't quite identify it. But
> eventually, if you are right, more data will come in.

--
Copyright 2022 Pete Olcott

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