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
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
On Fri, 17 Jun 2022 06:29:29 -0500
olcott <NoOne@NoWhere.com> wrote:
*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 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.
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 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:That is a misconception.
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.
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 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:That is a misconception.
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.
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.
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.
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.
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:That is a misconception.
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.
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
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:That is a misconception.
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.
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:It took me six months to figure out how to transform H(P,P) into a pure
On 6/17/2022 8:39 AM, wij wrote:
On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott wrote:That is a misconception.
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.
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.
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 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:That is a misconception.
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.
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 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:That is a misconception.
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.
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 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:That is a misconception.
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.
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.
/Flibble
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 asThat is a misconception.
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.
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>> --
"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 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 asThat is a misconception.
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.
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>> --
"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 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 itsThat is a misconception.
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.
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 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.That is a misconception.
*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.
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,
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
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: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
On Friday, 17 June 2022 at 19:29:37 UTC+8, olcottThat is a misconception.
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.
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. >>>>>>>>>>
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 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: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.
On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott >>>>>>>>>>>>>>> wrote:That is a misconception.
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.
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. >>>>>>>>>>>>
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
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:That is a misconception.
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.
Halt deciders must compute the mapping from their >>>>>>>>>>>>>> inputs to an accept or reject state on the basis of >>>>>>>>>>>>>> the actual behavior actually specified by these inputs. >>>>>>>>>>>>>>
It is an easily verified fact that the correct and >>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) by H >>>>>>>>>>>>>> would never reach its "ret" instruction thus
conclusively proving that it never halts.
H(P,P)==1 means P(P) halts.--
H(P,P)==Otherwise means H fails as a decider
(undecidable).
-----
Thanks to PO's years' tireless efforts demonstrated >>>>>>>>>>>>>>> even himself a genius in 10000-years cannot refute my >>>>>>>>>>>>>>> GUR. ...
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
GUR suggests no halting decider can exist. You just >>>>>>>>>>>>> confirms it by not able to provide POOH to test/review. >>>>>>>>>>>>>
It took me six months to figure out how to transform >>>>>>>>>>>> H(P,P) into a pure function of its inputs. I did not >>>>>>>>>>>> release the code before because I knew that its use of >>>>>>>>>>>> static local data would have been rejected. With this >>>>>>>>>>>> update to H I will be able to publish the code.
H recognizes that P is calling itself with its same
arguments that it was called with and there are no
instructions preceding this call that could possibly >>>>>>>>>>>> escape infinitely recursive emulation so H aborts its >>>>>>>>>>>> emulation of P before P even makes its first call to H. >>>>>>>>>>>>
Without even looking at the code competent software
engineers will be able to verify that the above H would >>>>>>>>>>>> correctly determine that that is input is non-halting as >>>>>>>>>>>> a pure function of this input.
So my other reply for why your H is not a pure function >>>>>>>>>>> for any accepted definition of the term.
/Flibble
In computer programming, a pure function is a function that >>>>>>>>>> has the following properties:
(1) the function return values are identical for identical >>>>>>>>>> arguments (no variation with local static variables,
non-local variables, mutable reference arguments or input >>>>>>>>>> streams), and
(2) the function application has no side effects (no
mutation of local static variables, non-local variables, >>>>>>>>>> mutable reference arguments or input/output streams).
Thus a pure function is a computational analogue of a
mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure functions do >>>>>>>>> not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
Whether or not it is construed as a side-effect does not matter
it must be a mutation side-effect to (a)(b)(c)(d) or it does
not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is said
to have a side effect if it modifies some state variable value(s)
outside its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the invoker
of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at this
address is emulated. Then H returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not have
side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
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:That is a misconception.
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.
Halt deciders must compute the mapping from their >>>>>>>>>>>>>> inputs to an accept or reject state on the basis of >>>>>>>>>>>>>> the actual behavior actually specified by these inputs. >>>>>>>>>>>>>>
It is an easily verified fact that the correct and >>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) by H >>>>>>>>>>>>>> would never reach its "ret" instruction thus
conclusively proving that it never halts.
H(P,P)==1 means P(P) halts.--
H(P,P)==Otherwise means H fails as a decider
(undecidable).
-----
Thanks to PO's years' tireless efforts demonstrated >>>>>>>>>>>>>>> even himself a genius in 10000-years cannot refute my >>>>>>>>>>>>>>> GUR. ...
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
GUR suggests no halting decider can exist. You just >>>>>>>>>>>>> confirms it by not able to provide POOH to test/review. >>>>>>>>>>>>>
It took me six months to figure out how to transform >>>>>>>>>>>> H(P,P) into a pure function of its inputs. I did not >>>>>>>>>>>> release the code before because I knew that its use of >>>>>>>>>>>> static local data would have been rejected. With this >>>>>>>>>>>> update to H I will be able to publish the code.
H recognizes that P is calling itself with its same
arguments that it was called with and there are no
instructions preceding this call that could possibly >>>>>>>>>>>> escape infinitely recursive emulation so H aborts its >>>>>>>>>>>> emulation of P before P even makes its first call to H. >>>>>>>>>>>>
Without even looking at the code competent software
engineers will be able to verify that the above H would >>>>>>>>>>>> correctly determine that that is input is non-halting as >>>>>>>>>>>> a pure function of this input.
So my other reply for why your H is not a pure function >>>>>>>>>>> for any accepted definition of the term.
/Flibble
In computer programming, a pure function is a function that >>>>>>>>>> has the following properties:
(1) the function return values are identical for identical >>>>>>>>>> arguments (no variation with local static variables,
non-local variables, mutable reference arguments or input >>>>>>>>>> streams), and
(2) the function application has no side effects (no
mutation of local static variables, non-local variables, >>>>>>>>>> mutable reference arguments or input/output streams).
Thus a pure function is a computational analogue of a
mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure functions do >>>>>>>>> not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
Whether or not it is construed as a side-effect does not matter
it must be a mutation side-effect to (a)(b)(c)(d) or it does
not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is said
to have a side effect if it modifies some state variable value(s)
outside its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the invoker
of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at this
address is emulated. Then H returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not have
side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:
On Friday, 17 June 2022 at 22:19:09 UTC+8, olcott >>>>>>>>>>>>>>> wrote:
On 6/17/2022 8:39 AM, wij wrote:
On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott >>>>>>>>>>>>>>>>> wrote:That is a misconception.
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.
Halt deciders must compute the mapping from their >>>>>>>>>>>>>>>> inputs to an accept or reject state on the basis of >>>>>>>>>>>>>>>> the actual behavior actually specified by these inputs. >>>>>>>>>>>>>>>>
It is an easily verified fact that the correct and >>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) by H >>>>>>>>>>>>>>>> would never reach its "ret" instruction thus
conclusively proving that it never halts.
H(P,P)==1 means P(P) halts.--
H(P,P)==Otherwise means H fails as a decider >>>>>>>>>>>>>>>>> (undecidable).
-----
Thanks to PO's years' tireless efforts demonstrated >>>>>>>>>>>>>>>>> even himself a genius in 10000-years cannot refute my >>>>>>>>>>>>>>>>> GUR. ...
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
GUR suggests no halting decider can exist. You just >>>>>>>>>>>>>>> confirms it by not able to provide POOH to test/review. >>>>>>>>>>>>>>>
It took me six months to figure out how to transform >>>>>>>>>>>>>> H(P,P) into a pure function of its inputs. I did not >>>>>>>>>>>>>> release the code before because I knew that its use of >>>>>>>>>>>>>> static local data would have been rejected. With this >>>>>>>>>>>>>> update to H I will be able to publish the code.
H recognizes that P is calling itself with its same >>>>>>>>>>>>>> arguments that it was called with and there are no >>>>>>>>>>>>>> instructions preceding this call that could possibly >>>>>>>>>>>>>> escape infinitely recursive emulation so H aborts its >>>>>>>>>>>>>> emulation of P before P even makes its first call to H. >>>>>>>>>>>>>>
Without even looking at the code competent software >>>>>>>>>>>>>> engineers will be able to verify that the above H would >>>>>>>>>>>>>> correctly determine that that is input is non-halting as >>>>>>>>>>>>>> a pure function of this input.
So my other reply for why your H is not a pure function >>>>>>>>>>>>> for any accepted definition of the term.
/Flibble
In computer programming, a pure function is a function that >>>>>>>>>>>> has the following properties:
(1) the function return values are identical for identical >>>>>>>>>>>> arguments (no variation with local static variables,
non-local variables, mutable reference arguments or input >>>>>>>>>>>> streams), and
(2) the function application has no side effects (no
mutation of local static variables, non-local variables, >>>>>>>>>>>> mutable reference arguments or input/output streams).
Thus a pure function is a computational analogue of a
mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure functions do >>>>>>>>>>> not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
Whether or not it is construed as a side-effect does not matter >>>>>>>> it must be a mutation side-effect to (a)(b)(c)(d) or it does
not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is said
to have a side effect if it modifies some state variable value(s)
outside its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the invoker
of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at this
address is emulated. Then H returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not have
side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
I might be on the spectrum; probably got Asperger's; whilst as far as
the topic under discussion is concerned, you've got nothing.
/Flibble
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:
On Friday, 17 June 2022 at 22:19:09 UTC+8, olcott >>>>>>>>>>>>>>> wrote:
On 6/17/2022 8:39 AM, wij wrote:
On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott >>>>>>>>>>>>>>>>> wrote:That is a misconception.
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.
Halt deciders must compute the mapping from their >>>>>>>>>>>>>>>> inputs to an accept or reject state on the basis of >>>>>>>>>>>>>>>> the actual behavior actually specified by these inputs. >>>>>>>>>>>>>>>>
It is an easily verified fact that the correct and >>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) by H >>>>>>>>>>>>>>>> would never reach its "ret" instruction thus
conclusively proving that it never halts.
H(P,P)==1 means P(P) halts.--
H(P,P)==Otherwise means H fails as a decider >>>>>>>>>>>>>>>>> (undecidable).
-----
Thanks to PO's years' tireless efforts demonstrated >>>>>>>>>>>>>>>>> even himself a genius in 10000-years cannot refute my >>>>>>>>>>>>>>>>> GUR. ...
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
GUR suggests no halting decider can exist. You just >>>>>>>>>>>>>>> confirms it by not able to provide POOH to test/review. >>>>>>>>>>>>>>>
It took me six months to figure out how to transform >>>>>>>>>>>>>> H(P,P) into a pure function of its inputs. I did not >>>>>>>>>>>>>> release the code before because I knew that its use of >>>>>>>>>>>>>> static local data would have been rejected. With this >>>>>>>>>>>>>> update to H I will be able to publish the code.
H recognizes that P is calling itself with its same >>>>>>>>>>>>>> arguments that it was called with and there are no >>>>>>>>>>>>>> instructions preceding this call that could possibly >>>>>>>>>>>>>> escape infinitely recursive emulation so H aborts its >>>>>>>>>>>>>> emulation of P before P even makes its first call to H. >>>>>>>>>>>>>>
Without even looking at the code competent software >>>>>>>>>>>>>> engineers will be able to verify that the above H would >>>>>>>>>>>>>> correctly determine that that is input is non-halting as >>>>>>>>>>>>>> a pure function of this input.
So my other reply for why your H is not a pure function >>>>>>>>>>>>> for any accepted definition of the term.
/Flibble
In computer programming, a pure function is a function that >>>>>>>>>>>> has the following properties:
(1) the function return values are identical for identical >>>>>>>>>>>> arguments (no variation with local static variables,
non-local variables, mutable reference arguments or input >>>>>>>>>>>> streams), and
(2) the function application has no side effects (no
mutation of local static variables, non-local variables, >>>>>>>>>>>> mutable reference arguments or input/output streams).
Thus a pure function is a computational analogue of a
mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure functions do >>>>>>>>>>> not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
Whether or not it is construed as a side-effect does not matter >>>>>>>> it must be a mutation side-effect to (a)(b)(c)(d) or it does
not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is said
to have a side effect if it modifies some state variable value(s)
outside its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the invoker
of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at this
address is emulated. Then H returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not have
side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second time an
*attempt* to call H is prevented than that is equivalent to calling H
and having H do something different with side effects. This is just my opinion though as it requires more thought and I am currently getting
drunk on gin and tonics.
/Flibble
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:
On Friday, 17 June 2022 at 22:19:09 UTC+8, olcott >>>>>>>>>>>>>>> wrote:
On 6/17/2022 8:39 AM, wij wrote:
On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott >>>>>>>>>>>>>>>>> wrote:That is a misconception.
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.
Halt deciders must compute the mapping from their >>>>>>>>>>>>>>>> inputs to an accept or reject state on the basis of >>>>>>>>>>>>>>>> the actual behavior actually specified by these >>>>>>>>>>>>>>>> inputs.
It is an easily verified fact that the correct and >>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) by H >>>>>>>>>>>>>>>> would never reach its "ret" instruction thus >>>>>>>>>>>>>>>> conclusively proving that it never halts. >>>>>>>>>>>>>>>>> H(P,P)==1 means P(P) halts.
H(P,P)==Otherwise means H fails as a decider >>>>>>>>>>>>>>>>> (undecidable).--
-----
Thanks to PO's years' tireless efforts demonstrated >>>>>>>>>>>>>>>>> even himself a genius in 10000-years cannot refute >>>>>>>>>>>>>>>>> my GUR. ...
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
GUR suggests no halting decider can exist. You just >>>>>>>>>>>>>>> confirms it by not able to provide POOH to
test/review.
It took me six months to figure out how to transform >>>>>>>>>>>>>> H(P,P) into a pure function of its inputs. I did not >>>>>>>>>>>>>> release the code before because I knew that its use of >>>>>>>>>>>>>> static local data would have been rejected. With this >>>>>>>>>>>>>> update to H I will be able to publish the code.
H recognizes that P is calling itself with its same >>>>>>>>>>>>>> arguments that it was called with and there are no >>>>>>>>>>>>>> instructions preceding this call that could possibly >>>>>>>>>>>>>> escape infinitely recursive emulation so H aborts its >>>>>>>>>>>>>> emulation of P before P even makes its first call to H. >>>>>>>>>>>>>>
Without even looking at the code competent software >>>>>>>>>>>>>> engineers will be able to verify that the above H would >>>>>>>>>>>>>> correctly determine that that is input is non-halting >>>>>>>>>>>>>> as a pure function of this input.
So my other reply for why your H is not a pure function >>>>>>>>>>>>> for any accepted definition of the term.
/Flibble
In computer programming, a pure function is a function >>>>>>>>>>>> that has the following properties:
(1) the function return values are identical for
identical arguments (no variation with local static
variables, non-local variables, mutable reference
arguments or input streams), and
(2) the function application has no side effects (no >>>>>>>>>>>> mutation of local static variables, non-local variables, >>>>>>>>>>>> mutable reference arguments or input/output streams). >>>>>>>>>>>>
Thus a pure function is a computational analogue of a >>>>>>>>>>>> mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure functions >>>>>>>>>>> do not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions do >>>>>>>>> not have side effects.
Whether or not it is construed as a side-effect does not
matter it must be a mutation side-effect to (a)(b)(c)(d) or
it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is
said to have a side effect if it modifies some state variable
value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the
invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at this
address is emulated. Then H returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not
have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second time an *attempt* to call H is prevented than that is equivalent to calling
H and having H do something different with side effects. This is
just my opinion though as it requires more thought and I am
currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same arguments
and
(b) there are no instructions preceding this call that could possibly
escape the infinite recursion / infinitely recursive emulation.
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:
On Friday, 17 June 2022 at 22:19:09 UTC+8, olcott >>>>>>>>>>>>>>>>> wrote:
On 6/17/2022 8:39 AM, wij wrote:
On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott >>>>>>>>>>>>>>>>>>> wrote:That is a misconception.
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.
Halt deciders must compute the mapping from their >>>>>>>>>>>>>>>>>> inputs to an accept or reject state on the basis of >>>>>>>>>>>>>>>>>> the actual behavior actually specified by these >>>>>>>>>>>>>>>>>> inputs.
It is an easily verified fact that the correct and >>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) by H >>>>>>>>>>>>>>>>>> would never reach its "ret" instruction thus >>>>>>>>>>>>>>>>>> conclusively proving that it never halts. >>>>>>>>>>>>>>>>>>> H(P,P)==1 means P(P) halts.
H(P,P)==Otherwise means H fails as a decider >>>>>>>>>>>>>>>>>>> (undecidable).--
-----
Thanks to PO's years' tireless efforts demonstrated >>>>>>>>>>>>>>>>>>> even himself a genius in 10000-years cannot refute >>>>>>>>>>>>>>>>>>> my GUR. ...
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit; >>>>>>>>>>>>>>>>>> Genius hits a target no one else can see." >>>>>>>>>>>>>>>>>> Arthur Schopenhauer
GUR suggests no halting decider can exist. You just >>>>>>>>>>>>>>>>> confirms it by not able to provide POOH to
test/review.
It took me six months to figure out how to transform >>>>>>>>>>>>>>>> H(P,P) into a pure function of its inputs. I did not >>>>>>>>>>>>>>>> release the code before because I knew that its use of >>>>>>>>>>>>>>>> static local data would have been rejected. With this >>>>>>>>>>>>>>>> update to H I will be able to publish the code. >>>>>>>>>>>>>>>>
H recognizes that P is calling itself with its same >>>>>>>>>>>>>>>> arguments that it was called with and there are no >>>>>>>>>>>>>>>> instructions preceding this call that could possibly >>>>>>>>>>>>>>>> escape infinitely recursive emulation so H aborts its >>>>>>>>>>>>>>>> emulation of P before P even makes its first call to H. >>>>>>>>>>>>>>>>
Without even looking at the code competent software >>>>>>>>>>>>>>>> engineers will be able to verify that the above H would >>>>>>>>>>>>>>>> correctly determine that that is input is non-halting >>>>>>>>>>>>>>>> as a pure function of this input.
So my other reply for why your H is not a pure function >>>>>>>>>>>>>>> for any accepted definition of the term.
/Flibble
In computer programming, a pure function is a function >>>>>>>>>>>>>> that has the following properties:
(1) the function return values are identical for
identical arguments (no variation with local static >>>>>>>>>>>>>> variables, non-local variables, mutable reference
arguments or input streams), and
(2) the function application has no side effects (no >>>>>>>>>>>>>> mutation of local static variables, non-local variables, >>>>>>>>>>>>>> mutable reference arguments or input/output streams). >>>>>>>>>>>>>>
Thus a pure function is a computational analogue of a >>>>>>>>>>>>>> mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>> do not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions do >>>>>>>>>>> not have side effects.
Whether or not it is construed as a side-effect does not
matter it must be a mutation side-effect to (a)(b)(c)(d) or >>>>>>>>>> it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is
said to have a side effect if it modifies some state variable
value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the
invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at this
address is emulated. Then H returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not
have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second time an
*attempt* to call H is prevented than that is equivalent to calling
H and having H do something different with side effects. This is
just my opinion though as it requires more thought and I am
currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same arguments
and
(b) there are no instructions preceding this call that could possibly
escape the infinite recursion / infinitely recursive emulation.
Agree but refusing to analyse what P would have done if H wasn't a
simulating decider still makes what you've got worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:So my other reply for why your H is not a pure >>>>>>>>>>>>>>> function for any accepted definition of the term. >>>>>>>>>>>>>>>
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:That is a misconception.
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.
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. >>>>>>>>>>>>>>>
/Flibble
In computer programming, a pure function is a function >>>>>>>>>>>>>> that has the following properties:
(1) the function return values are identical for >>>>>>>>>>>>>> identical arguments (no variation with local static >>>>>>>>>>>>>> variables, non-local variables, mutable reference >>>>>>>>>>>>>> arguments or input streams), and
(2) the function application has no side effects (no >>>>>>>>>>>>>> mutation of local static variables, non-local
variables, mutable reference arguments or input/output >>>>>>>>>>>>>> streams).
Thus a pure function is a computational analogue of a >>>>>>>>>>>>>> mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>> do not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>> do not have side effects.
Whether or not it is construed as a side-effect does not >>>>>>>>>> matter it must be a mutation side-effect to (a)(b)(c)(d) or >>>>>>>>>> it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is
said to have a side effect if it modifies some state variable
value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the
invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at
this address is emulated. Then H returns 0 to its caller:
main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not
have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second time an
*attempt* to call H is prevented than that is equivalent to
calling H and having H do something different with side effects.
This is just my opinion though as it requires more thought and I
am currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same arguments
and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H wasn't a simulating decider still makes what you've got worthless as far as
the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would have
done if H was merely an x86 emulator and not a halt deciding emulator.
The correct and complete x86 emulation of H(P,P) would never reach
its "ret" instruction thus making H a correct "not reach ret" / halt
decider for P.
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:So my other reply for why your H is not a pure >>>>>>>>>>>>>>> function for any accepted definition of the term. >>>>>>>>>>>>>>>
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>>>>>>> --
"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. >>>>>>>>>>>>>>>
/Flibble
In computer programming, a pure function is a
function that has the following properties:
(1) the function return values are identical for >>>>>>>>>>>>>> identical arguments (no variation with local static >>>>>>>>>>>>>> variables, non-local variables, mutable reference >>>>>>>>>>>>>> arguments or input streams), and
(2) the function application has no side effects (no >>>>>>>>>>>>>> mutation of local static variables, non-local
variables, mutable reference arguments or
input/output streams).
Thus a pure function is a computational analogue of a >>>>>>>>>>>>>> mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure
functions do not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>> do not have side effects.
Whether or not it is construed as a side-effect does not >>>>>>>>>> matter it must be a mutation side-effect to (a)(b)(c)(d) >>>>>>>>>> or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression
is said to have a side effect if it modifies some state
variable value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first
part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the
invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at
this address is emulated. Then H returns 0 to its caller:
main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second time
an *attempt* to call H is prevented than that is equivalent to
calling H and having H do something different with side effects.
This is just my opinion though as it requires more thought and I
am currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H wasn't a simulating decider still makes what you've got worthless as far as
the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt deciding
emulator.
The correct and complete x86 emulation of H(P,P) would never reach
its "ret" instruction thus making H a correct "not reach ret" / halt decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
On Fri, 17 Jun 2022 18:14:48 +0100
Mr Flibble <flibble@reddwarf.jmc> wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:Not at all, but you do seem to have that problem.
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>>>>>>> --
"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) >>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure
functions do not have side effects.
Whether or not it is construed as a side-effect does >>>>>>>>>> not matter it must be a mutation side-effect to
(a)(b)(c)(d) or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression >>>>>>> is said to have a side effect if it modifies some state
variable value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first
part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the
invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to
the invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its
machine address of [0000135d] the very first time before
the code at this address is emulated. Then H returns 0 to
its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second
time an *attempt* to call H is prevented than that is
equivalent to calling H and having H do something different
with side effects. This is just my opinion though as it
requires more thought and I am currently getting drunk on gin
and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H
wasn't a simulating decider still makes what you've got
worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt deciding emulator.
The correct and complete x86 emulation of H(P,P) would never reach
its "ret" instruction thus making H a correct "not reach ret" /
halt decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
Your assumption that any program that calls H is also pathological is
a flawed one. I have said before that all you have is a simulation
detector and not a halt decider: simulating halt deciders cannot
decide non-pathological non-halting programs in finite time so are not actually deciders.
On Fri, 17 Jun 2022 18:14:48 +0100
Mr Flibble <flibble@reddwarf.jmc> wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:So my other reply for why your H is not a pure >>>>>>>>>>>>>>>>>> function for any accepted definition of the term. >>>>>>>>>>>>>>>>>>
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>>>>>>>>>> --
"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. >>>>>>>>>>>>>>>>>>
/Flibble
In computer programming, a pure function is a >>>>>>>>>>>>>>>>> function that has the following properties:
(1) the function return values are identical for >>>>>>>>>>>>>>>>> identical arguments (no variation with local static >>>>>>>>>>>>>>>>> variables, non-local variables, mutable reference >>>>>>>>>>>>>>>>> arguments or input streams), and
(2) the function application has no side effects (no >>>>>>>>>>>>>>>>> mutation of local static variables, non-local >>>>>>>>>>>>>>>>> variables, mutable reference arguments or
input/output streams).
Thus a pure function is a computational analogue of a >>>>>>>>>>>>>>>>> mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>> functions do not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>>> do not have side effects.
Whether or not it is construed as a side-effect does not >>>>>>>>>>>>> matter it must be a mutation side-effect to (a)(b)(c)(d) >>>>>>>>>>>>> or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression >>>>>>>>>> is said to have a side effect if it modifies some state
variable value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first
part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the
invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to the >>>>>>>>>> invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine >>>>>>>>> address of [0000135d] the very first time before the code at >>>>>>>>> this address is emulated. Then H returns 0 to its caller:
main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second time
an *attempt* to call H is prevented than that is equivalent to
calling H and having H do something different with side effects.
This is just my opinion though as it requires more thought and I
am currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H wasn't a
simulating decider still makes what you've got worthless as far as
the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt deciding
emulator.
The correct and complete x86 emulation of H(P,P) would never reach
its "ret" instruction thus making H a correct "not reach ret" / halt
decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
Your assumption that any program that calls H is also pathological is
a flawed one. I have said before that all you have is a simulation
detector and not a halt decider: simulating halt deciders cannot
decide non-pathological non-halting programs in finite time so are not actually deciders.
/Flibble
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:So my other reply for why your H is not a pure >>>>>>>>>>>>>>>>> function for any accepted definition of the term. >>>>>>>>>>>>>>>>>
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:That is a misconception.
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.
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. >>>>>>>>>>>>>>>>>
/Flibble
In computer programming, a pure function is a function >>>>>>>>>>>>>>>> that has the following properties:
(1) the function return values are identical for >>>>>>>>>>>>>>>> identical arguments (no variation with local static >>>>>>>>>>>>>>>> variables, non-local variables, mutable reference >>>>>>>>>>>>>>>> arguments or input streams), and
(2) the function application has no side effects (no >>>>>>>>>>>>>>>> mutation of local static variables, non-local
variables, mutable reference arguments or input/output >>>>>>>>>>>>>>>> streams).
Thus a pure function is a computational analogue of a >>>>>>>>>>>>>>>> mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>>>> do not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>> do not have side effects.
Whether or not it is construed as a side-effect does not >>>>>>>>>>>> matter it must be a mutation side-effect to (a)(b)(c)(d) or >>>>>>>>>>>> it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is >>>>>>>>> said to have a side effect if it modifies some state variable >>>>>>>>> value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first part. >>>>>>>>
which is to say if it has any observable effect
other than its primary effect of returning a value to the
invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at
this address is emulated. Then H returns 0 to its caller:
main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not
have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second time an
*attempt* to call H is prevented than that is equivalent to
calling H and having H do something different with side effects.
This is just my opinion though as it requires more thought and I
am currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same arguments
and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H wasn't a
simulating decider still makes what you've got worthless as far as
the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would have
done if H was merely an x86 emulator and not a halt deciding emulator.
The correct and complete x86 emulation of H(P,P) would never reach
its "ret" instruction thus making H a correct "not reach ret" / halt
decider for P.
You need to think about a P that calls H but is non-pathological halting
(no infinite loop).
/Flibble
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:So my other reply for why your H is not a pure >>>>>>>>>>>>>>>>> function for any accepted definition of the term. >>>>>>>>>>>>>>>>>
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>>>>>>>>> --
"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. >>>>>>>>>>>>>>>>>
/Flibble
In computer programming, a pure function is a >>>>>>>>>>>>>>>> function that has the following properties:
(1) the function return values are identical for >>>>>>>>>>>>>>>> identical arguments (no variation with local static >>>>>>>>>>>>>>>> variables, non-local variables, mutable reference >>>>>>>>>>>>>>>> arguments or input streams), and
(2) the function application has no side effects (no >>>>>>>>>>>>>>>> mutation of local static variables, non-local >>>>>>>>>>>>>>>> variables, mutable reference arguments or
input/output streams).
Thus a pure function is a computational analogue of a >>>>>>>>>>>>>>>> mathematical function.
https://en.wikipedia.org/wiki/Pure_function
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>> functions do not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>> do not have side effects.
Whether or not it is construed as a side-effect does not >>>>>>>>>>>> matter it must be a mutation side-effect to (a)(b)(c)(d) >>>>>>>>>>>> or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression >>>>>>>>> is said to have a side effect if it modifies some state
variable value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first
part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the
invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to the >>>>>>>>> invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine >>>>>>>> address of [0000135d] the very first time before the code at >>>>>>>> this address is emulated. Then H returns 0 to its caller:
main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second time
an *attempt* to call H is prevented than that is equivalent to
calling H and having H do something different with side effects.
This is just my opinion though as it requires more thought and I
am currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H wasn't a
simulating decider still makes what you've got worthless as far as
the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt deciding
emulator.
The correct and complete x86 emulation of H(P,P) would never reach
its "ret" instruction thus making H a correct "not reach ret" /
halt decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here about
three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation of the
input to H(P,P) by H never reaches its "ret" instruction thus never
halts.
On Fri, 17 Jun 2022 19:04:51 +0100
Mr Flibble <flibble@reddwarf.jmc> wrote:
On Fri, 17 Jun 2022 18:14:48 +0100
Mr Flibble <flibble@reddwarf.jmc> wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:
On Friday, 17 June 2022 at 22:19:09 UTC+8, >>>>>>>>>>>>>>>>>>>>> olcott wrote:
On 6/17/2022 8:39 AM, wij wrote:
On Friday, 17 June 2022 at 19:29:37 UTC+8, >>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
When a simulating halt decider rejects all >>>>>>>>>>>>>>>>>>>>>>>> inputs as non-halting whenever it correctly >>>>>>>>>>>>>>>>>>>>>>>> detects that its correct and complete >>>>>>>>>>>>>>>>>>>>>>>> simulation of its input would never reach the >>>>>>>>>>>>>>>>>>>>>>>> final state of this input then all [these] >>>>>>>>>>>>>>>>>>>>>>>> inputs (including pathological inputs) are >>>>>>>>>>>>>>>>>>>>>>>> decided correctly.
*computation that halts* … the Turing machine >>>>>>>>>>>>>>>>>>>>>>>> will halt whenever it enters a final state. >>>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal >>>>>>>>>>>>>>>>>>>>>>>> Languages and Automata. Lexington/Toronto: D. >>>>>>>>>>>>>>>>>>>>>>>> C. Heath and Company. (317-320) >>>>>>>>>>>>>>>>>>>>>>>>
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P)); >>>>>>>>>>>>>>>>>>>>>>>> }
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P >>>>>>>>>>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P >>>>>>>>>>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // >>>>>>>>>>>>>>>>>>>>>>>> call H [00001362](03) 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>>> [00001365](02) 85c0 test eax,eax >>>>>>>>>>>>>>>>>>>>>>>> [00001367](02) 7402 jz 0000136b >>>>>>>>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369 >>>>>>>>>>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c] >>>>>>>>>>>>>>>>>>>>>>>>
(1) It is an easily verified fact that when >>>>>>>>>>>>>>>>>>>>>>>> we assume that H is only an x86 emulator >>>>>>>>>>>>>>>>>>>>>>>> that the correctly emulated P never reaches >>>>>>>>>>>>>>>>>>>>>>>> its "ret" instruction it remains stuck in >>>>>>>>>>>>>>>>>>>>>>>> repeated cycles of emulation.
(2) It is an easily verified fact that if H >>>>>>>>>>>>>>>>>>>>>>>> has been adapted to correctly detect (in a >>>>>>>>>>>>>>>>>>>>>>>> finite number of steps) that the correct and >>>>>>>>>>>>>>>>>>>>>>>> complete x86 emulation of its input would >>>>>>>>>>>>>>>>>>>>>>>> never each its "ret" instruction that H >>>>>>>>>>>>>>>>>>>>>>>> could abort its emulation and return 0 to >>>>>>>>>>>>>>>>>>>>>>>> report this.
(3) When the halt status criteria is defined >>>>>>>>>>>>>>>>>>>>>>>> as correctly determining whether or not an >>>>>>>>>>>>>>>>>>>>>>>> x86 emulated input would ever reach its "ret" >>>>>>>>>>>>>>>>>>>>>>>> instruction then it becomes an easily >>>>>>>>>>>>>>>>>>>>>>>> verified fact H(P,P) could correctly reject >>>>>>>>>>>>>>>>>>>>>>>> its input as non-halting.
Correct deductive inference proves that all >>>>>>>>>>>>>>>>>>>>>>>> of these things are true without any need >>>>>>>>>>>>>>>>>>>>>>>> what-so-ever to see either the source-code or >>>>>>>>>>>>>>>>>>>>>>>> the execution trace of H.
The one thing that is not proved is whether >>>>>>>>>>>>>>>>>>>>>>>> or not an actual encoded H(P,P) does indeed >>>>>>>>>>>>>>>>>>>>>>>> correctly determine that its input would >>>>>>>>>>>>>>>>>>>>>>>> never reach its "ret" instruction as a pure >>>>>>>>>>>>>>>>>>>>>>>> function of its inputs. This aspect will be >>>>>>>>>>>>>>>>>>>>>>>> confirmed by fully operational source-code. >>>>>>>>>>>>>>>>>>>>>>>>
Halting problem undecidability and infinitely >>>>>>>>>>>>>>>>>>>>>>>> nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit; >>>>>>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see." >>>>>>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
GUR already suggested such a halting decider H >>>>>>>>>>>>>>>>>>>>>>> cannot exist:
H(P,P)==0 means P(P) does not halt. >>>>>>>>>>>>>>>>>>>>>> That is a misconception.
Halt deciders must compute the mapping from >>>>>>>>>>>>>>>>>>>>>> their inputs to an accept or reject state on >>>>>>>>>>>>>>>>>>>>>> the basis of the actual behavior actually >>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
It is an easily verified fact that the correct >>>>>>>>>>>>>>>>>>>>>> and complete x86 emulation of the input to >>>>>>>>>>>>>>>>>>>>>> H(P,P) by H would never reach its "ret" >>>>>>>>>>>>>>>>>>>>>> instruction thus conclusively proving that it >>>>>>>>>>>>>>>>>>>>>> never halts.
H(P,P)==1 means P(P) halts.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>>>>>>>>>>> --
"Talent hits a target no one else can hit; >>>>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see." >>>>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
GUR suggests no halting decider can exist. You >>>>>>>>>>>>>>>>>>>>> just confirms it by not able to provide POOH to >>>>>>>>>>>>>>>>>>>>> test/review.
It took me six months to figure out how to >>>>>>>>>>>>>>>>>>>> transform H(P,P) into a pure function of its >>>>>>>>>>>>>>>>>>>> inputs. I did not release the code before because >>>>>>>>>>>>>>>>>>>> I knew that its use of static local data would >>>>>>>>>>>>>>>>>>>> have been rejected. With this update to H I will >>>>>>>>>>>>>>>>>>>> be able to publish the code.
H recognizes that P is calling itself with its >>>>>>>>>>>>>>>>>>>> same arguments that it was called with and there >>>>>>>>>>>>>>>>>>>> are no instructions preceding this call that >>>>>>>>>>>>>>>>>>>> could possibly escape infinitely recursive >>>>>>>>>>>>>>>>>>>> emulation so H aborts its emulation of P before >>>>>>>>>>>>>>>>>>>> P even makes its first call to H.
Without even looking at the code competent >>>>>>>>>>>>>>>>>>>> software engineers will be able to verify that >>>>>>>>>>>>>>>>>>>> the above H would correctly determine that that >>>>>>>>>>>>>>>>>>>> is input is non-halting as a pure function of >>>>>>>>>>>>>>>>>>>> this input.
So my other reply for why your H is not a pure >>>>>>>>>>>>>>>>>>> function for any accepted definition of the term. >>>>>>>>>>>>>>>>>>>
/Flibble
In computer programming, a pure function is a >>>>>>>>>>>>>>>>>> function that has the following properties: >>>>>>>>>>>>>>>>>>
(1) the function return values are identical for >>>>>>>>>>>>>>>>>> identical arguments (no variation with local static >>>>>>>>>>>>>>>>>> variables, non-local variables, mutable reference >>>>>>>>>>>>>>>>>> arguments or input streams), and
(2) the function application has no side effects >>>>>>>>>>>>>>>>>> (no mutation of local static variables, non-local >>>>>>>>>>>>>>>>>> variables, mutable reference arguments or
input/output streams).
Thus a pure function is a computational analogue >>>>>>>>>>>>>>>>>> of a mathematical function.
https://en.wikipedia.org/wiki/Pure_function >>>>>>>>>>>>>>>>>>
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>>> functions do not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem. >>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure
functions do not have side effects.
Whether or not it is construed as a side-effect does >>>>>>>>>>>>>> not matter it must be a mutation side-effect to
(a)(b)(c)(d) or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression >>>>>>>>>>> is said to have a side effect if it modifies some state
variable value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first
part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the >>>>>>>>>>> invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to
the invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its
machine address of [0000135d] the very first time before
the code at this address is emulated. Then H returns 0 to
its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second
time an *attempt* to call H is prevented than that is
equivalent to calling H and having H do something different
with side effects. This is just my opinion though as it
requires more thought and I am currently getting drunk on gin
and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H
wasn't a simulating decider still makes what you've got
worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt deciding
emulator.
The correct and complete x86 emulation of H(P,P) would never reach
its "ret" instruction thus making H a correct "not reach ret" /
halt decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
Your assumption that any program that calls H is also pathological is
a flawed one. I have said before that all you have is a simulation
detector and not a halt decider: simulating halt deciders cannot
decide non-pathological non-halting programs in finite time so are not
actually deciders.
The question then becomes is a simulation detector (rather than a halt decider) sufficient to refute proofs based on the [Strachey 1965]
impossible program? I cannot answer that question as I am unfamiliar
with the proofs.
/Flibble
On Fri, 17 Jun 2022 13:42:05 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:33:59 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 09:51:07 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 9:39 AM, wij wrote:So my other reply for why your H is not a pure >>>>>>>>>>>>>>>>>>> function for any accepted definition of the term. >>>>>>>>>>>>>>>>>>>
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>>>>>>>>>>> --
"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. >>>>>>>>>>>>>>>>>>>
/Flibble
In computer programming, a pure function is a >>>>>>>>>>>>>>>>>> function that has the following properties: >>>>>>>>>>>>>>>>>>
(1) the function return values are identical for >>>>>>>>>>>>>>>>>> identical arguments (no variation with local static >>>>>>>>>>>>>>>>>> variables, non-local variables, mutable reference >>>>>>>>>>>>>>>>>> arguments or input streams), and
(2) the function application has no side effects (no >>>>>>>>>>>>>>>>>> mutation of local static variables, non-local >>>>>>>>>>>>>>>>>> variables, mutable reference arguments or
input/output streams).
Thus a pure function is a computational analogue of a >>>>>>>>>>>>>>>>>> mathematical function.
https://en.wikipedia.org/wiki/Pure_function >>>>>>>>>>>>>>>>>>
The revised H has no:
(a) local static variables
(b) non-local variables
(c) mutable reference arguments
(d) input streams
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>>> functions do not have side effects.
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem. >>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>>>> do not have side effects.
Whether or not it is construed as a side-effect does not >>>>>>>>>>>>>> matter it must be a mutation side-effect to (a)(b)(c)(d) >>>>>>>>>>>>>> or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression >>>>>>>>>>> is said to have a side effect if it modifies some state
variable value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first
part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the >>>>>>>>>>> invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to the >>>>>>>>>>> invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine >>>>>>>>>> address of [0000135d] the very first time before the code at >>>>>>>>>> this address is emulated. Then H returns 0 to its caller:
main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do
not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second time
an *attempt* to call H is prevented than that is equivalent to
calling H and having H do something different with side effects. >>>>>>> This is just my opinion though as it requires more thought and I >>>>>>> am currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H wasn't a
simulating decider still makes what you've got worthless as far as
the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt deciding
emulator.
The correct and complete x86 emulation of H(P,P) would never reach
its "ret" instruction thus making H a correct "not reach ret" /
halt decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here about
three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation of the
input to H(P,P) by H never reaches its "ret" instruction thus never
halts.
Try reading what I actually wrote:
void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}
How does your "decider" handle that P?
/Flibble
On 6/17/2022 1:45 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 13:42:05 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:Not at all, but you do seem to have that problem. >>>>>>>>>>>>>>>
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>>>>>>>>>>> --
"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) >>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>> functions do not have side effects.
Whether or not it is construed as a side-effect does >>>>>>>>>>>>>> not matter it must be a mutation side-effect to
(a)(b)(c)(d) or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression >>>>>>>>>>> is said to have a side effect if it modifies some state >>>>>>>>>>> variable value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first >>>>>>>>>> part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the >>>>>>>>>>> invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to >>>>>>>>>>> the invoker disqualifies it from being a pure function. >>>>>>>>>>>
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its
machine address of [0000135d] the very first time before >>>>>>>>>> the code at this address is emulated. Then H returns 0 to >>>>>>>>>> its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do >>>>>>>>> not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second
time an *attempt* to call H is prevented than that is
equivalent to calling H and having H do something different
with side effects. This is just my opinion though as it
requires more thought and I am currently getting drunk on gin
and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H
wasn't a simulating decider still makes what you've got
worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt deciding
emulator.
The correct and complete x86 emulation of H(P,P) would never
reach its "ret" instruction thus making H a correct "not reach
ret" / halt decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here about
three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation of the
input to H(P,P) by H never reaches its "ret" instruction thus never
halts.
Try reading what I actually wrote:
void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}
How does your "decider" handle that P?
/Flibble
Removing the infinite loop does not make it non pathological.
As I have said donzens of times the infinite loop is unreachable.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](03) 8b4508 mov eax,[ebp+08]
[000013bc](01) 50 push eax
[000013bd](03) 8b4d08 mov ecx,[ebp+08]
[000013c0](01) 51 push ecx
[000013c1](05) e8e0fdffff call 000011a6
[000013c6](03) 83c408 add esp,+08
[000013c9](01) 5d pop ebp
[000013ca](01) c3 ret
Size in bytes:(0021) [000013ca]
_main()
[000013d6](01) 55 push ebp
[000013d7](02) 8bec mov ebp,esp
[000013d9](05) 68b6130000 push 000013b6
[000013de](05) 68b6130000 push 000013b6
[000013e3](05) e8befdffff call 000011a6
[000013e8](03) 83c408 add esp,+08
[000013eb](01) 50 push eax
[000013ec](05) 6827040000 push 00000427
[000013f1](05) e880f0ffff call 00000476
[000013f6](03) 83c408 add esp,+08
[000013f9](02) 33c0 xor eax,eax
[000013fb](01) 5d pop ebp
[000013fc](01) c3 ret
Size in bytes:(0039) [000013fc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= ...[000013d6][00102357][00000000] 55 push ebp ...[000013d7][00102357][00000000] 8bec mov ebp,esp ...[000013d9][00102353][000013b6] 68b6130000 push 000013b6 ...[000013de][0010234f][000013b6] 68b6130000 push 000013b6 ...[000013e3][0010234b][000013e8] e8befdffff call 000011a6
Begin Local Halt Decider Simulation Execution Trace Stored at:21240b ...[000013b6][002123f7][002123fb] 55 push ebp ...[000013b7][002123f7][002123fb] 8bec mov ebp,esp ...[000013b9][002123f7][002123fb] 8b4508 mov eax,[ebp+08] ...[000013bc][002123f3][000013b6] 50 push eax ...[000013bd][002123f3][000013b6] 8b4d08 mov ecx,[ebp+08] ...[000013c0][002123ef][000013b6] 51 push ecx ...[000013c1][002123eb][000013c6] e8e0fdffff call 000011a6 ...[000013b6][0025ce1f][0025ce23] 55 push ebp ...[000013b7][0025ce1f][0025ce23] 8bec mov ebp,esp ...[000013b9][0025ce1f][0025ce23] 8b4508 mov eax,[ebp+08] ...[000013bc][0025ce1b][000013b6] 50 push eax ...[000013bd][0025ce1b][000013b6] 8b4d08 mov ecx,[ebp+08] ...[000013c0][0025ce17][000013b6] 51 push ecx ...[000013c1][0025ce13][000013c6] e8e0fdffff call 000011a6
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[000013e8][00102357][00000000] 83c408 add esp,+08 ...[000013eb][00102353][00000000] 50 push eax ...[000013ec][0010234f][00000427] 6827040000 push 00000427 ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08 ...[000013f9][00102357][00000000] 33c0 xor eax,eax ...[000013fb][0010235b][00100000] 5d pop ebp ...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
On Fri, 17 Jun 2022 14:15:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 1:45 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 13:42:05 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote:Not at all, but you do seem to have that problem. >>>>>>>>>>>>>>>>>
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>>>>>>>>>>>>> --
"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) >>>>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>>> functions do not have side effects.
Whether or not it is construed as a side-effect does >>>>>>>>>>>>>>>> not matter it must be a mutation side-effect to >>>>>>>>>>>>>>>> (a)(b)(c)(d) or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression >>>>>>>>>>>>> is said to have a side effect if it modifies some state >>>>>>>>>>>>> variable value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first >>>>>>>>>>>> part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the >>>>>>>>>>>>> invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to >>>>>>>>>>>>> the invoker disqualifies it from being a pure function. >>>>>>>>>>>>>
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H >>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its
machine address of [0000135d] the very first time before >>>>>>>>>>>> the code at this address is emulated. Then H returns 0 to >>>>>>>>>>>> its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do >>>>>>>>>>> not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second
time an *attempt* to call H is prevented than that is
equivalent to calling H and having H do something different
with side effects. This is just my opinion though as it
requires more thought and I am currently getting drunk on gin >>>>>>>>> and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
Agree but refusing to analyse what P would have done if H
wasn't a simulating decider still makes what you've got
worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt deciding
emulator.
The correct and complete x86 emulation of H(P,P) would never
reach its "ret" instruction thus making H a correct "not reach
ret" / halt decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here about
three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation of the
input to H(P,P) by H never reaches its "ret" instruction thus never
halts.
Try reading what I actually wrote:
void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}
How does your "decider" handle that P?
/Flibble
Removing the infinite loop does not make it non pathological.
As I have said donzens of times the infinite loop is unreachable.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](03) 8b4508 mov eax,[ebp+08]
[000013bc](01) 50 push eax
[000013bd](03) 8b4d08 mov ecx,[ebp+08]
[000013c0](01) 51 push ecx
[000013c1](05) e8e0fdffff call 000011a6
[000013c6](03) 83c408 add esp,+08
[000013c9](01) 5d pop ebp
[000013ca](01) c3 ret
Size in bytes:(0021) [000013ca]
_main()
[000013d6](01) 55 push ebp
[000013d7](02) 8bec mov ebp,esp
[000013d9](05) 68b6130000 push 000013b6
[000013de](05) 68b6130000 push 000013b6
[000013e3](05) e8befdffff call 000011a6
[000013e8](03) 83c408 add esp,+08
[000013eb](01) 50 push eax
[000013ec](05) 6827040000 push 00000427
[000013f1](05) e880f0ffff call 00000476
[000013f6](03) 83c408 add esp,+08
[000013f9](02) 33c0 xor eax,eax
[000013fb](01) 5d pop ebp
[000013fc](01) c3 ret
Size in bytes:(0039) [000013fc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000013d6][00102357][00000000] 55 push ebp
...[000013d7][00102357][00000000] 8bec mov ebp,esp
...[000013d9][00102353][000013b6] 68b6130000 push 000013b6
...[000013de][0010234f][000013b6] 68b6130000 push 000013b6
...[000013e3][0010234b][000013e8] e8befdffff call 000011a6
Begin Local Halt Decider Simulation Execution Trace Stored at:21240b
...[000013b6][002123f7][002123fb] 55 push ebp
...[000013b7][002123f7][002123fb] 8bec mov ebp,esp
...[000013b9][002123f7][002123fb] 8b4508 mov eax,[ebp+08]
...[000013bc][002123f3][000013b6] 50 push eax
...[000013bd][002123f3][000013b6] 8b4d08 mov ecx,[ebp+08]
...[000013c0][002123ef][000013b6] 51 push ecx
...[000013c1][002123eb][000013c6] e8e0fdffff call 000011a6
...[000013b6][0025ce1f][0025ce23] 55 push ebp
...[000013b7][0025ce1f][0025ce23] 8bec mov ebp,esp
...[000013b9][0025ce1f][0025ce23] 8b4508 mov eax,[ebp+08]
...[000013bc][0025ce1b][000013b6] 50 push eax
...[000013bd][0025ce1b][000013b6] 8b4d08 mov ecx,[ebp+08]
...[000013c0][0025ce17][000013b6] 51 push ecx
...[000013c1][0025ce13][000013c6] e8e0fdffff call 000011a6
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
So it gets the answer wrong. QED.
/Flibble
On 6/17/2022 2:17 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:15:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 1:45 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 13:42:05 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500Not at all, but you do seem to have that problem. >>>>>>>>>>>>>>>>>
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).Copyright 2022 Pete Olcott
-----
Thanks to PO's years' tireless efforts >>>>>>>>>>>>>>>>>>>>>>>>> demonstrated even himself a genius in >>>>>>>>>>>>>>>>>>>>>>>>> 10000-years cannot refute my GUR. ... >>>>>>>>>>>>>>>>>>>>>>>> --
"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) >>>>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>>> functions do not have side effects.
Whether or not it is construed as a side-effect does >>>>>>>>>>>>>>>> not matter it must be a mutation side-effect to >>>>>>>>>>>>>>>> (a)(b)(c)(d) or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or
expression is said to have a side effect if it modifies >>>>>>>>>>>>> some state variable value(s) outside its local
environment,
The second part is an inaccurate paraphrase of the first >>>>>>>>>>>> part.
which is to say if it has any observable effect
other than its primary effect of returning a value to >>>>>>>>>>>>> the invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to >>>>>>>>>>>>> the invoker disqualifies it from being a pure function. >>>>>>>>>>>>>
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H >>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its >>>>>>>>>>>> machine address of [0000135d] the very first time before >>>>>>>>>>>> the code at this address is emulated. Then H returns 0 to >>>>>>>>>>>> its caller: main().
Returning to main() is not returning to its invoker, P. >>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>> do not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second >>>>>>>>> time an *attempt* to call H is prevented than that is
equivalent to calling H and having H do something different >>>>>>>>> with side effects. This is just my opinion though as it
requires more thought and I am currently getting drunk on
gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion >>>>>>>> (a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could >>>>>>>> possibly escape the infinite recursion / infinitely recursive >>>>>>>> emulation.
Agree but refusing to analyse what P would have done if H
wasn't a simulating decider still makes what you've got
worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak) >>>>>>>
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt
deciding emulator.
The correct and complete x86 emulation of H(P,P) would never
reach its "ret" instruction thus making H a correct "not reach
ret" / halt decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here about
three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation of
the input to H(P,P) by H never reaches its "ret" instruction
thus never halts.
Try reading what I actually wrote:
void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}
How does your "decider" handle that P?
/Flibble
Removing the infinite loop does not make it non pathological.
As I have said donzens of times the infinite loop is unreachable.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](03) 8b4508 mov eax,[ebp+08]
[000013bc](01) 50 push eax
[000013bd](03) 8b4d08 mov ecx,[ebp+08]
[000013c0](01) 51 push ecx
[000013c1](05) e8e0fdffff call 000011a6
[000013c6](03) 83c408 add esp,+08
[000013c9](01) 5d pop ebp
[000013ca](01) c3 ret
Size in bytes:(0021) [000013ca]
_main()
[000013d6](01) 55 push ebp
[000013d7](02) 8bec mov ebp,esp
[000013d9](05) 68b6130000 push 000013b6
[000013de](05) 68b6130000 push 000013b6
[000013e3](05) e8befdffff call 000011a6
[000013e8](03) 83c408 add esp,+08
[000013eb](01) 50 push eax
[000013ec](05) 6827040000 push 00000427
[000013f1](05) e880f0ffff call 00000476
[000013f6](03) 83c408 add esp,+08
[000013f9](02) 33c0 xor eax,eax
[000013fb](01) 5d pop ebp
[000013fc](01) c3 ret
Size in bytes:(0039) [000013fc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000013d6][00102357][00000000] 55 push ebp
...[000013d7][00102357][00000000] 8bec mov ebp,esp
...[000013d9][00102353][000013b6] 68b6130000 push 000013b6
...[000013de][0010234f][000013b6] 68b6130000 push 000013b6
...[000013e3][0010234b][000013e8] e8befdffff call 000011a6
Begin Local Halt Decider Simulation Execution Trace Stored
at:21240b ...[000013b6][002123f7][002123fb] 55 push
ebp ...[000013b7][002123f7][002123fb] 8bec mov ebp,esp
...[000013b9][002123f7][002123fb] 8b4508 mov eax,[ebp+08]
...[000013bc][002123f3][000013b6] 50 push eax
...[000013bd][002123f3][000013b6] 8b4d08 mov ecx,[ebp+08]
...[000013c0][002123ef][000013b6] 51 push ecx
...[000013c1][002123eb][000013c6] e8e0fdffff call 000011a6
...[000013b6][0025ce1f][0025ce23] 55 push ebp
...[000013b7][0025ce1f][0025ce23] 8bec mov ebp,esp
...[000013b9][0025ce1f][0025ce23] 8b4508 mov eax,[ebp+08]
...[000013bc][0025ce1b][000013b6] 50 push eax
...[000013bd][0025ce1b][000013b6] 8b4d08 mov ecx,[ebp+08]
...[000013c0][0025ce17][000013b6] 51 push ecx
...[000013c1][0025ce13][000013c6] e8e0fdffff call 000011a6
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
So it gets the answer wrong. QED.
/Flibble
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
This is the culmination of the essence of more than five years worth
of full time work when I first discovered that a simulating halt
decider could correctly determine the halt status of the "impossible"
input:
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 that all [these] inputs (including pathological inputs) are
decided correctly.
On Fri, 17 Jun 2022 14:34:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 2:17 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:15:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 1:45 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 13:42:05 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500Not at all, but you do seem to have that problem. >>>>>>>>>>>>>>>>>>>
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).Copyright 2022 Pete Olcott >>>>>>>>>>>>>>>>>>>>>>>>>>
-----
Thanks to PO's years' tireless efforts >>>>>>>>>>>>>>>>>>>>>>>>>>> demonstrated even himself a genius in >>>>>>>>>>>>>>>>>>>>>>>>>>> 10000-years cannot refute my GUR. ... >>>>>>>>>>>>>>>>>>>>>>>>>> --
"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) >>>>>>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>>>>> functions do not have side effects.
Whether or not it is construed as a side-effect does >>>>>>>>>>>>>>>>>> not matter it must be a mutation side-effect to >>>>>>>>>>>>>>>>>> (a)(b)(c)(d) or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or
expression is said to have a side effect if it modifies >>>>>>>>>>>>>>> some state variable value(s) outside its local
environment,
The second part is an inaccurate paraphrase of the first >>>>>>>>>>>>>> part.
which is to say if it has any observable effect
other than its primary effect of returning a value to >>>>>>>>>>>>>>> the invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to >>>>>>>>>>>>>>> the invoker disqualifies it from being a pure function. >>>>>>>>>>>>>>>
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H >>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its >>>>>>>>>>>>>> machine address of [0000135d] the very first time before >>>>>>>>>>>>>> the code at this address is emulated. Then H returns 0 to >>>>>>>>>>>>>> its caller: main().
Returning to main() is not returning to its invoker, P. >>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>> do not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second >>>>>>>>>>> time an *attempt* to call H is prevented than that is
equivalent to calling H and having H do something different >>>>>>>>>>> with side effects. This is just my opinion though as it
requires more thought and I am currently getting drunk on >>>>>>>>>>> gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion >>>>>>>>>> (a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could >>>>>>>>>> possibly escape the infinite recursion / infinitely recursive >>>>>>>>>> emulation.
Agree but refusing to analyse what P would have done if H
wasn't a simulating decider still makes what you've got
worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak) >>>>>>>>>
It is dead obvious to everyone (even Richard) that what P would >>>>>>>> have done if H was merely an x86 emulator and not a halt
deciding emulator.
The correct and complete x86 emulation of H(P,P) would never
reach its "ret" instruction thus making H a correct "not reach >>>>>>>> ret" / halt decider for P.
You need to think about a P that calls H but is non-pathological >>>>>>> halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here about
three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation of
the input to H(P,P) by H never reaches its "ret" instruction
thus never halts.
Try reading what I actually wrote:
void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}
How does your "decider" handle that P?
/Flibble
Removing the infinite loop does not make it non pathological.
As I have said donzens of times the infinite loop is unreachable.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](03) 8b4508 mov eax,[ebp+08]
[000013bc](01) 50 push eax
[000013bd](03) 8b4d08 mov ecx,[ebp+08]
[000013c0](01) 51 push ecx
[000013c1](05) e8e0fdffff call 000011a6
[000013c6](03) 83c408 add esp,+08
[000013c9](01) 5d pop ebp
[000013ca](01) c3 ret
Size in bytes:(0021) [000013ca]
_main()
[000013d6](01) 55 push ebp
[000013d7](02) 8bec mov ebp,esp
[000013d9](05) 68b6130000 push 000013b6
[000013de](05) 68b6130000 push 000013b6
[000013e3](05) e8befdffff call 000011a6
[000013e8](03) 83c408 add esp,+08
[000013eb](01) 50 push eax
[000013ec](05) 6827040000 push 00000427
[000013f1](05) e880f0ffff call 00000476
[000013f6](03) 83c408 add esp,+08
[000013f9](02) 33c0 xor eax,eax
[000013fb](01) 5d pop ebp
[000013fc](01) c3 ret
Size in bytes:(0039) [000013fc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000013d6][00102357][00000000] 55 push ebp
...[000013d7][00102357][00000000] 8bec mov ebp,esp
...[000013d9][00102353][000013b6] 68b6130000 push 000013b6
...[000013de][0010234f][000013b6] 68b6130000 push 000013b6
...[000013e3][0010234b][000013e8] e8befdffff call 000011a6
Begin Local Halt Decider Simulation Execution Trace Stored
at:21240b ...[000013b6][002123f7][002123fb] 55 push
ebp ...[000013b7][002123f7][002123fb] 8bec mov ebp,esp
...[000013b9][002123f7][002123fb] 8b4508 mov eax,[ebp+08]
...[000013bc][002123f3][000013b6] 50 push eax
...[000013bd][002123f3][000013b6] 8b4d08 mov ecx,[ebp+08]
...[000013c0][002123ef][000013b6] 51 push ecx
...[000013c1][002123eb][000013c6] e8e0fdffff call 000011a6
...[000013b6][0025ce1f][0025ce23] 55 push ebp
...[000013b7][0025ce1f][0025ce23] 8bec mov ebp,esp
...[000013b9][0025ce1f][0025ce23] 8b4508 mov eax,[ebp+08]
...[000013bc][0025ce1b][000013b6] 50 push eax
...[000013bd][0025ce1b][000013b6] 8b4d08 mov ecx,[ebp+08]
...[000013c0][0025ce17][000013b6] 51 push ecx
...[000013c1][0025ce13][000013c6] e8e0fdffff call 000011a6
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
So it gets the answer wrong. QED.
/Flibble
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
This is the culmination of the essence of more than five years worth
of full time work when I first discovered that a simulating halt
decider could correctly determine the halt status of the "impossible"
input:
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 that all [these] inputs (including pathological inputs) are
decided correctly.
It gets the answer wrong. QED.
/Flibble
On 6/17/2022 2:36 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:34:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 2:17 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:15:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 1:45 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 13:42:05 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500 >>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:Not at all, but you do seem to have that problem. >>>>>>>>>>>>>>>>>>>
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:
In computer programming, a pure function is a >>>>>>>>>>>>>>>>>>>>>> function that has the following properties: >>>>>>>>>>>>>>>>>>>>>>On 6/17/2022 8:39 AM, wij wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On Friday, 17 June 2022 at 19:29:37 UTC+8, >>>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
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. >>>>>>>>>>>>>>>>>>>>>>>>>>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.GUR already suggested such a halting >>>>>>>>>>>>>>>>>>>>>>>>>>> decider H cannot exist: >>>>>>>>>>>>>>>>>>>>>>>>>>>
*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 >>>>>>>>>>>>>>>>>>>>>>>>>>>
H(P,P)==0 means P(P) does not halt. >>>>>>>>>>>>>>>>>>>>>>>>>> That is a misconception. >>>>>>>>>>>>>>>>>>>>>>>>>>
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). >>>>>>>>>>>>>>>>>>>>>>>>>>>Copyright 2022 Pete Olcott >>>>>>>>>>>>>>>>>>>>>>>>>>
-----
Thanks to PO's years' tireless efforts >>>>>>>>>>>>>>>>>>>>>>>>>>> demonstrated even himself a genius in >>>>>>>>>>>>>>>>>>>>>>>>>>> 10000-years cannot refute my GUR. ... >>>>>>>>>>>>>>>>>>>>>>>>>> --
"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
>>>>>>>>>>>>>>>>>>>>>>
(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) >>>>>>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>>>>> functions do not have side effects.
Whether or not it is construed as a side-effect >>>>>>>>>>>>>>>>>> does not matter it must be a mutation side-effect >>>>>>>>>>>>>>>>>> to (a)(b)(c)(d) or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or >>>>>>>>>>>>>>> expression is said to have a side effect if it >>>>>>>>>>>>>>> modifies some state variable value(s) outside its >>>>>>>>>>>>>>> local environment,
The second part is an inaccurate paraphrase of the >>>>>>>>>>>>>> first part.
which is to say if it has any observable effect >>>>>>>>>>>>>>> other than its primary effect of returning a value to >>>>>>>>>>>>>>> the invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value >>>>>>>>>>>>>>> to the invoker disqualifies it from being a pure >>>>>>>>>>>>>>> function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>> [00001358](01) 50 push eax // push P >>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P >>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H >>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its >>>>>>>>>>>>>> machine address of [0000135d] the very first time >>>>>>>>>>>>>> before the code at this address is emulated. Then H >>>>>>>>>>>>>> returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P. >>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>> do not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second >>>>>>>>>>> time an *attempt* to call H is prevented than that is
equivalent to calling H and having H do something
different with side effects. This is just my opinion
though as it requires more thought and I am currently
getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite
recursion (a) calling the same function a second time with >>>>>>>>>> the same arguments and
(b) there are no instructions preceding this call that
could possibly escape the infinite recursion / infinitely >>>>>>>>>> recursive emulation.
Agree but refusing to analyse what P would have done if H
wasn't a simulating decider still makes what you've got
worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's
Peak)
It is dead obvious to everyone (even Richard) that what P
would have done if H was merely an x86 emulator and not a
halt deciding emulator.
The correct and complete x86 emulation of H(P,P) would never >>>>>>>> reach its "ret" instruction thus making H a correct "not
reach ret" / halt decider for P.
You need to think about a P that calls H but is
non-pathological halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here
about three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation of
the input to H(P,P) by H never reaches its "ret" instruction
thus never halts.
Try reading what I actually wrote:
void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}
How does your "decider" handle that P?
/Flibble
Removing the infinite loop does not make it non pathological.
As I have said donzens of times the infinite loop is unreachable.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](03) 8b4508 mov eax,[ebp+08]
[000013bc](01) 50 push eax
[000013bd](03) 8b4d08 mov ecx,[ebp+08]
[000013c0](01) 51 push ecx
[000013c1](05) e8e0fdffff call 000011a6
[000013c6](03) 83c408 add esp,+08
[000013c9](01) 5d pop ebp
[000013ca](01) c3 ret
Size in bytes:(0021) [000013ca]
_main()
[000013d6](01) 55 push ebp
[000013d7](02) 8bec mov ebp,esp
[000013d9](05) 68b6130000 push 000013b6
[000013de](05) 68b6130000 push 000013b6
[000013e3](05) e8befdffff call 000011a6
[000013e8](03) 83c408 add esp,+08
[000013eb](01) 50 push eax
[000013ec](05) 6827040000 push 00000427
[000013f1](05) e880f0ffff call 00000476
[000013f6](03) 83c408 add esp,+08
[000013f9](02) 33c0 xor eax,eax
[000013fb](01) 5d pop ebp
[000013fc](01) c3 ret
Size in bytes:(0039) [000013fc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000013d6][00102357][00000000] 55 push ebp
...[000013d7][00102357][00000000] 8bec mov ebp,esp
...[000013d9][00102353][000013b6] 68b6130000 push 000013b6
...[000013de][0010234f][000013b6] 68b6130000 push 000013b6
...[000013e3][0010234b][000013e8] e8befdffff call 000011a6
Begin Local Halt Decider Simulation Execution Trace Stored
at:21240b ...[000013b6][002123f7][002123fb] 55 push
ebp ...[000013b7][002123f7][002123fb] 8bec mov ebp,esp
...[000013b9][002123f7][002123fb] 8b4508 mov
eax,[ebp+08] ...[000013bc][002123f3][000013b6] 50
push eax ...[000013bd][002123f3][000013b6] 8b4d08 mov
ecx,[ebp+08] ...[000013c0][002123ef][000013b6] 51
push ecx ...[000013c1][002123eb][000013c6] e8e0fdffff call
000011a6 ...[000013b6][0025ce1f][0025ce23] 55 push
ebp ...[000013b7][0025ce1f][0025ce23] 8bec mov ebp,esp
...[000013b9][0025ce1f][0025ce23] 8b4508 mov
eax,[ebp+08] ...[000013bc][0025ce1b][000013b6] 50
push eax ...[000013bd][0025ce1b][000013b6] 8b4d08 mov
ecx,[ebp+08] ...[000013c0][0025ce17][000013b6] 51
push ecx ...[000013c1][0025ce13][000013c6] e8e0fdffff call
000011a6 Local Halt Decider: Infinite Recursion Detected
Simulation Stopped
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
So it gets the answer wrong. QED.
/Flibble
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
This is the culmination of the essence of more than five years
worth of full time work when I first discovered that a simulating
halt decider could correctly determine the halt status of the
"impossible" input:
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 that all [these] inputs (including pathological inputs) are
decided correctly.
It gets the answer wrong. QED.
/Flibble
It takes an actual competent software engineer to understand that the complete and correct x86 emulation of the input to H(Px, Px) would
never reach is "ret" instruction.
On Fri, 17 Jun 2022 14:42:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 2:36 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:34:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 2:17 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:15:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 1:45 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 13:42:05 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:12:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:56 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:49:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 10:37 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500 >>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>Not at all, but you do seem to have that problem. >>>>>>>>>>>>>>>>>>>>>
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:
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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>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.GUR already suggested such a halting >>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider H cannot exist: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
*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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H(P,P)==0 means P(P) does not halt. >>>>>>>>>>>>>>>>>>>>>>>>>>>> That is a misconception. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
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). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>Copyright 2022 Pete Olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----
Thanks to PO's years' tireless efforts >>>>>>>>>>>>>>>>>>>>>>>>>>>>> demonstrated even himself a genius in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 10000-years cannot refute my GUR. ... >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
"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) >>>>>>>>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>>>>>>> functions do not have side effects.
Whether or not it is construed as a side-effect >>>>>>>>>>>>>>>>>>>> does not matter it must be a mutation side-effect >>>>>>>>>>>>>>>>>>>> to (a)(b)(c)(d) or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or >>>>>>>>>>>>>>>>> expression is said to have a side effect if it >>>>>>>>>>>>>>>>> modifies some state variable value(s) outside its >>>>>>>>>>>>>>>>> local environment,
The second part is an inaccurate paraphrase of the >>>>>>>>>>>>>>>> first part.
which is to say if it has any observable effect >>>>>>>>>>>>>>>>> other than its primary effect of returning a value to >>>>>>>>>>>>>>>>> the invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value >>>>>>>>>>>>>>>>> to the invoker disqualifies it from being a pure >>>>>>>>>>>>>>>>> function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>> [00001358](01) 50 push eax // push P >>>>>>>>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>> [0000135c](01) 51 push ecx // push P >>>>>>>>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H >>>>>>>>>>>>>>>> [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its >>>>>>>>>>>>>>>> machine address of [0000135d] the very first time >>>>>>>>>>>>>>>> before the code at this address is emulated. Then H >>>>>>>>>>>>>>>> returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P. >>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure functions >>>>>>>>>>>>>>> do not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the second >>>>>>>>>>>>> time an *attempt* to call H is prevented than that is >>>>>>>>>>>>> equivalent to calling H and having H do something
different with side effects. This is just my opinion >>>>>>>>>>>>> though as it requires more thought and I am currently >>>>>>>>>>>>> getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite
recursion (a) calling the same function a second time with >>>>>>>>>>>> the same arguments and
(b) there are no instructions preceding this call that >>>>>>>>>>>> could possibly escape the infinite recursion / infinitely >>>>>>>>>>>> recursive emulation.
Agree but refusing to analyse what P would have done if H >>>>>>>>>>> wasn't a simulating decider still makes what you've got
worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's >>>>>>>>>>> Peak)
It is dead obvious to everyone (even Richard) that what P
would have done if H was merely an x86 emulator and not a
halt deciding emulator.
The correct and complete x86 emulation of H(P,P) would never >>>>>>>>>> reach its "ret" instruction thus making H a correct "not
reach ret" / halt decider for P.
You need to think about a P that calls H but is
non-pathological halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here
about three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation of >>>>>>>> the input to H(P,P) by H never reaches its "ret" instruction
thus never halts.
Try reading what I actually wrote:
void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}
How does your "decider" handle that P?
/Flibble
Removing the infinite loop does not make it non pathological.
As I have said donzens of times the infinite loop is unreachable.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](03) 8b4508 mov eax,[ebp+08]
[000013bc](01) 50 push eax
[000013bd](03) 8b4d08 mov ecx,[ebp+08]
[000013c0](01) 51 push ecx
[000013c1](05) e8e0fdffff call 000011a6
[000013c6](03) 83c408 add esp,+08
[000013c9](01) 5d pop ebp
[000013ca](01) c3 ret
Size in bytes:(0021) [000013ca]
_main()
[000013d6](01) 55 push ebp
[000013d7](02) 8bec mov ebp,esp
[000013d9](05) 68b6130000 push 000013b6
[000013de](05) 68b6130000 push 000013b6
[000013e3](05) e8befdffff call 000011a6
[000013e8](03) 83c408 add esp,+08
[000013eb](01) 50 push eax
[000013ec](05) 6827040000 push 00000427
[000013f1](05) e880f0ffff call 00000476
[000013f6](03) 83c408 add esp,+08
[000013f9](02) 33c0 xor eax,eax
[000013fb](01) 5d pop ebp
[000013fc](01) c3 ret
Size in bytes:(0039) [000013fc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000013d6][00102357][00000000] 55 push ebp
...[000013d7][00102357][00000000] 8bec mov ebp,esp
...[000013d9][00102353][000013b6] 68b6130000 push 000013b6
...[000013de][0010234f][000013b6] 68b6130000 push 000013b6
...[000013e3][0010234b][000013e8] e8befdffff call 000011a6
Begin Local Halt Decider Simulation Execution Trace Stored
at:21240b ...[000013b6][002123f7][002123fb] 55 push
ebp ...[000013b7][002123f7][002123fb] 8bec mov ebp,esp
...[000013b9][002123f7][002123fb] 8b4508 mov
eax,[ebp+08] ...[000013bc][002123f3][000013b6] 50
push eax ...[000013bd][002123f3][000013b6] 8b4d08 mov
ecx,[ebp+08] ...[000013c0][002123ef][000013b6] 51
push ecx ...[000013c1][002123eb][000013c6] e8e0fdffff call
000011a6 ...[000013b6][0025ce1f][0025ce23] 55 push
ebp ...[000013b7][0025ce1f][0025ce23] 8bec mov ebp,esp
...[000013b9][0025ce1f][0025ce23] 8b4508 mov
eax,[ebp+08] ...[000013bc][0025ce1b][000013b6] 50
push eax ...[000013bd][0025ce1b][000013b6] 8b4d08 mov
ecx,[ebp+08] ...[000013c0][0025ce17][000013b6] 51
push ecx ...[000013c1][0025ce13][000013c6] e8e0fdffff call
000011a6 Local Halt Decider: Infinite Recursion Detected
Simulation Stopped
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
So it gets the answer wrong. QED.
/Flibble
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
This is the culmination of the essence of more than five years
worth of full time work when I first discovered that a simulating
halt decider could correctly determine the halt status of the
"impossible" input:
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 that all [these] inputs (including pathological inputs) are
decided correctly.
It gets the answer wrong. QED.
/Flibble
It takes an actual competent software engineer to understand that the
complete and correct x86 emulation of the input to H(Px, Px) would
never reach is "ret" instruction.
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
On 6/17/2022 2:43 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:42:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 2:36 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:34:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 2:17 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:15:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 1:45 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 13:42:05 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 11:12:31 -0500"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,
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:It doesn't count according to who?
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:Not at all, but you do seem to have that >>>>>>>>>>>>>>>>>>>>> problem.
In computer programming, a pure function is a >>>>>>>>>>>>>>>>>>>>>>>> function that has the following properties: >>>>>>>>>>>>>>>>>>>>>>>>So my other reply for why your H is not a >>>>>>>>>>>>>>>>>>>>>>>>> pure function for any accepted definition >>>>>>>>>>>>>>>>>>>>>>>>> of the term.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. >>>>>>>>>>>>>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>GUR suggests no halting decider can exist. >>>>>>>>>>>>>>>>>>>>>>>>>>> You just confirms it by not able to >>>>>>>>>>>>>>>>>>>>>>>>>>> provide POOH to test/review. >>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>*computation that halts* … the Turing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine will halt whenever it enters a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state. (Linz:1990:234) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>GUR already suggested such a halting >>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider H cannot exist: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H(P,P)==0 means P(P) does not halt. >>>>>>>>>>>>>>>>>>>>>>>>>>>> That is a misconception. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
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). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----Copyright 2022 Pete Olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>
Thanks to PO's years' tireless efforts >>>>>>>>>>>>>>>>>>>>>>>>>>>>> demonstrated even himself a genius in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 10000-years cannot refute my GUR. ... >>>>>>>>>>>>>>>>>>>>>>>>>>>> --
"Talent hits a target no one else can >>>>>>>>>>>>>>>>>>>>>>>>>>>> hit; Genius hits a target no one else >>>>>>>>>>>>>>>>>>>>>>>>>>>> can see." Arthur Schopenhauer >>>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>>>>
/Flibble
>>>>>>>>>>>>>>>>>>>>>>>>
(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) >>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>
The above definition of pure functions. >>>>>>>>>>>>>>>>>
The second part is an inaccurate paraphrase of the >>>>>>>>>>>>>>>> first part.
which is to say if it has any observable effect >>>>>>>>>>>>>>>>> other than its primary effect of returning a value >>>>>>>>>>>>>>>>> to the invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value >>>>>>>>>>>>>>>>> to the invoker disqualifies it from being a pure >>>>>>>>>>>>>>>>> function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P)); >>>>>>>>>>>>>>>> }
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>> [00001358](01) 50 push eax // >>>>>>>>>>>>>>>> push P [00001359](03) 8b4d08 mov
ecx,[ebp+08] [0000135c](01) 51 push >>>>>>>>>>>>>>>> ecx // push P [0000135d](05) e840feffff >>>>>>>>>>>>>>>> call 000011a2 // call H [00001362](03) 83c408 >>>>>>>>>>>>>>>> add esp,+08 [00001365](02) 85c0 test >>>>>>>>>>>>>>>> eax,eax [00001367](02) 7402 jz 0000136b >>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369 >>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its >>>>>>>>>>>>>>>> machine address of [0000135d] the very first time >>>>>>>>>>>>>>>> before the code at this address is emulated. Then H >>>>>>>>>>>>>>>> returns 0 to its caller: main().
Returning to main() is not returning to its invoker, >>>>>>>>>>>>>>> P.
Again:
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>> functions do not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
If your claim is that H is only called once and the >>>>>>>>>>>>> second time an *attempt* to call H is prevented than >>>>>>>>>>>>> that is equivalent to calling H and having H do
something different with side effects. This is just my >>>>>>>>>>>>> opinion though as it requires more thought and I am >>>>>>>>>>>>> currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite
recursion (a) calling the same function a second time >>>>>>>>>>>> with the same arguments and
(b) there are no instructions preceding this call that >>>>>>>>>>>> could possibly escape the infinite recursion / infinitely >>>>>>>>>>>> recursive emulation.
Agree but refusing to analyse what P would have done if H >>>>>>>>>>> wasn't a simulating decider still makes what you've got >>>>>>>>>>> worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's >>>>>>>>>>> Peak)
It is dead obvious to everyone (even Richard) that what P >>>>>>>>>> would have done if H was merely an x86 emulator and not a >>>>>>>>>> halt deciding emulator.
The correct and complete x86 emulation of H(P,P) would
never reach its "ret" instruction thus making H a correct >>>>>>>>>> "not reach ret" / halt decider for P.
You need to think about a P that calls H but is
non-pathological halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here
about three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation
of the input to H(P,P) by H never reaches its "ret"
instruction thus never halts.
Try reading what I actually wrote:
void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}
How does your "decider" handle that P?
/Flibble
Removing the infinite loop does not make it non pathological.
As I have said donzens of times the infinite loop is
unreachable.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](03) 8b4508 mov eax,[ebp+08]
[000013bc](01) 50 push eax
[000013bd](03) 8b4d08 mov ecx,[ebp+08]
[000013c0](01) 51 push ecx
[000013c1](05) e8e0fdffff call 000011a6
[000013c6](03) 83c408 add esp,+08
[000013c9](01) 5d pop ebp
[000013ca](01) c3 ret
Size in bytes:(0021) [000013ca]
_main()
[000013d6](01) 55 push ebp
[000013d7](02) 8bec mov ebp,esp
[000013d9](05) 68b6130000 push 000013b6
[000013de](05) 68b6130000 push 000013b6
[000013e3](05) e8befdffff call 000011a6
[000013e8](03) 83c408 add esp,+08
[000013eb](01) 50 push eax
[000013ec](05) 6827040000 push 00000427
[000013f1](05) e880f0ffff call 00000476
[000013f6](03) 83c408 add esp,+08
[000013f9](02) 33c0 xor eax,eax
[000013fb](01) 5d pop ebp
[000013fc](01) c3 ret
Size in bytes:(0039) [000013fc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000013d6][00102357][00000000] 55 push ebp
...[000013d7][00102357][00000000] 8bec mov ebp,esp
...[000013d9][00102353][000013b6] 68b6130000 push 000013b6
...[000013de][0010234f][000013b6] 68b6130000 push 000013b6
...[000013e3][0010234b][000013e8] e8befdffff call 000011a6
Begin Local Halt Decider Simulation Execution Trace Stored
at:21240b ...[000013b6][002123f7][002123fb] 55
push ebp ...[000013b7][002123f7][002123fb] 8bec mov
ebp,esp ...[000013b9][002123f7][002123fb] 8b4508 mov
eax,[ebp+08] ...[000013bc][002123f3][000013b6] 50
push eax ...[000013bd][002123f3][000013b6] 8b4d08 mov
ecx,[ebp+08] ...[000013c0][002123ef][000013b6] 51
push ecx ...[000013c1][002123eb][000013c6] e8e0fdffff call
000011a6 ...[000013b6][0025ce1f][0025ce23] 55 push
ebp ...[000013b7][0025ce1f][0025ce23] 8bec mov
ebp,esp ...[000013b9][0025ce1f][0025ce23] 8b4508 mov
eax,[ebp+08] ...[000013bc][0025ce1b][000013b6] 50
push eax ...[000013bd][0025ce1b][000013b6] 8b4d08 mov
ecx,[ebp+08] ...[000013c0][0025ce17][000013b6] 51
push ecx ...[000013c1][0025ce13][000013c6] e8e0fdffff call
000011a6 Local Halt Decider: Infinite Recursion Detected
Simulation Stopped
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
So it gets the answer wrong. QED.
/Flibble
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
This is the culmination of the essence of more than five years
worth of full time work when I first discovered that a simulating
halt decider could correctly determine the halt status of the
"impossible" input:
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 that all [these] inputs (including pathological inputs) are
decided correctly.
It gets the answer wrong. QED.
/Flibble
It takes an actual competent software engineer to understand that
the complete and correct x86 emulation of the input to H(Px, Px)
would never reach is "ret" instruction.
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
In other words when I told you that the actual issued is infinitely recursive emulation 150 times you made sure to always ignore
everything that I said.
On Fri, 17 Jun 2022 14:56:08 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 2:43 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:42:45 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 2:36 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:34:12 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 2:17 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 14:15:04 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 1:45 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 13:42:05 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:14 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:33:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:22 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:16:15 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:14 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 11:12:31 -0500"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,
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: >>>>>>>>>>>>>>>>>>>>>>>It doesn't count according to who?
On 6/17/2022 10:37 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On Fri, 17 Jun 2022 10:33:59 -0500 >>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>Not at all, but you do seem to have that >>>>>>>>>>>>>>>>>>>>>>> problem.
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:So my other reply for why your H is not a >>>>>>>>>>>>>>>>>>>>>>>>>>> pure function for any accepted definition >>>>>>>>>>>>>>>>>>>>>>>>>>> of the term.
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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>GUR suggests no halting decider can exist. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> You just confirms it by not able to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide POOH to test/review. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>*computation that halts* … the Turing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine will halt whenever it enters a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> final state. (Linz:1990:234) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>GUR already suggested such a halting >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider H cannot exist: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H(P,P)==0 means P(P) does not halt. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is a misconception. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----Copyright 2022 Pete Olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Thanks to PO's years' tireless efforts >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> demonstrated even himself a genius in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 10000-years cannot refute my GUR. ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
"Talent hits a target no one else can >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hit; Genius hits a target no one else >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can see." Arthur Schopenhauer >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>>>>>>>
/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) >>>>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>>>
The above definition of pure functions. >>>>>>>>>>>>>>>>>>>
The second part is an inaccurate paraphrase of the >>>>>>>>>>>>>>>>>> first part.
which is to say if it has any observable effect >>>>>>>>>>>>>>>>>>> other than its primary effect of returning a value >>>>>>>>>>>>>>>>>>> to the invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value >>>>>>>>>>>>>>>>>>> to the invoker disqualifies it from being a pure >>>>>>>>>>>>>>>>>>> function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P)); >>>>>>>>>>>>>>>>>> }
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp >>>>>>>>>>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>> [00001358](01) 50 push eax // >>>>>>>>>>>>>>>>>> push P [00001359](03) 8b4d08 mov >>>>>>>>>>>>>>>>>> ecx,[ebp+08] [0000135c](01) 51 push >>>>>>>>>>>>>>>>>> ecx // push P [0000135d](05) e840feffff >>>>>>>>>>>>>>>>>> call 000011a2 // call H [00001362](03) 83c408 >>>>>>>>>>>>>>>>>> add esp,+08 [00001365](02) 85c0 test >>>>>>>>>>>>>>>>>> eax,eax [00001367](02) 7402 jz 0000136b >>>>>>>>>>>>>>>>>> [00001369](02) ebfe jmp 00001369 >>>>>>>>>>>>>>>>>> [0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its >>>>>>>>>>>>>>>>>> machine address of [0000135d] the very first time >>>>>>>>>>>>>>>>>> before the code at this address is emulated. Then H >>>>>>>>>>>>>>>>>> returns 0 to its caller: main().
Returning to main() is not returning to its invoker, >>>>>>>>>>>>>>>>> P.
Again:
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>>> functions do not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P)); >>>>>>>>>>>>>>>> }
If your claim is that H is only called once and the >>>>>>>>>>>>>>> second time an *attempt* to call H is prevented than >>>>>>>>>>>>>>> that is equivalent to calling H and having H do
something different with side effects. This is just my >>>>>>>>>>>>>>> opinion though as it requires more thought and I am >>>>>>>>>>>>>>> currently getting drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite >>>>>>>>>>>>>> recursion (a) calling the same function a second time >>>>>>>>>>>>>> with the same arguments and
(b) there are no instructions preceding this call that >>>>>>>>>>>>>> could possibly escape the infinite recursion / infinitely >>>>>>>>>>>>>> recursive emulation.
Agree but refusing to analyse what P would have done if H >>>>>>>>>>>>> wasn't a simulating decider still makes what you've got >>>>>>>>>>>>> worthless as far as the Halting Problem is concerned. >>>>>>>>>>>>>
/Flibble (getting drunk, possibly not quite at Ballmer's >>>>>>>>>>>>> Peak)
It is dead obvious to everyone (even Richard) that what P >>>>>>>>>>>> would have done if H was merely an x86 emulator and not a >>>>>>>>>>>> halt deciding emulator.
The correct and complete x86 emulation of H(P,P) would >>>>>>>>>>>> never reach its "ret" instruction thus making H a correct >>>>>>>>>>>> "not reach ret" / halt decider for P.
You need to think about a P that calls H but is
non-pathological halting (no infinite loop).
/Flibble
I have already done that and posted all of the details here >>>>>>>>>> about three dozen times.
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1(P, P));
}
It remains true that the correct and complete x86 emulation >>>>>>>>>> of the input to H(P,P) by H never reaches its "ret"
instruction thus never halts.
Try reading what I actually wrote:
void P(ptr x)
{
H(x, x); // ignore result
return; // halt
}
How does your "decider" handle that P?
/Flibble
Removing the infinite loop does not make it non pathological.
As I have said donzens of times the infinite loop is
unreachable.
void Px(u32 x)
{
H(x, x);
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}
_Px()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](03) 8b4508 mov eax,[ebp+08]
[000013bc](01) 50 push eax
[000013bd](03) 8b4d08 mov ecx,[ebp+08]
[000013c0](01) 51 push ecx
[000013c1](05) e8e0fdffff call 000011a6
[000013c6](03) 83c408 add esp,+08
[000013c9](01) 5d pop ebp
[000013ca](01) c3 ret
Size in bytes:(0021) [000013ca]
_main()
[000013d6](01) 55 push ebp
[000013d7](02) 8bec mov ebp,esp
[000013d9](05) 68b6130000 push 000013b6
[000013de](05) 68b6130000 push 000013b6
[000013e3](05) e8befdffff call 000011a6
[000013e8](03) 83c408 add esp,+08
[000013eb](01) 50 push eax
[000013ec](05) 6827040000 push 00000427
[000013f1](05) e880f0ffff call 00000476
[000013f6](03) 83c408 add esp,+08
[000013f9](02) 33c0 xor eax,eax
[000013fb](01) 5d pop ebp
[000013fc](01) c3 ret
Size in bytes:(0039) [000013fc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000013d6][00102357][00000000] 55 push ebp
...[000013d7][00102357][00000000] 8bec mov ebp,esp
...[000013d9][00102353][000013b6] 68b6130000 push 000013b6 >>>>>>>> ...[000013de][0010234f][000013b6] 68b6130000 push 000013b6 >>>>>>>> ...[000013e3][0010234b][000013e8] e8befdffff call 000011a6 >>>>>>>>
Begin Local Halt Decider Simulation Execution Trace Stored
at:21240b ...[000013b6][002123f7][002123fb] 55
push ebp ...[000013b7][002123f7][002123fb] 8bec mov >>>>>>>> ebp,esp ...[000013b9][002123f7][002123fb] 8b4508 mov
eax,[ebp+08] ...[000013bc][002123f3][000013b6] 50
push eax ...[000013bd][002123f3][000013b6] 8b4d08 mov >>>>>>>> ecx,[ebp+08] ...[000013c0][002123ef][000013b6] 51
push ecx ...[000013c1][002123eb][000013c6] e8e0fdffff call >>>>>>>> 000011a6 ...[000013b6][0025ce1f][0025ce23] 55 push >>>>>>>> ebp ...[000013b7][0025ce1f][0025ce23] 8bec mov
ebp,esp ...[000013b9][0025ce1f][0025ce23] 8b4508 mov
eax,[ebp+08] ...[000013bc][0025ce1b][000013b6] 50
push eax ...[000013bd][0025ce1b][000013b6] 8b4d08 mov >>>>>>>> ecx,[ebp+08] ...[000013c0][0025ce17][000013b6] 51
push ecx ...[000013c1][0025ce13][000013c6] e8e0fdffff call >>>>>>>> 000011a6 Local Halt Decider: Infinite Recursion Detected
Simulation Stopped
...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427 >>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476 >>>>>>>> Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)
So it gets the answer wrong. QED.
/Flibble
comp.theory:
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:
This is the culmination of the essence of more than five years
worth of full time work when I first discovered that a simulating
halt decider could correctly determine the halt status of the
"impossible" input:
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 that all [these] inputs (including pathological inputs) are
decided correctly.
It gets the answer wrong. QED.
/Flibble
It takes an actual competent software engineer to understand that
the complete and correct x86 emulation of the input to H(Px, Px)
would never reach is "ret" instruction.
It gets the answer wrong, i.e. input has not been decided correctly.
QED.
/Flibble
In other words when I told you that the actual issued is infinitely
recursive emulation 150 times you made sure to always ignore
everything that I said.
Px will always halt with a non-simulating "decider"; your "simulating decider" behaves differently, getting the answer wrong. QED.
/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. ...
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:That is a misconception.
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.
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.
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:That is a misconception.
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.
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.
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:That is a misconception.
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.
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
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:Aborting the simulation is a side effect; pure functions do not have
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:That is a misconception.
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.
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
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 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:Aborting the simulation is a side effect; pure functions do not >>>>>>>> have side effects.
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.That is a misconception.
*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.
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>> --
"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
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions do not
have side effects.
Whether or not it is construed as a side-effect does not matter it
must be a mutation side-effect to (a)(b)(c)(d) or it does not
count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is said to
have a side effect if it modifies some state variable value(s) outside
its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the invoker of
the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the invoker
disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
ize in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine address of [0000135d] the very first time before the code at this address is
emulated. Then H returns 0 to its caller: main().
On 6/17/2022 12:04 PM, Mr Flibble wrote:
Agree but refusing to analyse what P would have done if H wasn't a
simulating decider still makes what you've got worthless as far as the
Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would have
done if H was merely an x86 emulator and not a halt deciding emulator.
The correct and complete x86 emulation of H(P,P) would never reach its
"ret" instruction thus making H a correct "not reach ret" / halt decider
for P.
I already proved that they do many dozen of times.
The reason that I stopped talking to Richard is that he could not
remember from one post to the next what I said in the preceding post.
On 6/17/2022 11:41 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:I might be on the spectrum; probably got Asperger's; whilst as far as
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:Aborting the simulation is a side effect; pure functions do >>>>>>>>>>>> not have side effects.
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: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.
On 6/17/2022 8:39 AM, wij wrote:
On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott >>>>>>>>>>>>>>>>>> wrote:That is a misconception.
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.
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. >>>>>>>>>>>>>>>
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
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions do >>>>>>>>>> not have side effects.
Whether or not it is construed as a side-effect does not matter >>>>>>>>> it must be a mutation side-effect to (a)(b)(c)(d) or it does >>>>>>>>> not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is said >>>>>> to have a side effect if it modifies some state variable value(s)
outside its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the invoker
of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at this
address is emulated. Then H returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not have
side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
the topic under discussion is concerned, you've got nothing.
/Flibble
Then that may explain why you didn't notice that main calls H(P,P);
When H returns to its caller it must return to main().
main() and not P is the invoker of H(P,P).
On 6/17/2022 11:51 AM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:If your claim is that H is only called once and the second time an
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:Aborting the simulation is a side effect; pure functions do >>>>>>>>>>>> not have side effects.
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: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.
On 6/17/2022 8:39 AM, wij wrote:
On Friday, 17 June 2022 at 19:29:37 UTC+8, olcott >>>>>>>>>>>>>>>>>> wrote:That is a misconception.
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.
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. >>>>>>>>>>>>>>>
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
/Flibble
You have a reading comprehension problem.
If H does not have (a)(b)(c)(d) then
H has no mutation side effect to (a)(b)(c)(d)
Not at all, but you do seem to have that problem.
Again:
Aborting the simulation is a side effect; pure functions do >>>>>>>>>> not have side effects.
Whether or not it is construed as a side-effect does not matter >>>>>>>>> it must be a mutation side-effect to (a)(b)(c)(d) or it does >>>>>>>>> not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression is said >>>>>> to have a side effect if it modifies some state variable value(s)
outside its local environment,
The second part is an inaccurate paraphrase of the first part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the invoker
of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science)
"any observable effect"
Aborting the simulation instead of returning a value to the
invoker disqualifies it from being a pure function.
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its machine
address of [0000135d] the very first time before the code at this
address is emulated. Then H returns 0 to its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do not have
side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
*attempt* to call H is prevented than that is equivalent to calling H
and having H do something different with side effects. This is just my
opinion though as it requires more thought and I am currently getting
drunk on gin and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same arguments and
(b) there are no instructions preceding this call that could possibly
escape the infinite recursion / infinitely recursive emulation.
On 6/17/2022 1:08 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 19:04:51 +0100
Mr Flibble <flibble@reddwarf.jmc> wrote:
On Fri, 17 Jun 2022 18:14:48 +0100
Mr Flibble <flibble@reddwarf.jmc> wrote:
On Fri, 17 Jun 2022 12:13:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 12:04 PM, Mr Flibble wrote:
On Fri, 17 Jun 2022 11:59:53 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:51 AM, Mr Flibble wrote:Agree but refusing to analyse what P would have done if H
On Fri, 17 Jun 2022 11:38:29 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/17/2022 11:36 AM, Mr Flibble wrote:If your claim is that H is only called once and the second
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:Not at all, but you do seem to have that problem. >>>>>>>>>>>>>>>>
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 -0500Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>>>> functions do not have side effects.
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.Copyright 2022 Pete Olcott
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. ... >>>>>>>>>>>>>>>>>>>>>>> --
"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
/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) >>>>>>>>>>>>>>>>
Again:
Aborting the simulation is a side effect; pure >>>>>>>>>>>>>>>> functions do not have side effects.
Whether or not it is construed as a side-effect does >>>>>>>>>>>>>>> not matter it must be a mutation side-effect to
(a)(b)(c)(d) or it does not count.
It doesn't count according to who?
The above definition of pure functions.
"In computer science, an operation, function or expression >>>>>>>>>>>> is said to have a side effect if it modifies some state >>>>>>>>>>>> variable value(s) outside its local environment,
The second part is an inaccurate paraphrase of the first >>>>>>>>>>> part.
which is to say if it has any observable effect
other than its primary effect of returning a value to the >>>>>>>>>>>> invoker of the operation." --
https://en.wikipedia.org/wiki/Side_effect_(computer_science) >>>>>>>>>>>>
"any observable effect"
Aborting the simulation instead of returning a value to >>>>>>>>>>>> the invoker disqualifies it from being a pure function. >>>>>>>>>>>>
/Flibble
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>> [00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>> [0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H >>>>>>>>>>> [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax >>>>>>>>>>> [00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369 >>>>>>>>>>> [0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
H aborts its x86 emulation of P as soon P reaches its
machine address of [0000135d] the very first time before >>>>>>>>>>> the code at this address is emulated. Then H returns 0 to >>>>>>>>>>> its caller: main().
Returning to main() is not returning to its invoker, P.
Again:
Aborting the simulation is a side effect; pure functions do >>>>>>>>>> not have side effects.
/Flibble
Do you have ADD?
int main()
{
Output("Input_Halts = ", H(P, P));
}
time an *attempt* to call H is prevented than that is
equivalent to calling H and having H do something different
with side effects. This is just my opinion though as it
requires more thought and I am currently getting drunk on gin
and tonics.
/Flibble
It is obviously the exact same pattern as infinite recursion
(a) calling the same function a second time with the same
arguments and
(b) there are no instructions preceding this call that could
possibly escape the infinite recursion / infinitely recursive
emulation.
wasn't a simulating decider still makes what you've got
worthless as far as the Halting Problem is concerned.
/Flibble (getting drunk, possibly not quite at Ballmer's Peak)
It is dead obvious to everyone (even Richard) that what P would
have done if H was merely an x86 emulator and not a halt deciding
emulator.
The correct and complete x86 emulation of H(P,P) would never reach
its "ret" instruction thus making H a correct "not reach ret" /
halt decider for P.
You need to think about a P that calls H but is non-pathological
halting (no infinite loop).
Your assumption that any program that calls H is also pathological is
a flawed one. I have said before that all you have is a simulation
detector and not a halt decider: simulating halt deciders cannot
decide non-pathological non-halting programs in finite time so are not
actually deciders.
The question then becomes is a simulation detector (rather than a halt
decider) sufficient to refute proofs based on the [Strachey 1965]
impossible program? I cannot answer that question as I am unfamiliar
with the proofs.
/Flibble
[Strachey 1965] is merely P that takes no arguments and H that takes one argument.
void P0()
{
if (H0((u32)P0))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H0((u32)P0));
}
_P0()
[00001396](01) 55 push ebp
[00001397](02) 8bec mov ebp,esp
[00001399](05) 6896130000 push 00001396
[0000139e](05) e813fdffff call 000010b6
[000013a3](03) 83c404 add esp,+04
[000013a6](02) 85c0 test eax,eax
[000013a8](02) 7402 jz 000013ac
[000013aa](02) ebfe jmp 000013aa
[000013ac](01) 5d pop ebp
[000013ad](01) c3 ret
Size in bytes:(0024) [000013ad]
_main()
[000013b6](01) 55 push ebp
[000013b7](02) 8bec mov ebp,esp
[000013b9](05) 6896130000 push 00001396
[000013be](05) e8f3fcffff call 000010b6
[000013c3](03) 83c404 add esp,+04
[000013c6](01) 50 push eax
[000013c7](05) 6827040000 push 00000427
[000013cc](05) e8a5f0ffff call 00000476
[000013d1](03) 83c408 add esp,+08
[000013d4](02) 33c0 xor eax,eax
[000013d6](01) 5d pop ebp
[000013d7](01) c3 ret
Size in bytes:(0034) [000013d7]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= ...[000013b6][0010230c][00000000] 55 push ebp ...[000013b7][0010230c][00000000] 8bec mov ebp,esp ...[000013b9][00102308][00001396] 6896130000 push 00001396 ...[000013be][00102304][000013c3] e8f3fcffff call 000010b6
Begin Local Halt Decider Simulation Execution Trace Stored at:2123c0 ...[00001396][002123b0][002123b4] 55 push ebp ...[00001397][002123b0][002123b4] 8bec mov ebp,esp ...[00001399][002123ac][00001396] 6896130000 push 00001396 ...[0000139e][002123a8][000013a3] e813fdffff call 000010b6 ...[00001396][0025cdd8][0025cddc] 55 push ebp ...[00001397][0025cdd8][0025cddc] 8bec mov ebp,esp ...[00001399][0025cdd4][00001396] 6896130000 push 00001396 ...[0000139e][0025cdd0][000013a3] e813fdffff call 000010b6
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[000013c3][0010230c][00000000] 83c404 add esp,+04 ...[000013c6][00102308][00000000] 50 push eax ...[000013c7][00102304][00000427] 6827040000 push 00000427 ---[000013cc][00102304][00000427] e8a5f0ffff call 00000476 Input_Halts = 0
...[000013d1][0010230c][00000000] 83c408 add esp,+08 ...[000013d4][0010230c][00000000] 33c0 xor eax,eax ...[000013d6][00102310][00100000] 5d pop ebp ...[000013d7][00102314][00000004] c3 ret
Number of Instructions Executed(11031)
On 6/17/2022 10:06 AM, wij wrote:
On Friday, 17 June 2022 at 22:51:15 UTC+8, olcott wrote:
It took me six months to figure out how to transform H(P,P) into a pure
function of its inputs. I did not release the code before because I knew >>> that its use of static local data would have been rejected. With this
update to H I will be able to publish the code.
H recognizes that P is calling itself with its same arguments that it
was called with and there are no instructions preceding this call that
could possibly escape infinitely recursive emulation so H aborts its
emulation of P before P even makes its first call to H.
Without even looking at the code competent software engineers will be
able to verify that the above H would correctly determine that that is
input is non-halting as a pure function of this input.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
What you say is irrelevant.
Reviewers investigate the 'H', an algorithm that a computer can execute,
not Peter Olcltt's Oral Halting decider.
H knows its own machine address and on this basis
H recognizes that P is calling itself with its same arguments that it
was called with and there are no instructions preceding this call that
could possibly escape infinitely recursive emulation so H aborts its emulation of P before P even makes its first call to H.
Every competent software engineer can verify that H(P,P)==0 as a pure function of its inputs according the the above algorithm.
The irrefutable fact is clear: GUR cannot be violated, you don't have a
real POOH for test/review.
On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
When a simulating halt decider rejects all inputs as non-haltingYes.
whenever it correctly detects that its correct and complete simulation
of its input would never reach the final state of this input then all
[these] inputs (including pathological inputs) are decided correctly.
*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is only an
x86 emulator that the correctly emulated P never reaches its "ret"
instruction it remains stuck in repeated cycles of emulation.
Yes.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report this.
No. Because by changing H from emulator to halt decider, you have changed
(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.
P.
On 2022-06-17 14:33:32 +0000, olcott said:
THIS IS IRREFUTABLE BECAUSE IT IS A TAUTOLOGY:
When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects that its correct and complete
simulation of its input would never reach the final state of this
input then all [these] inputs (including pathological inputs) are
decided correctly.
One should not use "whenever" in a when-clause. In the beginnig
of the above "If" would be better than "When".
Another tautology is that the above tautology is irrelevant except
when a correct and complete simulation of its input would never reach
a final state of this input.
Note that "the" final state is incorrect: any state that is not
folowed by another state is a final state, and a computation halts
if it reaches one of its final states.
Mikko
On Saturday, 18 June 2022 at 20:07:56 UTC+8, olcott wrote:
On 6/18/2022 4:09 AM, Malcolm McLean wrote:
On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:When H(P,P) correctly determines that P would never reach its "ret"
When a simulating halt decider rejects all inputs as non-haltingYes.
whenever it correctly detects that its correct and complete simulation >>>> of its input would never reach the final state of this input then all
[these] inputs (including pathological inputs) are decided correctly.
*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is only an >>>> x86 emulator that the correctly emulated P never reaches its "ret"
instruction it remains stuck in repeated cycles of emulation.
Yes.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report this. >>>>
No. Because by changing H from emulator to halt decider, you have changed >>> P.
(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.
instruction (AKA final state) this makes H a halt decider for this input
by definition:
computation that halts … the Turing machine will halt whenever it enters >> a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
GUR is repeatedly proved:
olcott can never provide a real halting decider except a verbal one.
Thanks olcott.
On 6/18/2022 4:09 AM, Malcolm McLean wrote:
On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:
When a simulating halt decider rejects all inputs as non-haltingYes.
whenever it correctly detects that its correct and complete simulation
of its input would never reach the final state of this input then all
[these] inputs (including pathological inputs) are decided correctly.
*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is only an
x86 emulator that the correctly emulated P never reaches its "ret"
instruction it remains stuck in repeated cycles of emulation.
Yes.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report
this.
No. Because by changing H from emulator to halt decider, you have changed
(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.
P.
When H(P,P) correctly determines that P would never reach its "ret" instruction (AKA final state) this makes H a halt decider for this input
by definition:
computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
On 6/18/2022 7:24 AM, wij wrote:
On Saturday, 18 June 2022 at 20:07:56 UTC+8, olcott wrote:
On 6/18/2022 4:09 AM, Malcolm McLean wrote:
On Friday, 17 June 2022 at 12:29:37 UTC+1, olcott wrote:When H(P,P) correctly determines that P would never reach its "ret"
When a simulating halt decider rejects all inputs as non-haltingYes.
whenever it correctly detects that its correct and complete simulation >>>>> of its input would never reach the final state of this input then all >>>>> [these] inputs (including pathological inputs) are decided correctly. >>>>>
*computation that halts* … the Turing machine will halt whenever it >>>>> enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
#include <stdint.h>
typedef void (*ptr)();
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
(1) It is an easily verified fact that when we assume that H is
only an
x86 emulator that the correctly emulated P never reaches its "ret"
instruction it remains stuck in repeated cycles of emulation.
Yes.
(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report
this.
No. Because by changing H from emulator to halt decider, you have
(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.
changed
P.
instruction (AKA final state) this makes H a halt decider for this input >>> by definition:
computation that halts … the Turing machine will halt whenever it enters >>> a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
GUR is repeatedly proved:
olcott can never provide a real halting decider except a verbal one.
Thanks olcott.
This one proves that H(P,P) does correctly determine that H(P,P)==0 is correct:
H(P,P)==0 as a pure function of its inputs is fully operational V2
On 6/17/2022 9:31 PM, olcott wrote:
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 108:55:11 |
| Calls: | 6,662 |
| Calls today: | 4 |
| Files: | 12,209 |
| Messages: | 5,335,710 |