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

On 6/17/22 7:29 AM, 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
>
>
>

Summary of your error:

At the same time you have assumes that H is a function that only
correctly and completely emulates its input and also that it aborts its
emulation (and thus not be complete) and return the answer.

That is an impossible program, and renders your logic totally invalid.

It is like assuming that the night was so dark you couldn't see the hand
in front of your face, but you could also, at exactly the same time, be
seen from a mile ways because things were so clear and light.

You are just embarassing yourself, you just seem to be too dumb to
notice it.

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

On Fri, 17 Jun 2022 06:29:29 -0500
olcott <NoOne@NoWhere.com> 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

You can keep repeating yourself as many times as you like but that
won't make you correct:

(1) you assert H is a pure function so it must ALWAYS return the
SAME RESULT for the SAME ARGUMENTS with NO SIDE EFFECTS (aborting a
simulation is a side effect);
(2) you assert H(P,P) == 0;
(3) given (1) and (2) P must halt as H should return 0 to P's
invocation of H but it doesn't because it is either a different H or an
erroneous H;
(4) given (1), (2) and (3) H is not a halt decider; it is an incredibly
useless olcott simulation detector.

/Flibble

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

On 6/17/2022 9:11 AM, Mr Flibble wrote:
> On Fri, 17 Jun 2022 06:29:29 -0500
> olcott <NoOne@NoWhere.com> wrote:
>

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.

>>
>> *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
>
> You can keep repeating yourself as many times as you like but that
> won't make you correct:
>
> (1) you assert H is a pure function so it must ALWAYS return the
> SAME RESULT for the SAME ARGUMENTS with NO SIDE EFFECTS (aborting a
> simulation is a side effect);

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.

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

> (2) you assert H(P,P) == 0;
> (3) given (1) and (2) P must halt as H should return 0 to P's
> invocation of H but it doesn't because it is either a different H or an
> erroneous H;
> (4) given (1), (2) and (3) H is not a halt decider; it is an incredibly
> useless olcott simulation detector.
>
> /Flibble
>

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

On Fri, 17 Jun 2022 09:33:32 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/17/2022 9:11 AM, Mr Flibble wrote:
> > On Fri, 17 Jun 2022 06:29:29 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
>
> 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.

There is no such thing as a simulating halt decider and your failed
attempts at proving the contrary just confirms what. Why? Because if P
is NOT pathological and never halts then nor would a simulation of P
hence the decider would never return an answer of non-halting so is
in fact not a halt decider. The fact that your decider can detect an
infinite loop as represented as the x86 opcodes "EB FE" is not proof
that your decider can detect all forms of non-halting.

>
> >>
> >> *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
> >>
> >
> > You can keep repeating yourself as many times as you like but that
> > won't make you correct:
> >
> > (1) you assert H is a pure function so it must ALWAYS return the
> > SAME RESULT for the SAME ARGUMENTS with NO SIDE EFFECTS (aborting a
> > simulation is a side effect);
>
> 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.

Then H isn't a pure function for the computer science definition of a
pure function as pure functions can't have side effects and aborting
the simulation is a side effect.

/Flibble

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.

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

On Friday, 17 June 2022 at 22:51:15 UTC+8, olcott 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.
> --
> 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.

The irrefutable fact is clear: GUR cannot be violated, you don't have a
real POOH for test/review.

On 6/17/2022 9:43 AM, Mr Flibble wrote:
> On Fri, 17 Jun 2022 09:33:32 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/17/2022 9:11 AM, Mr Flibble wrote:
>>> On Fri, 17 Jun 2022 06:29:29 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>
>> 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.
>
> There is no such thing as a simulating halt decider and your failed
> attempts at proving the contrary just confirms what. Why? Because if P
> is NOT pathological and never halts then nor would a simulation of P
> hence the decider would never return an answer of non-halting so is
> in fact not a halt decider. The fact that your decider can detect an
> infinite loop as represented as the x86 opcodes "EB FE" is not proof
> that your decider can detect all forms of non-halting.

I have to repeat things to you too many times. This may get you blocked.

Refuting the halting problem proofs only requires a halt decider that
correctly decides a single input it can be totally wrong on every other
input.

--
Copyright 2022 Pete Olcott

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

On Fri, 17 Jun 2022 10:29:06 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/17/2022 9:43 AM, Mr Flibble wrote:
> > On Fri, 17 Jun 2022 09:33:32 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/17/2022 9:11 AM, Mr Flibble wrote:
> >>> On Fri, 17 Jun 2022 06:29:29 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>
> >> 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.
> >
> > There is no such thing as a simulating halt decider and your failed
> > attempts at proving the contrary just confirms what. Why? Because
> > if P is NOT pathological and never halts then nor would a
> > simulation of P hence the decider would never return an answer of
> > non-halting so is in fact not a halt decider. The fact that your
> > decider can detect an infinite loop as represented as the x86
> > opcodes "EB FE" is not proof that your decider can detect all forms
> > of non-halting.
>
> I have to repeat things to you too many times. This may get you
> blocked.

Block away: I will still refute your mess.

>
> Refuting the halting problem proofs only requires a halt decider that
> correctly decides a single input it can be totally wrong on every
> other input.

Nonsense.

I see you conveniently ignored my point about your H not being a pure
function: I think that is the real reason you want to block me as you
realize I am correct and you have fucked up, badly.

/Flibble

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

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

On 6/17/2022 10:06 AM, wij wrote:
> On Friday, 17 June 2022 at 22:51:15 UTC+8, olcott 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.
>> --
>> 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.

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

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)

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

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.

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?

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.

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,

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

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
>