On Wed, 10 Nov 2021 19:42:23 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
On 11/10/21 5:34 PM, olcott wrote:
On 11/10/2021 3:53 PM, Mr Flibble wrote:
Olcott is barking up the wrong tree re infinite recursion: there
is only a need to detect a single recursive call into the halt
decider and signal an exception.
Yes, I figured that out. That eliminates the need for static local
data thus allowing the halt decider to be a pure function.
Except that this logic is only correct if the function is being
executed under unconditional execution.
If the 'simulation' is being run under condition that can/will
terminate its execution, then the detection of this recursion is NOT
proof that the execution will be non-halting.
All you have show is that IF the decider would never abort its
'simulation' then the program would be non-halting.
Since it turns out that the decider DOES abort its 'simulation', the
assumptions that the analysis was done under are not in fact true, so
the analysis is invalid.
https://en.wikipedia.org/wiki/Pure_function
But Software Engineering 'Pure Function' is NOT the Compution Theory
'Computation', so you need to be aware of the difference.
That is why I needed my source-code analyzer to provide the exact
number of parameters to every function.
As long as the currently executing function (H) is called again
with the same parameters then we know that this call will be
infinitely recursive unless this infinite recursion is aborted at
some point.
Right, it would be infinite if NEVER aborted, but it IS aborted, so
it is not infinite, and since the machine uses a copy of the decider,
that same fact applies to it being run as an indepent computation,
since the decider inside it does abort its internal simulation, it
return the answer that allows the actual computation to be finint.
When H aborts this call to itself made by P then P never reaches
its final state. If H never aborts this call made by P then P never
reaches its final state. This conclusively proves that H can abort
this call to itself and report that its input never halts.
But it doensn't matter that H's PARTIAL simulation of P reached the
halting point. When we run the actual computation, or give this input
to a REAL pure simulator, it will Halt.
Here is the reference to my NumParams system:
On 10/23/2021 8:27 PM, olcott wrote:
[I finally completed my lexical analyzer generator (needed by my
halt decider)]
This system uses a DFA lexical analyzer to recognize
the pattern of function declarations. This pattern is
specified as 15 DFA states. The output is a C header
file that looks up the function name specified in the
COFF object file and returns its number of parameters.
And where does this code get the source code of the program whose
COMPILED form has been given to H?
Or, is H now being given the source code as the representation?
Remember, if you do that, then that source code needs to contain the
FULL description of the program, which includes the code for H, and
everything it uses, which includes your NumParams and the compiler
you are going to put that code into.
Nope, H needs to be a black box so its implementation is unknown to
everyone but the creator of H. If H is a black box it can safely
detect recursion into it and signal an exception.
/Flibble
--
This message is a troll.
On Thu, 11 Nov 2021 13:19:33 -0600
olcott <NoOne@NoWhere.com> wrote:
On 11/11/2021 11:52 AM, Mr Flibble wrote:
On Wed, 10 Nov 2021 19:42:23 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
On 11/10/21 5:34 PM, olcott wrote:
On 11/10/2021 3:53 PM, Mr Flibble wrote:
Olcott is barking up the wrong tree re infinite recursion: there
is only a need to detect a single recursive call into the halt
decider and signal an exception.
Yes, I figured that out. That eliminates the need for static local
data thus allowing the halt decider to be a pure function.
Except that this logic is only correct if the function is being
executed under unconditional execution.
If the 'simulation' is being run under condition that can/will
terminate its execution, then the detection of this recursion is
NOT proof that the execution will be non-halting.
All you have show is that IF the decider would never abort its
'simulation' then the program would be non-halting.
Since it turns out that the decider DOES abort its 'simulation',
the assumptions that the analysis was done under are not in fact
true, so the analysis is invalid.
https://en.wikipedia.org/wiki/Pure_function
But Software Engineering 'Pure Function' is NOT the Compution
Theory 'Computation', so you need to be aware of the difference.
That is why I needed my source-code analyzer to provide the exact
number of parameters to every function.
As long as the currently executing function (H) is called again
with the same parameters then we know that this call will be
infinitely recursive unless this infinite recursion is aborted at
some point.
Right, it would be infinite if NEVER aborted, but it IS aborted, so
it is not infinite, and since the machine uses a copy of the
decider, that same fact applies to it being run as an indepent
computation, since the decider inside it does abort its internal
simulation, it return the answer that allows the actual
computation to be finint.
When H aborts this call to itself made by P then P never reaches
its final state. If H never aborts this call made by P then P
never reaches its final state. This conclusively proves that H
can abort this call to itself and report that its input never
halts.
But it doensn't matter that H's PARTIAL simulation of P reached the
halting point. When we run the actual computation, or give this
input to a REAL pure simulator, it will Halt.
Here is the reference to my NumParams system:
On 10/23/2021 8:27 PM, olcott wrote:
[I finally completed my lexical analyzer generator (needed by my
halt decider)]
This system uses a DFA lexical analyzer to recognize
the pattern of function declarations. This pattern is
specified as 15 DFA states. The output is a C header
file that looks up the function name specified in the
COFF object file and returns its number of parameters.
And where does this code get the source code of the program whose
COMPILED form has been given to H?
Or, is H now being given the source code as the representation?
Remember, if you do that, then that source code needs to contain
the FULL description of the program, which includes the code for
H, and everything it uses, which includes your NumParams and the
compiler you are going to put that code into.
Nope, H needs to be a black box so its implementation is unknown to
everyone but the creator of H. If H is a black box it can safely
detect recursion into it and signal an exception.
That won't work because someone could write the same H as a whitebox.
They could only do that by accident so if the probability of blindly replicating the black box is sufficiently low we can discount it (just
as we can discount cracking a 512-bit encryption key with a
classical computer).
/Flibble
--
This message is a troll.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 384 |
Nodes: | 16 (2 / 14) |
Uptime: | 59:51:08 |
Calls: | 8,172 |
Calls today: | 4 |
Files: | 13,113 |
Messages: | 5,864,379 |