On 6/17/22 11:33 AM, olcott wrote:
> On 6/17/2022 9:56 AM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 09:51:07 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/17/2022 9:39 AM, wij wrote:
>>>> On Friday, 17 June 2022 at 22:19:09 UTC+8, olcott wrote:
>>>>> On 6/17/2022 8:39 AM, wij wrote:
>>>>>> On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott wrote:
>>>>>>> When a simulating halt decider rejects all inputs as non-halting
>>>>>>> whenever it correctly detects that its correct and complete
>>>>>>> simulation of its input would never reach the final state of
>>>>>>> this input then all [these] inputs (including pathological
>>>>>>> inputs) are decided correctly.
>>>>>>>
>>>>>>> *computation that halts* … the Turing machine will halt whenever
>>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>>
>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>
>>>>>>> #include <stdint.h>
>>>>>>> typedef void (*ptr)();
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [00001352](01) 55 push ebp
>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>> [0000136c](01) c3 ret
>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>
>>>>>>> (1) It is an easily verified fact that when we assume that H is
>>>>>>> only an x86 emulator that the correctly emulated P never reaches
>>>>>>> its "ret" instruction it remains stuck in repeated cycles of
>>>>>>> emulation.
>>>>>>>
>>>>>>> (2) It is an easily verified fact that if H has been adapted to
>>>>>>> correctly detect (in a finite number of steps) that the correct
>>>>>>> and complete x86 emulation of its input would never each its
>>>>>>> "ret" instruction that H could abort its emulation and return 0
>>>>>>> to report this.
>>>>>>>
>>>>>>> (3) When the halt status criteria is defined as correctly
>>>>>>> determining whether or not an x86 emulated input would ever
>>>>>>> reach its "ret" instruction then it becomes an easily verified
>>>>>>> fact H(P,P) could correctly reject its input as non-halting.
>>>>>>>
>>>>>>> Correct deductive inference proves that all of these things are
>>>>>>> true without any need what-so-ever to see either the source-code
>>>>>>> or the execution trace of H.
>>>>>>>
>>>>>>> The one thing that is not proved is whether or not an actual
>>>>>>> encoded H(P,P) does indeed correctly determine that its input
>>>>>>> would never reach its "ret" instruction as a pure function of
>>>>>>> its inputs. This aspect will be confirmed by fully operational
>>>>>>> source-code.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>> (V5)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>
>>>>>>> "Talent hits a target no one else can hit;
>>>>>>> Genius hits a target no one else can see."
>>>>>>> Arthur Schopenhauer
>>>>>>
>>>>>> GUR already suggested such a halting decider H cannot exist:
>>>>>>
>>>>>> H(P,P)==0 means P(P) does not halt.
>>>>> That is a misconception.
>>>>>
>>>>> Halt deciders must compute the mapping from their inputs to an
>>>>> accept or reject state on the basis of the actual behavior
>>>>> actually specified by these inputs.
>>>>>
>>>>> It is an easily verified fact that the correct and complete x86
>>>>> emulation of the input to H(P,P) by H would never reach its "ret"
>>>>> instruction thus conclusively proving that it never halts.
>>>>>> H(P,P)==1 means P(P) halts.
>>>>>> H(P,P)==Otherwise means H fails as a decider (undecidable).
>>>>>>
>>>>>> -----
>>>>>> Thanks to PO's years' tireless efforts demonstrated even himself
>>>>>> a genius in 10000-years cannot refute my GUR. ...
>>>>> --
>>>>> Copyright 2022 Pete Olcott
>>>>>
>>>>> "Talent hits a target no one else can hit;
>>>>> Genius hits a target no one else can see."
>>>>> Arthur Schopenhauer
>>>>
>>>> GUR suggests no halting decider can exist. You just confirms it by
>>>> not able to provide POOH to test/review.
>>>
>>> It took me six months to figure out how to transform H(P,P) into a
>>> pure function of its inputs. I did not release the code before
>>> because I knew that its use of static local data would have been
>>> rejected. With this update to H I will be able to publish the code.
>>>
>>> H recognizes that P is calling itself with its same arguments that it
>>> was called with and there are no instructions preceding this call
>>> that could possibly escape infinitely recursive emulation so H aborts
>>> its emulation of P before P even makes its first call to H.
>>>
>>> Without even looking at the code competent software engineers will be
>>> able to verify that the above H would correctly determine that that
>>> is input is non-halting as a pure function of this input.
>>
>> So my other reply for why your H is not a pure function for any
>> accepted definition of the term.
>>
>> /Flibble
>>
>
> In computer programming, a pure function is a function that has the
> following properties:
>
> (1) the function return values are identical for identical arguments (no
> variation with local static variables, non-local variables, mutable
> reference arguments or input streams), and
>
> (2) the function application has no side effects (no mutation of local
> static variables, non-local variables, mutable reference arguments or
> input/output streams).
>
> Thus a pure function is a computational analogue of a mathematical
> function. https://en.wikipedia.org/wiki/Pure_function
>
> The revised H has no:
> (a) local static variables
> (b) non-local variables
> (c) mutable reference arguments
> (d) input streams
>
>

So the H(P,P) called by P(P needs to return 0 in finite time, and NOT
cause an infinite recursion just like the call to H(P,P) by main (and
thus H(P,P) retuning 0 is wrong, as the input halts), or

On 6/17/22 11:49 AM, olcott wrote:
> On 6/17/2022 10:37 AM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 10:33:59 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/17/2022 9:56 AM, Mr Flibble wrote:
>>>> On Fri, 17 Jun 2022 09:51:07 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 6/17/2022 9:39 AM, wij wrote:
>>>>>> On Friday, 17 June 2022 at 22:19:09 UTC+8, olcott wrote:
>>>>>>> On 6/17/2022 8:39 AM, wij wrote:
>>>>>>>> On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott wrote:
>>>>>>>>> When a simulating halt decider rejects all inputs as
>>>>>>>>> non-halting whenever it correctly detects that its correct and
>>>>>>>>> complete simulation of its input would never reach the final
>>>>>>>>> state of this input then all [these] inputs (including
>>>>>>>>> pathological inputs) are decided correctly.
>>>>>>>>>
>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>
>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>
>>>>>>>>> #include <stdint.h>
>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>> if (H(x, x))
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>
>>>>>>>>> (1) It is an easily verified fact that when we assume that H is
>>>>>>>>> only an x86 emulator that the correctly emulated P never
>>>>>>>>> reaches its "ret" instruction it remains stuck in repeated
>>>>>>>>> cycles of emulation.
>>>>>>>>>
>>>>>>>>> (2) It is an easily verified fact that if H has been adapted to
>>>>>>>>> correctly detect (in a finite number of steps) that the correct
>>>>>>>>> and complete x86 emulation of its input would never each its
>>>>>>>>> "ret" instruction that H could abort its emulation and return 0
>>>>>>>>> to report this.
>>>>>>>>>
>>>>>>>>> (3) When the halt status criteria is defined as correctly
>>>>>>>>> determining whether or not an x86 emulated input would ever
>>>>>>>>> reach its "ret" instruction then it becomes an easily verified
>>>>>>>>> fact H(P,P) could correctly reject its input as non-halting.
>>>>>>>>>
>>>>>>>>> Correct deductive inference proves that all of these things are
>>>>>>>>> true without any need what-so-ever to see either the
>>>>>>>>> source-code or the execution trace of H.
>>>>>>>>>
>>>>>>>>> The one thing that is not proved is whether or not an actual
>>>>>>>>> encoded H(P,P) does indeed correctly determine that its input
>>>>>>>>> would never reach its "ret" instruction as a pure function of
>>>>>>>>> its inputs. This aspect will be confirmed by fully operational
>>>>>>>>> source-code.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>> (V5)
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>
>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>> Arthur Schopenhauer
>>>>>>>>
>>>>>>>> GUR already suggested such a halting decider H cannot exist:
>>>>>>>>
>>>>>>>> H(P,P)==0 means P(P) does not halt.
>>>>>>> That is a misconception.
>>>>>>>
>>>>>>> Halt deciders must compute the mapping from their inputs to an
>>>>>>> accept or reject state on the basis of the actual behavior
>>>>>>> actually specified by these inputs.
>>>>>>>
>>>>>>> It is an easily verified fact that the correct and complete x86
>>>>>>> emulation of the input to H(P,P) by H would never reach its "ret"
>>>>>>> instruction thus conclusively proving that it never halts.
>>>>>>>> H(P,P)==1 means P(P) halts.
>>>>>>>> H(P,P)==Otherwise means H fails as a decider (undecidable).
>>>>>>>>
>>>>>>>> -----
>>>>>>>> Thanks to PO's years' tireless efforts demonstrated even himself
>>>>>>>> a genius in 10000-years cannot refute my GUR. ...
>>>>>>> --
>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>
>>>>>>> "Talent hits a target no one else can hit;
>>>>>>> Genius hits a target no one else can see."
>>>>>>> Arthur Schopenhauer
>>>>>>
>>>>>> GUR suggests no halting decider can exist. You just confirms it by
>>>>>> not able to provide POOH to test/review.
>>>>>
>>>>> It took me six months to figure out how to transform H(P,P) into a
>>>>> pure function of its inputs. I did not release the code before
>>>>> because I knew that its use of static local data would have been
>>>>> rejected. With this update to H I will be able to publish the code.
>>>>>
>>>>> H recognizes that P is calling itself with its same arguments that
>>>>> it was called with and there are no instructions preceding this
>>>>> call that could possibly escape infinitely recursive emulation so
>>>>> H aborts its emulation of P before P even makes its first call to
>>>>> H.
>>>>>
>>>>> Without even looking at the code competent software engineers will
>>>>> be able to verify that the above H would correctly determine that
>>>>> that is input is non-halting as a pure function of this input.
>>>>
>>>> So my other reply for why your H is not a pure function for any
>>>> accepted definition of the term.
>>>>
>>>> /Flibble
>>>
>>> In computer programming, a pure function is a function that has the
>>> following properties:
>>>
>>> (1) the function return values are identical for identical arguments
>>> (no variation with local static variables, non-local variables,
>>> mutable reference arguments or input streams), and
>>>
>>> (2) the function application has no side effects (no mutation of
>>> local static variables, non-local variables, mutable reference
>>> arguments or input/output streams).
>>>
>>> Thus a pure function is a computational analogue of a mathematical
>>> function. https://en.wikipedia.org/wiki/Pure_function
>>>
>>> The revised H has no:
>>> (a) local static variables
>>> (b) non-local variables
>>> (c) mutable reference arguments
>>> (d) input streams
>> Aborting the simulation is a side effect; pure functions do not have
>> side effects.
>>
>> /Flibble
>
> You have a reading comprehension problem.
> If H does not have (a)(b)(c)(d) then
> H has no mutation side effect to (a)(b)(c)(d)
>
>

On 6/17/22 12:33 PM, olcott wrote:
> On 6/17/2022 11:22 AM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 11:16:15 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/17/2022 11:14 AM, Mr Flibble wrote:
>>>> On Fri, 17 Jun 2022 11:12:31 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 6/17/2022 10:56 AM, Mr Flibble wrote:
>>>>>> On Fri, 17 Jun 2022 10:49:08 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/17/2022 10:37 AM, Mr Flibble wrote:
>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 6/17/2022 9:56 AM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 17 Jun 2022 09:51:07 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/17/2022 9:39 AM, wij wrote:
>>>>>>>>>>>> On Friday, 17 June 2022 at 22:19:09 UTC+8, olcott wrote:
>>>>>>>>>>>>> On 6/17/2022 8:39 AM, wij wrote:
>>>>>>>>>>>>>> On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott wrote:
>>>>>>>>>>>>>>> When a simulating halt decider rejects all inputs as
>>>>>>>>>>>>>>> non-halting whenever it correctly detects that its
>>>>>>>>>>>>>>> correct and complete simulation of its input would never
>>>>>>>>>>>>>>> reach the final state of this input then all [these]
>>>>>>>>>>>>>>> inputs (including pathological inputs) are decided
>>>>>>>>>>>>>>> correctly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company.
>>>>>>>>>>>>>>> (317-320)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (1) It is an easily verified fact that when we assume
>>>>>>>>>>>>>>> that H is only an x86 emulator that the correctly
>>>>>>>>>>>>>>> emulated P never reaches its "ret" instruction it
>>>>>>>>>>>>>>> remains stuck in repeated cycles of emulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (2) It is an easily verified fact that if H has been
>>>>>>>>>>>>>>> adapted to correctly detect (in a finite number of steps)
>>>>>>>>>>>>>>> that the correct and complete x86 emulation of its input
>>>>>>>>>>>>>>> would never each its "ret" instruction that H could abort
>>>>>>>>>>>>>>> its emulation and return 0 to report this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (3) When the halt status criteria is defined as correctly
>>>>>>>>>>>>>>> determining whether or not an x86 emulated input would
>>>>>>>>>>>>>>> ever reach its "ret" instruction then it becomes an
>>>>>>>>>>>>>>> easily verified fact H(P,P) could correctly reject its
>>>>>>>>>>>>>>> input as non-halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Correct deductive inference proves that all of these
>>>>>>>>>>>>>>> things are true without any need what-so-ever to see
>>>>>>>>>>>>>>> either the source-code or the execution trace of H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The one thing that is not proved is whether or not an
>>>>>>>>>>>>>>> actual encoded H(P,P) does indeed correctly determine
>>>>>>>>>>>>>>> that its input would never reach its "ret" instruction
>>>>>>>>>>>>>>> as a pure function of its inputs. This aspect will be
>>>>>>>>>>>>>>> confirmed by fully operational source-code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> GUR already suggested such a halting decider H cannot
>>>>>>>>>>>>>> exist:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H(P,P)==0 means P(P) does not halt.
>>>>>>>>>>>>> That is a misconception.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Halt deciders must compute the mapping from their inputs to
>>>>>>>>>>>>> an accept or reject state on the basis of the actual
>>>>>>>>>>>>> behavior actually specified by these inputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is an easily verified fact that the correct and complete
>>>>>>>>>>>>> x86 emulation of the input to H(P,P) by H would never reach
>>>>>>>>>>>>> its "ret" instruction thus conclusively proving that it
>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>> H(P,P)==1 means P(P) halts.
>>>>>>>>>>>>>> H(P,P)==Otherwise means H fails as a decider
>>>>>>>>>>>>>> (undecidable).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>> Thanks to PO's years' tireless efforts demonstrated even
>>>>>>>>>>>>>> himself a genius in 10000-years cannot refute my GUR. ...
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>>>>>
>>>>>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>
>>>>>>>>>>>> GUR suggests no halting decider can exist. You just confirms
>>>>>>>>>>>> it by not able to provide POOH to test/review.
>>>>>>>>>>>
>>>>>>>>>>> It took me six months to figure out how to transform H(P,P)
>>>>>>>>>>> into a pure function of its inputs. I did not release the
>>>>>>>>>>> code before because I knew that its use of static local data
>>>>>>>>>>> would have been rejected. With this update to H I will be
>>>>>>>>>>> able to publish the code.
>>>>>>>>>>>
>>>>>>>>>>> H recognizes that P is calling itself with its same arguments
>>>>>>>>>>> that it was called with and there are no instructions
>>>>>>>>>>> preceding this call that could possibly escape infinitely
>>>>>>>>>>> recursive emulation so H aborts its emulation of P before P
>>>>>>>>>>> even makes its first call to H.
>>>>>>>>>>>
>>>>>>>>>>> Without even looking at the code competent software engineers
>>>>>>>>>>> will be able to verify that the above H would correctly
>>>>>>>>>>> determine that that is input is non-halting as a pure
>>>>>>>>>>> function of this input.
>>>>>>>>>>
>>>>>>>>>> So my other reply for why your H is not a pure function for
>>>>>>>>>> any accepted definition of the term.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> In computer programming, a pure function is a function that has
>>>>>>>>> the following properties:
>>>>>>>>>
>>>>>>>>> (1) the function return values are identical for identical
>>>>>>>>> arguments (no variation with local static variables, non-local
>>>>>>>>> variables, mutable reference arguments or input streams), and
>>>>>>>>>
>>>>>>>>> (2) the function application has no side effects (no mutation
>>>>>>>>> of local static variables, non-local variables, mutable
>>>>>>>>> reference arguments or input/output streams).
>>>>>>>>>
>>>>>>>>> Thus a pure function is a computational analogue of a
>>>>>>>>> mathematical function.
>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>
>>>>>>>>> The revised H has no:
>>>>>>>>> (a) local static variables
>>>>>>>>> (b) non-local variables
>>>>>>>>> (c) mutable reference arguments
>>>>>>>>> (d) input streams
>>>>>>>> Aborting the simulation is a side effect; pure functions do not
>>>>>>>> have side effects.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> You have a reading comprehension problem.
>>>>>>> If H does not have (a)(b)(c)(d) then
>>>>>>> H has no mutation side effect to (a)(b)(c)(d)
>>>>>>
>>>>>> Not at all, but you do seem to have that problem.
>>>>>>
>>>>>> Again:
>>>>>>
>>>>>> Aborting the simulation is a side effect; pure functions do not
>>>>>> have side effects.
>>>>>
>>>>> Whether or not it is construed as a side-effect does not matter it
>>>>> must be a mutation side-effect to (a)(b)(c)(d) or it does not
>>>>> count.
>>>>
>>>> It doesn't count according to who?
>>>
>>> The above definition of pure functions.
>>
>> "In computer science, an operation, function or expression is said to
>> have a side effect if it modifies some state variable value(s) outside
>> its local environment,
>
> The second part is an inaccurate paraphrase of the first part.
>
>> which is to say if it has any observable effect
>> other than its primary effect of returning a value to the invoker of
>> the operation." --
>> https://en.wikipedia.org/wiki/Side_effect_(computer_science)
>>
>> "any observable effect"
>>
>> Aborting the simulation instead of returning a value to the invoker
>> disqualifies it from being a pure function.
>>
>> /Flibble
>>
>
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> ize in bytes:(0027) [0000136c]
>
> H aborts its x86 emulation of P as soon P reaches its machine address of
> [0000135d] the very first time before the code at this address is
> emulated. Then H returns 0 to its caller: main().
>
>

On 6/17/22 12:51 PM, olcott wrote:
> On 6/17/2022 11:41 AM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 11:38:29 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/17/2022 11:36 AM, Mr Flibble wrote:
>>>> On Fri, 17 Jun 2022 11:33:22 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 6/17/2022 11:22 AM, Mr Flibble wrote:
>>>>>> On Fri, 17 Jun 2022 11:16:15 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/17/2022 11:14 AM, Mr Flibble wrote:
>>>>>>>> On Fri, 17 Jun 2022 11:12:31 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 6/17/2022 10:56 AM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 17 Jun 2022 10:49:08 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/17/2022 10:37 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 6/17/2022 9:56 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 17 Jun 2022 09:51:07 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 6/17/2022 9:39 AM, wij wrote:
>>>>>>>>>>>>>>>> On Friday, 17 June 2022 at 22:19:09 UTC+8, olcott
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> On 6/17/2022 8:39 AM, wij wrote:
>>>>>>>>>>>>>>>>>> On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> When a simulating halt decider rejects all inputs as
>>>>>>>>>>>>>>>>>>> non-halting whenever it correctly detects that its
>>>>>>>>>>>>>>>>>>> correct and complete simulation of its input would
>>>>>>>>>>>>>>>>>>> never reach the final state of this input then all
>>>>>>>>>>>>>>>>>>> [these] inputs (including pathological inputs) are
>>>>>>>>>>>>>>>>>>> decided correctly.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *computation that halts* … the Turing machine will
>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state.
>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages
>>>>>>>>>>>>>>>>>>> and Automata. Lexington/Toronto: D. C. Heath and
>>>>>>>>>>>>>>>>>>> Company. (317-320)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (1) It is an easily verified fact that when we assume
>>>>>>>>>>>>>>>>>>> that H is only an x86 emulator that the correctly
>>>>>>>>>>>>>>>>>>> emulated P never reaches its "ret" instruction it
>>>>>>>>>>>>>>>>>>> remains stuck in repeated cycles of emulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (2) It is an easily verified fact that if H has been
>>>>>>>>>>>>>>>>>>> adapted to correctly detect (in a finite number of
>>>>>>>>>>>>>>>>>>> steps) that the correct and complete x86 emulation of
>>>>>>>>>>>>>>>>>>> its input would never each its "ret" instruction that
>>>>>>>>>>>>>>>>>>> H could abort its emulation and return 0 to report
>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (3) When the halt status criteria is defined as
>>>>>>>>>>>>>>>>>>> correctly determining whether or not an x86 emulated
>>>>>>>>>>>>>>>>>>> input would ever reach its "ret" instruction then it
>>>>>>>>>>>>>>>>>>> becomes an easily verified fact H(P,P) could
>>>>>>>>>>>>>>>>>>> correctly reject its input as non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Correct deductive inference proves that all of these
>>>>>>>>>>>>>>>>>>> things are true without any need what-so-ever to see
>>>>>>>>>>>>>>>>>>> either the source-code or the execution trace of H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The one thing that is not proved is whether or not an
>>>>>>>>>>>>>>>>>>> actual encoded H(P,P) does indeed correctly determine
>>>>>>>>>>>>>>>>>>> that its input would never reach its "ret"
>>>>>>>>>>>>>>>>>>> instruction as a pure function of its inputs. This
>>>>>>>>>>>>>>>>>>> aspect will be confirmed by fully operational
>>>>>>>>>>>>>>>>>>> source-code.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> GUR already suggested such a halting decider H cannot
>>>>>>>>>>>>>>>>>> exist:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H(P,P)==0 means P(P) does not halt.
>>>>>>>>>>>>>>>>> That is a misconception.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Halt deciders must compute the mapping from their
>>>>>>>>>>>>>>>>> inputs to an accept or reject state on the basis of
>>>>>>>>>>>>>>>>> the actual behavior actually specified by these inputs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>> would never reach its "ret" instruction thus
>>>>>>>>>>>>>>>>> conclusively proving that it never halts.
>>>>>>>>>>>>>>>>>> H(P,P)==1 means P(P) halts.
>>>>>>>>>>>>>>>>>> H(P,P)==Otherwise means H fails as a decider
>>>>>>>>>>>>>>>>>> (undecidable).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>> Thanks to PO's years' tireless efforts demonstrated
>>>>>>>>>>>>>>>>>> even himself a genius in 10000-years cannot refute my
>>>>>>>>>>>>>>>>>> GUR. ...
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> GUR suggests no halting decider can exist. You just
>>>>>>>>>>>>>>>> confirms it by not able to provide POOH to test/review.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It took me six months to figure out how to transform
>>>>>>>>>>>>>>> H(P,P) into a pure function of its inputs. I did not
>>>>>>>>>>>>>>> release the code before because I knew that its use of
>>>>>>>>>>>>>>> static local data would have been rejected. With this
>>>>>>>>>>>>>>> update to H I will be able to publish the code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H recognizes that P is calling itself with its same
>>>>>>>>>>>>>>> arguments that it was called with and there are no
>>>>>>>>>>>>>>> instructions preceding this call that could possibly
>>>>>>>>>>>>>>> escape infinitely recursive emulation so H aborts its
>>>>>>>>>>>>>>> emulation of P before P even makes its first call to H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Without even looking at the code competent software
>>>>>>>>>>>>>>> engineers will be able to verify that the above H would
>>>>>>>>>>>>>>> correctly determine that that is input is non-halting as
>>>>>>>>>>>>>>> a pure function of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So my other reply for why your H is not a pure function
>>>>>>>>>>>>>> for any accepted definition of the term.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> In computer programming, a pure function is a function that
>>>>>>>>>>>>> has the following properties:
>>>>>>>>>>>>>
>>>>>>>>>>>>> (1) the function return values are identical for identical
>>>>>>>>>>>>> arguments (no variation with local static variables,
>>>>>>>>>>>>> non-local variables, mutable reference arguments or input
>>>>>>>>>>>>> streams), and
>>>>>>>>>>>>>
>>>>>>>>>>>>> (2) the function application has no side effects (no
>>>>>>>>>>>>> mutation of local static variables, non-local variables,
>>>>>>>>>>>>> mutable reference arguments or input/output streams).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thus a pure function is a computational analogue of a
>>>>>>>>>>>>> mathematical function.
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>>>>>
>>>>>>>>>>>>> The revised H has no:
>>>>>>>>>>>>> (a) local static variables
>>>>>>>>>>>>> (b) non-local variables
>>>>>>>>>>>>> (c) mutable reference arguments
>>>>>>>>>>>>> (d) input streams
>>>>>>>>>>>> Aborting the simulation is a side effect; pure functions do
>>>>>>>>>>>> not have side effects.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> You have a reading comprehension problem.
>>>>>>>>>>> If H does not have (a)(b)(c)(d) then
>>>>>>>>>>> H has no mutation side effect to (a)(b)(c)(d)
>>>>>>>>>>
>>>>>>>>>> Not at all, but you do seem to have that problem.
>>>>>>>>>>
>>>>>>>>>> Again:
>>>>>>>>>>
>>>>>>>>>> Aborting the simulation is a side effect; pure functions do
>>>>>>>>>> not have side effects.
>>>>>>>>>
>>>>>>>>> Whether or not it is construed as a side-effect does not matter
>>>>>>>>> it must be a mutation side-effect to (a)(b)(c)(d) or it does
>>>>>>>>> not count.
>>>>>>>>
>>>>>>>> It doesn't count according to who?
>>>>>>>
>>>>>>> The above definition of pure functions.
>>>>>>
>>>>>> "In computer science, an operation, function or expression is said
>>>>>> to have a side effect if it modifies some state variable value(s)
>>>>>> outside its local environment,
>>>>>
>>>>> The second part is an inaccurate paraphrase of the first part.
>>>>>> which is to say if it has any observable effect
>>>>>> other than its primary effect of returning a value to the invoker
>>>>>> of the operation." --
>>>>>> https://en.wikipedia.org/wiki/Side_effect_(computer_science)
>>>>>>
>>>>>> "any observable effect"
>>>>>>
>>>>>> Aborting the simulation instead of returning a value to the
>>>>>> invoker disqualifies it from being a pure function.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>      if (H(x, x))
>>>>>        HERE: goto HERE;
>>>>>      return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>      Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01)  55              push ebp
>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001358](01)  50              push eax      // push P
>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [0000135c](01)  51              push ecx      // push P
>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>> [00001362](03)  83c408          add esp,+08
>>>>> [00001365](02)  85c0            test eax,eax
>>>>> [00001367](02)  7402            jz 0000136b
>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>> [0000136b](01)  5d              pop ebp
>>>>> [0000136c](01)  c3              ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> H aborts its x86 emulation of P as soon P reaches its machine
>>>>> address of [0000135d] the very first time before the code at this
>>>>> address is emulated. Then H returns 0 to its caller: main().
>>>>
>>>> Returning to main() is not returning to its invoker, P.
>>>>
>>>> Again:
>>>>
>>>> Aborting the simulation is a side effect; pure functions do not have
>>>> side effects.
>>>>
>>>> /Flibble
>>>
>>> Do you have ADD?
>>>
>>> int main()
>>> {
>>>      Output("Input_Halts = ", H(P, P));
>>> }
>> I might be on the spectrum; probably got Asperger's; whilst as far as
>> the topic under discussion is concerned, you've got nothing.
>>
>> /Flibble
>>
>
> Then that may explain why you didn't notice that main calls H(P,P);
> When H returns to its caller it must return to main().
>
> main() and not P is the invoker of H(P,P).
>
>
>

On 6/17/22 12:59 PM, olcott wrote:
> On 6/17/2022 11:51 AM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 11:38:29 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/17/2022 11:36 AM, Mr Flibble wrote:
>>>> On Fri, 17 Jun 2022 11:33:22 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 6/17/2022 11:22 AM, Mr Flibble wrote:
>>>>>> On Fri, 17 Jun 2022 11:16:15 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/17/2022 11:14 AM, Mr Flibble wrote:
>>>>>>>> On Fri, 17 Jun 2022 11:12:31 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 6/17/2022 10:56 AM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 17 Jun 2022 10:49:08 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/17/2022 10:37 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 6/17/2022 9:56 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 17 Jun 2022 09:51:07 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 6/17/2022 9:39 AM, wij wrote:
>>>>>>>>>>>>>>>> On Friday, 17 June 2022 at 22:19:09 UTC+8, olcott
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> On 6/17/2022 8:39 AM, wij wrote:
>>>>>>>>>>>>>>>>>> On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> When a simulating halt decider rejects all inputs as
>>>>>>>>>>>>>>>>>>> non-halting whenever it correctly detects that its
>>>>>>>>>>>>>>>>>>> correct and complete simulation of its input would
>>>>>>>>>>>>>>>>>>> never reach the final state of this input then all
>>>>>>>>>>>>>>>>>>> [these] inputs (including pathological inputs) are
>>>>>>>>>>>>>>>>>>> decided correctly.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *computation that halts* … the Turing machine will
>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state.
>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages
>>>>>>>>>>>>>>>>>>> and Automata. Lexington/Toronto: D. C. Heath and
>>>>>>>>>>>>>>>>>>> Company. (317-320)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (1) It is an easily verified fact that when we assume
>>>>>>>>>>>>>>>>>>> that H is only an x86 emulator that the correctly
>>>>>>>>>>>>>>>>>>> emulated P never reaches its "ret" instruction it
>>>>>>>>>>>>>>>>>>> remains stuck in repeated cycles of emulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (2) It is an easily verified fact that if H has been
>>>>>>>>>>>>>>>>>>> adapted to correctly detect (in a finite number of
>>>>>>>>>>>>>>>>>>> steps) that the correct and complete x86 emulation of
>>>>>>>>>>>>>>>>>>> its input would never each its "ret" instruction that
>>>>>>>>>>>>>>>>>>> H could abort its emulation and return 0 to report
>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (3) When the halt status criteria is defined as
>>>>>>>>>>>>>>>>>>> correctly determining whether or not an x86 emulated
>>>>>>>>>>>>>>>>>>> input would ever reach its "ret" instruction then it
>>>>>>>>>>>>>>>>>>> becomes an easily verified fact H(P,P) could
>>>>>>>>>>>>>>>>>>> correctly reject its input as non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Correct deductive inference proves that all of these
>>>>>>>>>>>>>>>>>>> things are true without any need what-so-ever to see
>>>>>>>>>>>>>>>>>>> either the source-code or the execution trace of H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The one thing that is not proved is whether or not an
>>>>>>>>>>>>>>>>>>> actual encoded H(P,P) does indeed correctly determine
>>>>>>>>>>>>>>>>>>> that its input would never reach its "ret"
>>>>>>>>>>>>>>>>>>> instruction as a pure function of its inputs. This
>>>>>>>>>>>>>>>>>>> aspect will be confirmed by fully operational
>>>>>>>>>>>>>>>>>>> source-code.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> GUR already suggested such a halting decider H cannot
>>>>>>>>>>>>>>>>>> exist:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H(P,P)==0 means P(P) does not halt.
>>>>>>>>>>>>>>>>> That is a misconception.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Halt deciders must compute the mapping from their
>>>>>>>>>>>>>>>>> inputs to an accept or reject state on the basis of
>>>>>>>>>>>>>>>>> the actual behavior actually specified by these inputs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>> would never reach its "ret" instruction thus
>>>>>>>>>>>>>>>>> conclusively proving that it never halts.
>>>>>>>>>>>>>>>>>> H(P,P)==1 means P(P) halts.
>>>>>>>>>>>>>>>>>> H(P,P)==Otherwise means H fails as a decider
>>>>>>>>>>>>>>>>>> (undecidable).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>> Thanks to PO's years' tireless efforts demonstrated
>>>>>>>>>>>>>>>>>> even himself a genius in 10000-years cannot refute my
>>>>>>>>>>>>>>>>>> GUR. ...
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> GUR suggests no halting decider can exist. You just
>>>>>>>>>>>>>>>> confirms it by not able to provide POOH to test/review.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It took me six months to figure out how to transform
>>>>>>>>>>>>>>> H(P,P) into a pure function of its inputs. I did not
>>>>>>>>>>>>>>> release the code before because I knew that its use of
>>>>>>>>>>>>>>> static local data would have been rejected. With this
>>>>>>>>>>>>>>> update to H I will be able to publish the code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H recognizes that P is calling itself with its same
>>>>>>>>>>>>>>> arguments that it was called with and there are no
>>>>>>>>>>>>>>> instructions preceding this call that could possibly
>>>>>>>>>>>>>>> escape infinitely recursive emulation so H aborts its
>>>>>>>>>>>>>>> emulation of P before P even makes its first call to H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Without even looking at the code competent software
>>>>>>>>>>>>>>> engineers will be able to verify that the above H would
>>>>>>>>>>>>>>> correctly determine that that is input is non-halting as
>>>>>>>>>>>>>>> a pure function of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So my other reply for why your H is not a pure function
>>>>>>>>>>>>>> for any accepted definition of the term.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> In computer programming, a pure function is a function that
>>>>>>>>>>>>> has the following properties:
>>>>>>>>>>>>>
>>>>>>>>>>>>> (1) the function return values are identical for identical
>>>>>>>>>>>>> arguments (no variation with local static variables,
>>>>>>>>>>>>> non-local variables, mutable reference arguments or input
>>>>>>>>>>>>> streams), and
>>>>>>>>>>>>>
>>>>>>>>>>>>> (2) the function application has no side effects (no
>>>>>>>>>>>>> mutation of local static variables, non-local variables,
>>>>>>>>>>>>> mutable reference arguments or input/output streams).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thus a pure function is a computational analogue of a
>>>>>>>>>>>>> mathematical function.
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>>>>>
>>>>>>>>>>>>> The revised H has no:
>>>>>>>>>>>>> (a) local static variables
>>>>>>>>>>>>> (b) non-local variables
>>>>>>>>>>>>> (c) mutable reference arguments
>>>>>>>>>>>>> (d) input streams
>>>>>>>>>>>> Aborting the simulation is a side effect; pure functions do
>>>>>>>>>>>> not have side effects.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> You have a reading comprehension problem.
>>>>>>>>>>> If H does not have (a)(b)(c)(d) then
>>>>>>>>>>> H has no mutation side effect to (a)(b)(c)(d)
>>>>>>>>>>
>>>>>>>>>> Not at all, but you do seem to have that problem.
>>>>>>>>>>
>>>>>>>>>> Again:
>>>>>>>>>>
>>>>>>>>>> Aborting the simulation is a side effect; pure functions do
>>>>>>>>>> not have side effects.
>>>>>>>>>
>>>>>>>>> Whether or not it is construed as a side-effect does not matter
>>>>>>>>> it must be a mutation side-effect to (a)(b)(c)(d) or it does
>>>>>>>>> not count.
>>>>>>>>
>>>>>>>> It doesn't count according to who?
>>>>>>>
>>>>>>> The above definition of pure functions.
>>>>>>
>>>>>> "In computer science, an operation, function or expression is said
>>>>>> to have a side effect if it modifies some state variable value(s)
>>>>>> outside its local environment,
>>>>>
>>>>> The second part is an inaccurate paraphrase of the first part.
>>>>>> which is to say if it has any observable effect
>>>>>> other than its primary effect of returning a value to the invoker
>>>>>> of the operation." --
>>>>>> https://en.wikipedia.org/wiki/Side_effect_(computer_science)
>>>>>>
>>>>>> "any observable effect"
>>>>>>
>>>>>> Aborting the simulation instead of returning a value to the
>>>>>> invoker disqualifies it from being a pure function.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>      if (H(x, x))
>>>>>        HERE: goto HERE;
>>>>>      return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>      Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01)  55              push ebp
>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001358](01)  50              push eax      // push P
>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [0000135c](01)  51              push ecx      // push P
>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>> [00001362](03)  83c408          add esp,+08
>>>>> [00001365](02)  85c0            test eax,eax
>>>>> [00001367](02)  7402            jz 0000136b
>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>> [0000136b](01)  5d              pop ebp
>>>>> [0000136c](01)  c3              ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> H aborts its x86 emulation of P as soon P reaches its machine
>>>>> address of [0000135d] the very first time before the code at this
>>>>> address is emulated. Then H returns 0 to its caller: main().
>>>>
>>>> Returning to main() is not returning to its invoker, P.
>>>>
>>>> Again:
>>>>
>>>> Aborting the simulation is a side effect; pure functions do not have
>>>> side effects.
>>>>
>>>> /Flibble
>>>
>>> Do you have ADD?
>>>
>>> int main()
>>> {
>>>      Output("Input_Halts = ", H(P, P));
>>> }
>> If your claim is that H is only called once and the second time an
>> *attempt* to call H is prevented than that is equivalent to calling H
>> and having H do something different with side effects. This is just my
>> opinion though as it requires more thought and I am currently getting
>> drunk on gin and tonics.
>>
>> /Flibble
>>
>
> It is obviously the exact same pattern as infinite recursion
> (a) calling the same function a second time with the same arguments and
>
> (b) there are no instructions preceding this call that could possibly
> escape the infinite recursion / infinitely recursive emulation.
>

On 6/17/22 1:13 PM, olcott wrote:
> On 6/17/2022 12:04 PM, Mr Flibble wrote:
>> Agree but refusing to analyse what P would have done if H wasn't a
>> simulating decider still makes what you've got worthless as far as the
>> Halting Problem is concerned.
>>
>> /Flibble (getting drunk, possibly not quite at Ballmer's Peak)
>>
>
> It is dead obvious to everyone (even Richard) that what P would have
> done if H was merely an x86 emulator and not a halt deciding emulator.
>
> The correct and complete x86 emulation of H(P,P) would never reach its
> "ret" instruction thus making H a correct "not reach ret" / halt decider
> for P.
>
>

Right, but H ISN'T just a pure emulator, so what the pure emulator would
have done doesn't matter.

Just like the fact your cat would bark if it was a dog doesn't matter if
we ask if your actual cat barks.

You are confusing two distinct things because of your confusing
notations. It almost seems deliberate.

On 6/17/22 2:59 PM, olcott wrote:
> On 6/17/2022 1:08 PM, Mr Flibble wrote:
>> On Fri, 17 Jun 2022 19:04:51 +0100
>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>
>>> On Fri, 17 Jun 2022 18:14:48 +0100
>>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>>
>>>> On Fri, 17 Jun 2022 12:13:13 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 6/17/2022 12:04 PM, Mr Flibble wrote:
>>>>>> On Fri, 17 Jun 2022 11:59:53 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/17/2022 11:51 AM, Mr Flibble wrote:
>>>>>>>> On Fri, 17 Jun 2022 11:38:29 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 6/17/2022 11:36 AM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 17 Jun 2022 11:33:22 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/17/2022 11:22 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 17 Jun 2022 11:16:15 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 6/17/2022 11:14 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 17 Jun 2022 11:12:31 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 6/17/2022 10:56 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:49:08 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>> On 6/17/2022 10:37 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>> On 6/17/2022 9:56 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 09:51:07 -0500
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/17/2022 9:39 AM, wij wrote:
>>>>>>>>>>>>>>>>>>>>>> On Friday, 17 June 2022 at 22:19:09 UTC+8,
>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/17/2022 8:39 AM, wij wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Friday, 17 June 2022 at 19:29:37 UTC+8,
>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> When a simulating halt decider rejects all
>>>>>>>>>>>>>>>>>>>>>>>>> inputs as non-halting whenever it correctly
>>>>>>>>>>>>>>>>>>>>>>>>> detects that its correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>> simulation of its input would never reach the
>>>>>>>>>>>>>>>>>>>>>>>>> final state of this input then all [these]
>>>>>>>>>>>>>>>>>>>>>>>>> inputs (including pathological inputs) are
>>>>>>>>>>>>>>>>>>>>>>>>> decided correctly.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> *computation that halts* … the Turing machine
>>>>>>>>>>>>>>>>>>>>>>>>> will halt whenever it enters a final state.
>>>>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal
>>>>>>>>>>>>>>>>>>>>>>>>> Languages and Automata. Lexington/Toronto: D.
>>>>>>>>>>>>>>>>>>>>>>>>> C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>>>>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 //
>>>>>>>>>>>>>>>>>>>>>>>>> call H [00001362](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>>>>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> (1) It is an easily verified fact that when
>>>>>>>>>>>>>>>>>>>>>>>>> we assume that H is only an x86 emulator
>>>>>>>>>>>>>>>>>>>>>>>>> that the correctly emulated P never reaches
>>>>>>>>>>>>>>>>>>>>>>>>> its "ret" instruction it remains stuck in
>>>>>>>>>>>>>>>>>>>>>>>>> repeated cycles of emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> (2) It is an easily verified fact that if H
>>>>>>>>>>>>>>>>>>>>>>>>> has been adapted to correctly detect (in a
>>>>>>>>>>>>>>>>>>>>>>>>> finite number of steps) that the correct and
>>>>>>>>>>>>>>>>>>>>>>>>> complete x86 emulation of its input would
>>>>>>>>>>>>>>>>>>>>>>>>> never each its "ret" instruction that H
>>>>>>>>>>>>>>>>>>>>>>>>> could abort its emulation and return 0 to
>>>>>>>>>>>>>>>>>>>>>>>>> report this.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> (3) When the halt status criteria is defined
>>>>>>>>>>>>>>>>>>>>>>>>> as correctly determining whether or not an
>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulated input would ever reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>> instruction then it becomes an easily
>>>>>>>>>>>>>>>>>>>>>>>>> verified fact H(P,P) could correctly reject
>>>>>>>>>>>>>>>>>>>>>>>>> its input as non-halting.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Correct deductive inference proves that all
>>>>>>>>>>>>>>>>>>>>>>>>> of these things are true without any need
>>>>>>>>>>>>>>>>>>>>>>>>> what-so-ever to see either the source-code or
>>>>>>>>>>>>>>>>>>>>>>>>> the execution trace of H.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The one thing that is not proved is whether
>>>>>>>>>>>>>>>>>>>>>>>>> or not an actual encoded H(P,P) does indeed
>>>>>>>>>>>>>>>>>>>>>>>>> correctly determine that its input would
>>>>>>>>>>>>>>>>>>>>>>>>> never reach its "ret" instruction as a pure
>>>>>>>>>>>>>>>>>>>>>>>>> function of its inputs. This aspect will be
>>>>>>>>>>>>>>>>>>>>>>>>> confirmed by fully operational source-code.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely
>>>>>>>>>>>>>>>>>>>>>>>>> nested simulation (V5)
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> GUR already suggested such a halting decider H
>>>>>>>>>>>>>>>>>>>>>>>> cannot exist:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==0 means P(P) does not halt.
>>>>>>>>>>>>>>>>>>>>>>> That is a misconception.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Halt deciders must compute the mapping from
>>>>>>>>>>>>>>>>>>>>>>> their inputs to an accept or reject state on
>>>>>>>>>>>>>>>>>>>>>>> the basis of the actual behavior actually
>>>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct
>>>>>>>>>>>>>>>>>>>>>>> and complete x86 emulation of the input to
>>>>>>>>>>>>>>>>>>>>>>> H(P,P) by H would never reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>> instruction thus conclusively proving that it
>>>>>>>>>>>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==1 means P(P) halts.
>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==Otherwise means H fails as a decider
>>>>>>>>>>>>>>>>>>>>>>>> (undecidable).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>>>>>>>> Thanks to PO's years' tireless efforts
>>>>>>>>>>>>>>>>>>>>>>>> demonstrated even himself a genius in
>>>>>>>>>>>>>>>>>>>>>>>> 10000-years cannot refute my GUR. ...
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> "Talent hits a target no one else can hit;
>>>>>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see."
>>>>>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> GUR suggests no halting decider can exist. You
>>>>>>>>>>>>>>>>>>>>>> just confirms it by not able to provide POOH to
>>>>>>>>>>>>>>>>>>>>>> test/review.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It took me six months to figure out how to
>>>>>>>>>>>>>>>>>>>>> transform H(P,P) into a pure function of its
>>>>>>>>>>>>>>>>>>>>> inputs. I did not release the code before because
>>>>>>>>>>>>>>>>>>>>> I knew that its use of static local data would
>>>>>>>>>>>>>>>>>>>>> have been rejected. With this update to H I will
>>>>>>>>>>>>>>>>>>>>> be able to publish the code.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H recognizes that P is calling itself with its
>>>>>>>>>>>>>>>>>>>>> same arguments that it was called with and there
>>>>>>>>>>>>>>>>>>>>> are no instructions preceding this call that
>>>>>>>>>>>>>>>>>>>>> could possibly escape infinitely recursive
>>>>>>>>>>>>>>>>>>>>> emulation so H aborts its emulation of P before
>>>>>>>>>>>>>>>>>>>>> P even makes its first call to H.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Without even looking at the code competent
>>>>>>>>>>>>>>>>>>>>> software engineers will be able to verify that
>>>>>>>>>>>>>>>>>>>>> the above H would correctly determine that that
>>>>>>>>>>>>>>>>>>>>> is input is non-halting as a pure function of
>>>>>>>>>>>>>>>>>>>>> this input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So my other reply for why your H is not a pure
>>>>>>>>>>>>>>>>>>>> function for any accepted definition of the term.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In computer programming, a pure function is a
>>>>>>>>>>>>>>>>>>> function that has the following properties:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (1) the function return values are identical for
>>>>>>>>>>>>>>>>>>> identical arguments (no variation with local static
>>>>>>>>>>>>>>>>>>> variables, non-local variables, mutable reference
>>>>>>>>>>>>>>>>>>> arguments or input streams), and
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (2) the function application has no side effects
>>>>>>>>>>>>>>>>>>> (no mutation of local static variables, non-local
>>>>>>>>>>>>>>>>>>> variables, mutable reference arguments or
>>>>>>>>>>>>>>>>>>> input/output streams).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thus a pure function is a computational analogue
>>>>>>>>>>>>>>>>>>> of a mathematical function.
>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Pure_function
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The revised H has no:
>>>>>>>>>>>>>>>>>>> (a) local static variables
>>>>>>>>>>>>>>>>>>> (b) non-local variables
>>>>>>>>>>>>>>>>>>> (c) mutable reference arguments
>>>>>>>>>>>>>>>>>>> (d) input streams
>>>>>>>>>>>>>>>>>> Aborting the simulation is a side effect; pure
>>>>>>>>>>>>>>>>>> functions do not have side effects.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You have a reading comprehension problem.
>>>>>>>>>>>>>>>>> If H does not have (a)(b)(c)(d) then
>>>>>>>>>>>>>>>>> H has no mutation side effect to (a)(b)(c)(d)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not at all, but you do seem to have that problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Again:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Aborting the simulation is a side effect; pure
>>>>>>>>>>>>>>>> functions do not have side effects.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Whether or not it is construed as a side-effect does
>>>>>>>>>>>>>>> not matter it must be a mutation side-effect to
>>>>>>>>>>>>>>> (a)(b)(c)(d) or it does not count.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It doesn't count according to who?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The above definition of pure functions.
>>>>>>>>>>>>
>>>>>>>>>>>> "In computer science, an operation, function or expression
>>>>>>>>>>>> is said to have a side effect if it modifies some state
>>>>>>>>>>>> variable value(s) outside its local environment,
>>>>>>>>>>>
>>>>>>>>>>> The second part is an inaccurate paraphrase of the first
>>>>>>>>>>> part.
>>>>>>>>>>>> which is to say if it has any observable effect
>>>>>>>>>>>> other than its primary effect of returning a value to the
>>>>>>>>>>>> invoker of the operation." --
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Side_effect_(computer_science)
>>>>>>>>>>>>
>>>>>>>>>>>> "any observable effect"
>>>>>>>>>>>>
>>>>>>>>>>>> Aborting the simulation instead of returning a value to
>>>>>>>>>>>> the invoker disqualifies it from being a pure function.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>        if (H(x, x))
>>>>>>>>>>>          HERE: goto HERE;
>>>>>>>>>>>        return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>        Output("Input_Halts = ", H(P, P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [00001352](01)  55              push ebp
>>>>>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>> [00001358](01)  50              push eax      // push P
>>>>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>>>>>> [0000136c](01)  c3              ret
>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>
>>>>>>>>>>> H aborts its x86 emulation of P as soon P reaches its
>>>>>>>>>>> machine address of [0000135d] the very first time before
>>>>>>>>>>> the code at this address is emulated. Then H returns 0 to
>>>>>>>>>>> its caller: main().
>>>>>>>>>>
>>>>>>>>>> Returning to main() is not returning to its invoker, P.
>>>>>>>>>>
>>>>>>>>>> Again:
>>>>>>>>>>
>>>>>>>>>> Aborting the simulation is a side effect; pure functions do
>>>>>>>>>> not have side effects.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Do you have ADD?
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>        Output("Input_Halts = ", H(P, P));
>>>>>>>>> }
>>>>>>>> If your claim is that H is only called once and the second
>>>>>>>> time an *attempt* to call H is prevented than that is
>>>>>>>> equivalent to calling H and having H do something different
>>>>>>>> with side effects. This is just my opinion though as it
>>>>>>>> requires more thought and I am currently getting drunk on gin
>>>>>>>> and tonics.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> It is obviously the exact same pattern as infinite recursion
>>>>>>> (a) calling the same function a second time with the same
>>>>>>> arguments and
>>>>>>>
>>>>>>> (b) there are no instructions preceding this call that could
>>>>>>> possibly escape the infinite recursion / infinitely recursive
>>>>>>> emulation.
>>>>>> Agree but refusing to analyse what P would have done if H
>>>>>> wasn't a simulating decider still makes what you've got
>>>>>> worthless as far as the Halting Problem is concerned.
>>>>>>
>>>>>> /Flibble (getting drunk, possibly not quite at Ballmer's Peak)
>>>>>
>>>>> It is dead obvious to everyone (even Richard) that what P would
>>>>> have done if H was merely an x86 emulator and not a halt deciding
>>>>> emulator.
>>>>>
>>>>> The correct and complete x86 emulation of H(P,P) would never reach
>>>>> its "ret" instruction thus making H a correct "not reach ret" /
>>>>> halt decider for P.
>>>>
>>>> You need to think about a P that calls H but is non-pathological
>>>> halting (no infinite loop).
>>>
>>> Your assumption that any program that calls H is also pathological is
>>> a flawed one.  I have said before that all you have is a simulation
>>> detector and not a halt decider: simulating halt deciders cannot
>>> decide non-pathological non-halting programs in finite time so are not
>>> actually deciders.
>>
>> The question then becomes is a simulation detector (rather than a halt
>> decider) sufficient to refute proofs based on the [Strachey 1965]
>> impossible program?  I cannot answer that question as I am unfamiliar
>> with the proofs.
>>
>> /Flibble
>>
>
> [Strachey 1965] is merely P that takes no arguments and H that takes one
> argument.
>
> void P0()
> {
>   if (H0((u32)P0))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0((u32)P0));
> }
>
> _P0()
> [00001396](01)  55              push ebp
> [00001397](02)  8bec            mov ebp,esp
> [00001399](05)  6896130000      push 00001396
> [0000139e](05)  e813fdffff      call 000010b6
> [000013a3](03)  83c404          add esp,+04
> [000013a6](02)  85c0            test eax,eax
> [000013a8](02)  7402            jz 000013ac
> [000013aa](02)  ebfe            jmp 000013aa
> [000013ac](01)  5d              pop ebp
> [000013ad](01)  c3              ret
> Size in bytes:(0024) [000013ad]
>
> _main()
> [000013b6](01)  55              push ebp
> [000013b7](02)  8bec            mov ebp,esp
> [000013b9](05)  6896130000      push 00001396
> [000013be](05)  e8f3fcffff      call 000010b6
> [000013c3](03)  83c404          add esp,+04
> [000013c6](01)  50              push eax
> [000013c7](05)  6827040000      push 00000427
> [000013cc](05)  e8a5f0ffff      call 00000476
> [000013d1](03)  83c408          add esp,+08
> [000013d4](02)  33c0            xor eax,eax
> [000013d6](01)  5d              pop ebp
> [000013d7](01)  c3              ret
> Size in bytes:(0034) [000013d7]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> ...[000013b6][0010230c][00000000] 55              push ebp
> ...[000013b7][0010230c][00000000] 8bec            mov ebp,esp
> ...[000013b9][00102308][00001396] 6896130000      push 00001396
> ...[000013be][00102304][000013c3] e8f3fcffff      call 000010b6
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:2123c0
> ...[00001396][002123b0][002123b4] 55              push ebp
> ...[00001397][002123b0][002123b4] 8bec            mov ebp,esp
> ...[00001399][002123ac][00001396] 6896130000      push 00001396
> ...[0000139e][002123a8][000013a3] e813fdffff      call 000010b6
> ...[00001396][0025cdd8][0025cddc] 55              push ebp
> ...[00001397][0025cdd8][0025cddc] 8bec            mov ebp,esp
> ...[00001399][0025cdd4][00001396] 6896130000      push 00001396
> ...[0000139e][0025cdd0][000013a3] e813fdffff      call 000010b6
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> ...[000013c3][0010230c][00000000] 83c404          add esp,+04
> ...[000013c6][00102308][00000000] 50              push eax
> ...[000013c7][00102304][00000427] 6827040000      push 00000427
> ---[000013cc][00102304][00000427] e8a5f0ffff      call 00000476
> Input_Halts = 0
> ...[000013d1][0010230c][00000000] 83c408          add esp,+08
> ...[000013d4][0010230c][00000000] 33c0            xor eax,eax
> ...[000013d6][00102310][00100000] 5d              pop ebp
> ...[000013d7][00102314][00000004] c3              ret
> Number of Instructions Executed(11031)
>
>

On 6/17/22 2:45 PM, olcott wrote:

> I already proved that they do many dozen of times.
> The reason that I stopped talking to Richard is that he could not
> remember from one post to the next what I said in the preceding post.
>

LIE.

And you know it.

You think that just because I don't accept your fabrications that I
don't remember it.

Anyone with even a little bit of a brain can tell who is using logic and
who is just repeating lies.

The fact that you can't shows how much brain you are using.

On 6/17/22 11:45 AM, olcott wrote:
> On 6/17/2022 10:06 AM, wij wrote:
>> On Friday, 17 June 2022 at 22:51:15 UTC+8, olcott wrote:
>>> It took me six months to figure out how to transform H(P,P) into a pure
>>> function of its inputs. I did not release the code before because I knew
>>> that its use of static local data would have been rejected. With this
>>> update to H I will be able to publish the code.
>>> H recognizes that P is calling itself with its same arguments that it
>>> was called with and there are no instructions preceding this call that
>>> could possibly escape infinitely recursive emulation so H aborts its
>>> emulation of P before P even makes its first call to H.
>>> Without even looking at the code competent software engineers will be
>>> able to verify that the above H would correctly determine that that is
>>> input is non-halting as a pure function of this 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
>>
>> What you say is irrelevant.
>> Reviewers investigate the 'H', an algorithm that a computer can execute,
>> not Peter Olcltt's Oral Halting decider.
>>
>
> H knows its own machine address and on this basis
> H recognizes that P is calling itself with its same arguments that it
> was called with and there are no instructions preceding this call that
> could possibly escape infinitely recursive emulation so H aborts its
> emulation of P before P even makes its first call to H.
>
> Every competent software engineer can verify that H(P,P)==0 as a pure
> function of its inputs according the the above algorithm.
>
>> The irrefutable fact is clear: GUR cannot be violated, you don't have a
>> real POOH for test/review.
>
>

H may be a pure function, but not a correct emulator/decider.

Note, the pattern H(P,P) conditionally emulating P(P) which calls H(P,P)

is NOT a infinite behavior pattern.

This has been proven.

IF H's emulation is correct, including the deduction of infinite
behavior, then H is NOT a pure function.

On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects that its correct and complete simulation
> of its input would never reach the final state of this input then all
> [these] inputs (including pathological inputs) are decided correctly.
>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> void P(ptr x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> (1) It is an easily verified fact that when we assume that H is only an
> x86 emulator that the correctly emulated P never reaches its "ret"
> instruction it remains stuck in repeated cycles of emulation.
>
Yes.
>
> (2) It is an easily verified fact that if H has been adapted to
> correctly detect (in a finite number of steps) that the correct and
> complete x86 emulation of its input would never each its "ret"
> instruction that H could abort its emulation and return 0 to report this.
>
Yes.
>
> (3) When the halt status criteria is defined as correctly determining
> whether or not an x86 emulated input would ever reach its "ret"
> instruction then it becomes an easily verified fact H(P,P) could
> correctly reject its input as non-halting.
>
No. Because by changing H from emulator to halt decider, you have changed
P.

On 2022-06-17 14:33:32 +0000, olcott said:

> THIS IS IRREFUTABLE BECAUSE IT IS A TAUTOLOGY:
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects that its correct and complete
> simulation of its input would never reach the final state of this
> input then all [these] inputs (including pathological inputs) are
> decided correctly.

One should not use "whenever" in a when-clause. In the beginnig
of the above "If" would be better than "When".

Another tautology is that the above tautology is irrelevant except
when a correct and complete simulation of its input would never reach
a final state of this input.

Note that "the" final state is incorrect: any state that is not
folowed by another state is a final state, and a computation halts
if it reaches one of its final states.

Mikko

On 6/18/2022 4:09 AM, Malcolm McLean wrote:
> On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
>> When a simulating halt decider rejects all inputs as non-halting
>> whenever it correctly detects that its correct and complete simulation
>> of its input would never reach the final state of this input then all
>> [these] inputs (including pathological inputs) are decided correctly.
>>
>> *computation that halts* … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> void P(ptr x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax // push P
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx // push P
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> (1) It is an easily verified fact that when we assume that H is only an
>> x86 emulator that the correctly emulated P never reaches its "ret"
>> instruction it remains stuck in repeated cycles of emulation.
>>
> Yes.
>>
>> (2) It is an easily verified fact that if H has been adapted to
>> correctly detect (in a finite number of steps) that the correct and
>> complete x86 emulation of its input would never each its "ret"
>> instruction that H could abort its emulation and return 0 to report this.
>>
> Yes.
>>
>> (3) When the halt status criteria is defined as correctly determining
>> whether or not an x86 emulated input would ever reach its "ret"
>> instruction then it becomes an easily verified fact H(P,P) could
>> correctly reject its input as non-halting.
>>
> No. Because by changing H from emulator to halt decider, you have changed
> P.

When H(P,P) correctly determines that P would never reach its "ret"
instruction (AKA final state) this makes H a halt decider for this input
by definition:

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

--
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 6/18/2022 5:20 AM, Mikko wrote:
> On 2022-06-17 14:33:32 +0000, olcott said:
>
>> THIS IS IRREFUTABLE BECAUSE IT IS A TAUTOLOGY:
>> When a simulating halt decider rejects all inputs as non-halting
>> whenever it correctly detects that its correct and complete
>> simulation of its input would never reach the final state of this
>> input then all [these] inputs (including pathological inputs) are
>> decided correctly.
>
> One should not use "whenever" in a when-clause. In the beginnig
> of the above "If" would be better than "When".
>

Yes you are probably correct. The above words are a little clumsy.

> Another tautology is that the above tautology is irrelevant except
> when a correct and complete simulation of its input would never reach
> a final state of this input.
>

That is the same as saying all non-halting inputs.

> Note that "the" final state is incorrect: any state that is not
> folowed by another state is a final state, and a computation halts
> if it reaches one of its final states.
>
> Mikko
>

Yes you are technically correct that a computation can have more than
one final state. None of my test cases have more than one. I changed
"the" to "a".

--
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 Saturday, 18 June 2022 at 20:07:56 UTC+8, olcott wrote:
> On 6/18/2022 4:09 AM, Malcolm McLean wrote:
> > On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
> >> When a simulating halt decider rejects all inputs as non-halting
> >> whenever it correctly detects that its correct and complete simulation
> >> of its input would never reach the final state of this input then all
> >> [these] inputs (including pathological inputs) are decided correctly.
> >>
> >> *computation that halts* … the Turing machine will halt whenever it
> >> enters a final state. (Linz:1990:234)
> >>
> >> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> >> Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>
> >> #include <stdint.h>
> >> typedef void (*ptr)();
> >>
> >> void P(ptr x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H(P, P));
> >> }
> >>
> >> _P()
> >> [00001352](01) 55 push ebp
> >> [00001353](02) 8bec mov ebp,esp
> >> [00001355](03) 8b4508 mov eax,[ebp+08]
> >> [00001358](01) 50 push eax // push P
> >> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >> [0000135c](01) 51 push ecx // push P
> >> [0000135d](05) e840feffff call 000011a2 // call H
> >> [00001362](03) 83c408 add esp,+08
> >> [00001365](02) 85c0 test eax,eax
> >> [00001367](02) 7402 jz 0000136b
> >> [00001369](02) ebfe jmp 00001369
> >> [0000136b](01) 5d pop ebp
> >> [0000136c](01) c3 ret
> >> Size in bytes:(0027) [0000136c]
> >>
> >> (1) It is an easily verified fact that when we assume that H is only an
> >> x86 emulator that the correctly emulated P never reaches its "ret"
> >> instruction it remains stuck in repeated cycles of emulation.
> >>
> > Yes.
> >>
> >> (2) It is an easily verified fact that if H has been adapted to
> >> correctly detect (in a finite number of steps) that the correct and
> >> complete x86 emulation of its input would never each its "ret"
> >> instruction that H could abort its emulation and return 0 to report this.
> >>
> > Yes.
> >>
> >> (3) When the halt status criteria is defined as correctly determining
> >> whether or not an x86 emulated input would ever reach its "ret"
> >> instruction then it becomes an easily verified fact H(P,P) could
> >> correctly reject its input as non-halting.
> >>
> > No. Because by changing H from emulator to halt decider, you have changed
> > P.
> When H(P,P) correctly determines that P would never reach its "ret"
> instruction (AKA final state) this makes H a halt decider for this input
> by definition:
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

GUR is repeatedly proved:
olcott can never provide a real halting decider except a verbal one.
Thanks olcott.

On 6/18/2022 7:24 AM, wij wrote:
> On Saturday, 18 June 2022 at 20:07:56 UTC+8, olcott wrote:
>> On 6/18/2022 4:09 AM, Malcolm McLean wrote:
>>> On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
>>>> When a simulating halt decider rejects all inputs as non-halting
>>>> whenever it correctly detects that its correct and complete simulation
>>>> of its input would never reach the final state of this input then all
>>>> [these] inputs (including pathological inputs) are decided correctly.
>>>>
>>>> *computation that halts* … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> void P(ptr x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> _P()
>>>> [00001352](01) 55 push ebp
>>>> [00001353](02) 8bec mov ebp,esp
>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>> [00001358](01) 50 push eax // push P
>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000135c](01) 51 push ecx // push P
>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>> [00001362](03) 83c408 add esp,+08
>>>> [00001365](02) 85c0 test eax,eax
>>>> [00001367](02) 7402 jz 0000136b
>>>> [00001369](02) ebfe jmp 00001369
>>>> [0000136b](01) 5d pop ebp
>>>> [0000136c](01) c3 ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> (1) It is an easily verified fact that when we assume that H is only an
>>>> x86 emulator that the correctly emulated P never reaches its "ret"
>>>> instruction it remains stuck in repeated cycles of emulation.
>>>>
>>> Yes.
>>>>
>>>> (2) It is an easily verified fact that if H has been adapted to
>>>> correctly detect (in a finite number of steps) that the correct and
>>>> complete x86 emulation of its input would never each its "ret"
>>>> instruction that H could abort its emulation and return 0 to report this.
>>>>
>>> Yes.
>>>>
>>>> (3) When the halt status criteria is defined as correctly determining
>>>> whether or not an x86 emulated input would ever reach its "ret"
>>>> instruction then it becomes an easily verified fact H(P,P) could
>>>> correctly reject its input as non-halting.
>>>>
>>> No. Because by changing H from emulator to halt decider, you have changed
>>> P.
>> When H(P,P) correctly determines that P would never reach its "ret"
>> instruction (AKA final state) this makes H a halt decider for this input
>> by definition:
>>
>> computation that halts … the Turing machine will halt whenever it enters
>> a final state. (Linz:1990:234)
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> GUR is repeatedly proved:
> olcott can never provide a real halting decider except a verbal one.
> Thanks olcott.

This one proves that H(P,P) does correctly determine that H(P,P)==0 is
correct:

H(P,P)==0 as a pure function of its inputs is fully operational V2
On 6/17/2022 9:31 PM, olcott wrote:

--
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 Saturday, 18 June 2022 at 20:32:57 UTC+8, olcott wrote:
> >
> > GUR is repeatedly proved:
> > olcott can never provide a real halting decider except a verbal one.
> > Thanks olcott.
> This one proves that H(P,P) does correctly determine that H(P,P)==0 is
> correct:
>
> H(P,P)==0 as a pure function of its inputs is fully operational V2
> On 6/17/2022 9:31 PM, olcott wrote:
>
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

Even blind idiots can see your H has no definition, just a name.
You have no right to ask people worse than you are.

On 6/18/22 8:07 AM, olcott wrote:
> On 6/18/2022 4:09 AM, Malcolm McLean wrote:
>> On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
>>> When a simulating halt decider rejects all inputs as non-halting
>>> whenever it correctly detects that its correct and complete simulation
>>> of its input would never reach the final state of this input then all
>>> [these] inputs (including pathological inputs) are decided correctly.
>>>
>>> *computation that halts* … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> void P(ptr x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> _P()
>>> [00001352](01) 55 push ebp
>>> [00001353](02) 8bec mov ebp,esp
>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>> [00001358](01) 50 push eax // push P
>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>> [0000135c](01) 51 push ecx // push P
>>> [0000135d](05) e840feffff call 000011a2 // call H
>>> [00001362](03) 83c408 add esp,+08
>>> [00001365](02) 85c0 test eax,eax
>>> [00001367](02) 7402 jz 0000136b
>>> [00001369](02) ebfe jmp 00001369
>>> [0000136b](01) 5d pop ebp
>>> [0000136c](01) c3 ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> (1) It is an easily verified fact that when we assume that H is only an
>>> x86 emulator that the correctly emulated P never reaches its "ret"
>>> instruction it remains stuck in repeated cycles of emulation.
>>>
>> Yes.
>>>
>>> (2) It is an easily verified fact that if H has been adapted to
>>> correctly detect (in a finite number of steps) that the correct and
>>> complete x86 emulation of its input would never each its "ret"
>>> instruction that H could abort its emulation and return 0 to report
>>> this.
>>>
>> Yes.
>>>
>>> (3) When the halt status criteria is defined as correctly determining
>>> whether or not an x86 emulated input would ever reach its "ret"
>>> instruction then it becomes an easily verified fact H(P,P) could
>>> correctly reject its input as non-halting.
>>>
>> No. Because by changing H from emulator to halt decider, you have changed
>> P.
>
> When H(P,P) correctly determines that P would never reach its "ret"
> instruction (AKA final state) this makes H a halt decider for this input
> by definition:
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
>

You are missing that H may have determened the correct behavior for *A*
P< the one built on the H that is a pure emulator and never aborts, but
that isn't the P that this H needs to answer about. This H needs to get
right the P that is built on itself, the H that will abort when it sees
this pattern, and that P does reach that final state.

Your fundamental problem seems to be that you think the the "P" you are
deciding on is just the code for the C function with an abstract/fuzzy
definition of the behavior of the H tht it calls, but that isn't the
question, When you look at a Turing Machine, that machine includes ALL
the "code" that machine executes, even "sub-functions" that it uses, so
the code of H (and everything that H uses) is PART of the "input P".

Thus, the x86 assembly representation of the input P isn't just the code
of the function P, as that isn't an actual definition that defines the
behavior in question, but the representation needs to include all the
x86 code of H and everything that H calls.

On 6/18/22 8:32 AM, olcott wrote:
> On 6/18/2022 7:24 AM, wij wrote:
>> On Saturday, 18 June 2022 at 20:07:56 UTC+8, olcott wrote:
>>> On 6/18/2022 4:09 AM, Malcolm McLean wrote:
>>>> On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
>>>>> When a simulating halt decider rejects all inputs as non-halting
>>>>> whenever it correctly detects that its correct and complete simulation
>>>>> of its input would never reach the final state of this input then all
>>>>> [these] inputs (including pathological inputs) are decided correctly.
>>>>>
>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01) 55 push ebp
>>>>> [00001353](02) 8bec mov ebp,esp
>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>> [00001358](01) 50 push eax // push P
>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>> [0000135c](01) 51 push ecx // push P
>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>> [00001362](03) 83c408 add esp,+08
>>>>> [00001365](02) 85c0 test eax,eax
>>>>> [00001367](02) 7402 jz 0000136b
>>>>> [00001369](02) ebfe jmp 00001369
>>>>> [0000136b](01) 5d pop ebp
>>>>> [0000136c](01) c3 ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> (1) It is an easily verified fact that when we assume that H is
>>>>> only an
>>>>> x86 emulator that the correctly emulated P never reaches its "ret"
>>>>> instruction it remains stuck in repeated cycles of emulation.
>>>>>
>>>> Yes.
>>>>>
>>>>> (2) It is an easily verified fact that if H has been adapted to
>>>>> correctly detect (in a finite number of steps) that the correct and
>>>>> complete x86 emulation of its input would never each its "ret"
>>>>> instruction that H could abort its emulation and return 0 to report
>>>>> this.
>>>>>
>>>> Yes.
>>>>>
>>>>> (3) When the halt status criteria is defined as correctly determining
>>>>> whether or not an x86 emulated input would ever reach its "ret"
>>>>> instruction then it becomes an easily verified fact H(P,P) could
>>>>> correctly reject its input as non-halting.
>>>>>
>>>> No. Because by changing H from emulator to halt decider, you have
>>>> changed
>>>> P.
>>> When H(P,P) correctly determines that P would never reach its "ret"
>>> instruction (AKA final state) this makes H a halt decider for this input
>>> by definition:
>>>
>>> computation that halts … the Turing machine will halt whenever it enters
>>> a final state. (Linz:1990:234)
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>>
>> GUR is repeatedly proved:
>>   olcott can never provide a real halting decider except a verbal one.
>> Thanks olcott.
>
> This one proves that H(P,P) does correctly determine that H(P,P)==0 is
> correct:
>
> H(P,P)==0 as a pure function of its inputs is fully operational V2
> On 6/17/2022 9:31 PM, olcott wrote:
>

Except it isn't since H(P,P) returns 0, saying that P(P) is non-halting,
when P(P) will halt when H(P,P) returns 0.

If H(P,P) isn't asking about P(P), then you don't have the right
function P, as the Linz definition of P is that it will ask about that.

On 6/18/2022 7:52 AM, Richard Damon wrote:
> On 6/18/22 8:32 AM, olcott wrote:
>> On 6/18/2022 7:24 AM, wij wrote:
>>> On Saturday, 18 June 2022 at 20:07:56 UTC+8, olcott wrote:
>>>> On 6/18/2022 4:09 AM, Malcolm McLean wrote:
>>>>> On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
>>>>>> When a simulating halt decider rejects all inputs as non-halting
>>>>>> whenever it correctly detects that its correct and complete
>>>>>> simulation
>>>>>> of its input would never reach the final state of this input then all
>>>>>> [these] inputs (including pathological inputs) are decided correctly.
>>>>>>
>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>> enters a final state. (Linz:1990:234)
>>>>>>
>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>
>>>>>> #include <stdint.h>
>>>>>> typedef void (*ptr)();
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>>
>>>>>> _P()
>>>>>> [00001352](01) 55 push ebp
>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>> [00001358](01) 50 push eax // push P
>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>> [0000136b](01) 5d pop ebp
>>>>>> [0000136c](01) c3 ret
>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>
>>>>>> (1) It is an easily verified fact that when we assume that H is
>>>>>> only an
>>>>>> x86 emulator that the correctly emulated P never reaches its "ret"
>>>>>> instruction it remains stuck in repeated cycles of emulation.
>>>>>>
>>>>> Yes.
>>>>>>
>>>>>> (2) It is an easily verified fact that if H has been adapted to
>>>>>> correctly detect (in a finite number of steps) that the correct and
>>>>>> complete x86 emulation of its input would never each its "ret"
>>>>>> instruction that H could abort its emulation and return 0 to
>>>>>> report this.
>>>>>>
>>>>> Yes.
>>>>>>
>>>>>> (3) When the halt status criteria is defined as correctly determining
>>>>>> whether or not an x86 emulated input would ever reach its "ret"
>>>>>> instruction then it becomes an easily verified fact H(P,P) could
>>>>>> correctly reject its input as non-halting.
>>>>>>
>>>>> No. Because by changing H from emulator to halt decider, you have
>>>>> changed
>>>>> P.
>>>> When H(P,P) correctly determines that P would never reach its "ret"
>>>> instruction (AKA final state) this makes H a halt decider for this
>>>> input
>>>> by definition:
>>>>
>>>> computation that halts … the Turing machine will halt whenever it
>>>> enters
>>>> a final state. (Linz:1990:234)
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>> --
>>>> Copyright 2022 Pete Olcott
>>>>
>>>> "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see."
>>>> Arthur Schopenhauer
>>>
>>> GUR is repeatedly proved:
>>>   olcott can never provide a real halting decider except a verbal one.
>>> Thanks olcott.
>>
>> This one proves that H(P,P) does correctly determine that H(P,P)==0 is
>> correct:
>>
>> H(P,P)==0 as a pure function of its inputs is fully operational V2
>> On 6/17/2022 9:31 PM, olcott wrote:
>>
>
> Except it isn't since H(P,P) returns 0, saying that P(P) is non-halting,
> when P(P) will halt when H(P,P) returns 0.
>
> If H(P,P) isn't asking about P(P), then you don't have the right
> function P, as the Linz definition of P is that it will ask about that.

(X) H(P,P) correctly determines (in a finite number of steps) that the
correct and complete x86 emulation of its input would never reach the
"ret" instruction (AKA final state) of this input.

(Y) computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

(Z) H(P,P) has correctly determined that its input is non-halting.

When we know that X & Y proves Z and we know X & Y then Z is proved.
Failing to agree with this last line is sufficient evidence of dishonesty.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

--
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 6/18/22 9:19 AM, olcott wrote:
> On 6/18/2022 7:52 AM, Richard Damon wrote:
>> On 6/18/22 8:32 AM, olcott wrote:
>>> On 6/18/2022 7:24 AM, wij wrote:
>>>> On Saturday, 18 June 2022 at 20:07:56 UTC+8, olcott wrote:
>>>>> On 6/18/2022 4:09 AM, Malcolm McLean wrote:
>>>>>> On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
>>>>>>> When a simulating halt decider rejects all inputs as non-halting
>>>>>>> whenever it correctly detects that its correct and complete
>>>>>>> simulation
>>>>>>> of its input would never reach the final state of this input then
>>>>>>> all
>>>>>>> [these] inputs (including pathological inputs) are decided
>>>>>>> correctly.
>>>>>>>
>>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>
>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>
>>>>>>> #include <stdint.h>
>>>>>>> typedef void (*ptr)();
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [00001352](01) 55 push ebp
>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>> [0000136c](01) c3 ret
>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>
>>>>>>> (1) It is an easily verified fact that when we assume that H is
>>>>>>> only an
>>>>>>> x86 emulator that the correctly emulated P never reaches its "ret"
>>>>>>> instruction it remains stuck in repeated cycles of emulation.
>>>>>>>
>>>>>> Yes.
>>>>>>>
>>>>>>> (2) It is an easily verified fact that if H has been adapted to
>>>>>>> correctly detect (in a finite number of steps) that the correct and
>>>>>>> complete x86 emulation of its input would never each its "ret"
>>>>>>> instruction that H could abort its emulation and return 0 to
>>>>>>> report this.
>>>>>>>
>>>>>> Yes.
>>>>>>>
>>>>>>> (3) When the halt status criteria is defined as correctly
>>>>>>> determining
>>>>>>> whether or not an x86 emulated input would ever reach its "ret"
>>>>>>> instruction then it becomes an easily verified fact H(P,P) could
>>>>>>> correctly reject its input as non-halting.
>>>>>>>
>>>>>> No. Because by changing H from emulator to halt decider, you have
>>>>>> changed
>>>>>> P.
>>>>> When H(P,P) correctly determines that P would never reach its "ret"
>>>>> instruction (AKA final state) this makes H a halt decider for this
>>>>> input
>>>>> by definition:
>>>>>
>>>>> computation that halts … the Turing machine will halt whenever it
>>>>> enters
>>>>> a final state. (Linz:1990:234)
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>> --
>>>>> Copyright 2022 Pete Olcott
>>>>>
>>>>> "Talent hits a target no one else can hit;
>>>>> Genius hits a target no one else can see."
>>>>> Arthur Schopenhauer
>>>>
>>>> GUR is repeatedly proved:
>>>>   olcott can never provide a real halting decider except a verbal one.
>>>> Thanks olcott.
>>>
>>> This one proves that H(P,P) does correctly determine that H(P,P)==0
>>> is correct:
>>>
>>> H(P,P)==0 as a pure function of its inputs is fully operational V2
>>> On 6/17/2022 9:31 PM, olcott wrote:
>>>
>>
>> Except it isn't since H(P,P) returns 0, saying that P(P) is
>> non-halting, when P(P) will halt when H(P,P) returns 0.
>>
>> If H(P,P) isn't asking about P(P), then you don't have the right
>> function P, as the Linz definition of P is that it will ask about that.
>
> (X) H(P,P) correctly determines (in a finite number of steps) that the
> correct and complete x86 emulation of its input would never reach the
> "ret" instruction (AKA final state) of this input.

FALSE. Only proven for all H(P,P) that actually DO a complete x86
emulation of its input, and those can't do it in a finite number of
steps. The H(P,P) that you have proven it for NEVER return 0 from
H(P,P). The H you are now talking about DOES return 0, and thus DOES
abort its simulation and thus DOES NOT actually do a complete x86
emulation of its input, so not applicable here.
>
> (Y) computation that halts … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)

True/

>
> (Z) H(P,P) has correctly determined that its input is non-halting.

Nope, it has correctly determined that A DIFFERENT P/H combination is
non-halting, not itself.

>
> When we know that X & Y proves Z and we know X & Y then Z is proved.
> Failing to agree with this last line is sufficient evidence of dishonesty.
>

So, since you never proved X for the H that you are talking about, you
haven't proved your point.

FAIL.

>
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
>