info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Halting problem undecidability and infinitely nested simulation (V5) (update)
0 views
Skip to first unread message
olcott
May 21, 2022, 5:48:34 PM5/21/22
to
Halting problem undecidability and infinitely nested simulation (V5)
This is an explanation of a key new insight into the halting problem
provided in the language of software engineering. Technical computer
science terms are explained using software engineering terms.
To fully understand this paper a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and what an x86 processor emulator is. No knowledge
of the halting problem is required.
The computer science term “halting” means that a Turing Machine
terminated normally reaching its last instruction known as its “final
state”. This is the same idea as when a function returns to its caller
as opposed to and contrast with getting stuck in an infinite loop or
infinite recursion.
In computability theory, the halting problem is the problem of
determining,
from a description of an arbitrary computer program and an input,
whether
the program will finish running, or continue to run forever. Alan
Turing proved
in 1936 that a general algorithm to solve the halting problem for
all possible
program-input pairs cannot exist.
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
Technically a halt decider is a program that computes the mapping from a
pair of input finite strings to its own accept or reject state based on
the actual behavior specified by these finite strings. In other words
it determines whether or not its input would halt and returns 0 or 1
accordingly.
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the intuitive
notion of
algorithms, in the sense that a function is computable if there
exists an algorithm
that can do the job of the function, i.e. given an input of the
function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
The most definitive way to determine the actual behavior of the actual
input is to simply simulate this input and watch its behavior. This is
the ultimate measure of the actual behavior of the input. A simulating
halt decider (SHD) simulates its input and determines the halt status of
this input on the basis of the behavior of this correctly simulated of
its input.
The x86utm operating system was created so that all of the details of
the the halting problem counter-example could be examined at the much
higher level of abstraction of the C/x86 computer languages. It is based
on a very powerful x86 emulator.
The function named P was defined to do the opposite of whatever H
reports that it will do. If H(P,P) reports that its input halts, P
invokes an infinite loop. If H(P,P) reports that its input is
non-halting, P immediately halts.
The technical computer science term "halt" means that a program will
reach its last instruction technically called its final state. For P
this would be its machine address [0000136c].
H simulates its input one x86 instruction at a time using an x86
emulator. As soon as H(P,P) detects the same infinitely repeating
pattern (that we can all see), it aborts its simulation and rejects its
input.
Anyone that is an expert in the C programming language, the x86
programming language, exactly how C translates into x86 and what an x86
processor emulator is can easily verify that the correctly simulated
input to H(P,P) by H specifies a non-halting sequence of configurations.
Software engineering experts can reverse-engineer what the correct x86
emulation of the input to H(P,P) would be for one emulation and one
nested emulation thus confirming that the provided execution trace is
correct. They can do this entirely on the basis of the x86 source-code
for P with no need to see the source-code or execution trace of H.
The function named H continues to simulate its input using an x86
emulator until this input either halts on its own or H detects that it
would never halt. If its input halts H returns 1. If H detects that its
input would never halt H returns 0.
#include <stdint.h>
#define u32 uint32_t
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)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]
_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
Begin Local Halt Decider Simulation Execution Trace Stored at:212352
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.
...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(15892) = 237 pages
The correct simulation of the input to H(P,P) and the direct execution
of P(P) are not computationally equivalent thus need not have the same
halting behavior.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
This is an explanation of a key new insight into the halting problem
provided in the language of software engineering. Technical computer
science terms are explained using software engineering terms.
To fully understand this paper a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and what an x86 processor emulator is. No knowledge
of the halting problem is required.
The computer science term “halting” means that a Turing Machine
terminated normally reaching its last instruction known as its “final
state”. This is the same idea as when a function returns to its caller
as opposed to and contrast with getting stuck in an infinite loop or
infinite recursion.
In computability theory, the halting problem is the problem of
determining,
from a description of an arbitrary computer program and an input,
whether
the program will finish running, or continue to run forever. Alan
Turing proved
in 1936 that a general algorithm to solve the halting problem for
all possible
program-input pairs cannot exist.
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
Technically a halt decider is a program that computes the mapping from a
pair of input finite strings to its own accept or reject state based on
the actual behavior specified by these finite strings. In other words
it determines whether or not its input would halt and returns 0 or 1
accordingly.
Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the intuitive
notion of
algorithms, in the sense that a function is computable if there
exists an algorithm
that can do the job of the function, i.e. given an input of the
function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
The most definitive way to determine the actual behavior of the actual
input is to simply simulate this input and watch its behavior. This is
the ultimate measure of the actual behavior of the input. A simulating
halt decider (SHD) simulates its input and determines the halt status of
this input on the basis of the behavior of this correctly simulated of
its input.
The x86utm operating system was created so that all of the details of
the the halting problem counter-example could be examined at the much
higher level of abstraction of the C/x86 computer languages. It is based
on a very powerful x86 emulator.
The function named P was defined to do the opposite of whatever H
reports that it will do. If H(P,P) reports that its input halts, P
invokes an infinite loop. If H(P,P) reports that its input is
non-halting, P immediately halts.
The technical computer science term "halt" means that a program will
reach its last instruction technically called its final state. For P
this would be its machine address [0000136c].
H simulates its input one x86 instruction at a time using an x86
emulator. As soon as H(P,P) detects the same infinitely repeating
pattern (that we can all see), it aborts its simulation and rejects its
input.
Anyone that is an expert in the C programming language, the x86
programming language, exactly how C translates into x86 and what an x86
processor emulator is can easily verify that the correctly simulated
input to H(P,P) by H specifies a non-halting sequence of configurations.
Software engineering experts can reverse-engineer what the correct x86
emulation of the input to H(P,P) would be for one emulation and one
nested emulation thus confirming that the provided execution trace is
correct. They can do this entirely on the basis of the x86 source-code
for P with no need to see the source-code or execution trace of H.
The function named H continues to simulate its input using an x86
emulator until this input either halts on its own or H detects that it
would never halt. If its input halts H returns 1. If H detects that its
input would never halt H returns 0.
#include <stdint.h>
#define u32 uint32_t
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)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]
_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
Begin Local Halt Decider Simulation Execution Trace Stored at:212352
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
H sees that P is calling the same function from the same machine address
with identical parameters, twice in sequence. This is the infinite
recursion (infinitely nested simulation) non-halting behavior pattern.
...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(15892) = 237 pages
The correct simulation of the input to H(P,P) and the direct execution
of P(P) are not computationally equivalent thus need not have the same
halting behavior.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
olcott
May 21, 2022, 5:51:03 PM5/21/22
to
Mutt Buncher
May 21, 2022, 6:16:05 PM5/21/22
to
On 5/21/2022 2:48 PM, olcott wrote:
> Halting problem undecidability and infinitely nested simulation (V5)
Post it 156,334 more times you retarded mouthload of Bolivian goat
> Halting problem undecidability and infinitely nested simulation (V5)
testicles.
Mr Flibble
May 21, 2022, 6:51:42 PM5/21/22
to
On Sat, 21 May 2022 16:48:26 -0500
olcott <No...@NoWhere.com> wrote:
>
> H simulates its input one x86 instruction at a time using an x86
> emulator. As soon as H(P,P) detects the same infinitely repeating
> pattern (that we can all see), it aborts its simulation and rejects
> its input.
There is no infinitely repeating pattern except the one you are making
olcott <No...@NoWhere.com> wrote:
>
> H simulates its input one x86 instruction at a time using an x86
> emulator. As soon as H(P,P) detects the same infinitely repeating
> pattern (that we can all see), it aborts its simulation and rejects
> its input.
up in your head based on your misunderstanding of the halting problem
theorem proof. How many times do you have to be told this? You've got
nothing.
/Flibble
olcott
May 21, 2022, 6:55:26 PM5/21/22
to
To fully understand this paper a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and what an x86 processor emulator is. No knowledge
of the halting problem is required.
language level.
Mr Flibble
May 21, 2022, 7:01:13 PM5/21/22
to
On Sat, 21 May 2022 17:55:18 -0500
olcott <No...@NoWhere.com> wrote:
> On 5/21/2022 5:51 PM, Mr Flibble wrote:
> > On Sat, 21 May 2022 16:48:26 -0500
> > olcott <No...@NoWhere.com> wrote:
> >>
> >> H simulates its input one x86 instruction at a time using an x86
> >> emulator. As soon as H(P,P) detects the same infinitely repeating
> >> pattern (that we can all see), it aborts its simulation and rejects
> >> its input.
> >
> > There is no infinitely repeating pattern except the one you are
> > making up in your head based on your misunderstanding of the
> > halting problem theorem proof. How many times do you have to be
> > told this? You've got nothing.
> >
> > /Flibble
> >
>
> Clearly you do not have the technical competence to evaluate my paper:
>
> To fully understand this paper a software engineer must be an expert
> in: the C programming language, the x86 programming language, exactly
> how C translates into x86 and what an x86 processor emulator is. No
> knowledge of the halting problem is required.
>
> and the ability to recognize infinite recursion at the x86 assembly
> language level.
We have been over this. I am quite capable of recognizing infinite
olcott <No...@NoWhere.com> wrote:
> On 5/21/2022 5:51 PM, Mr Flibble wrote:
> > On Sat, 21 May 2022 16:48:26 -0500
> > olcott <No...@NoWhere.com> wrote:
> >>
> >> H simulates its input one x86 instruction at a time using an x86
> >> emulator. As soon as H(P,P) detects the same infinitely repeating
> >> pattern (that we can all see), it aborts its simulation and rejects
> >> its input.
> >
> > There is no infinitely repeating pattern except the one you are
> > making up in your head based on your misunderstanding of the
> > halting problem theorem proof. How many times do you have to be
> > told this? You've got nothing.
> >
> > /Flibble
> >
>
> Clearly you do not have the technical competence to evaluate my paper:
>
> To fully understand this paper a software engineer must be an expert
> in: the C programming language, the x86 programming language, exactly
> how C translates into x86 and what an x86 processor emulator is. No
> knowledge of the halting problem is required.
>
> and the ability to recognize infinite recursion at the x86 assembly
> language level.
recursion but, crucially, I can also recognize a *lack* of infinite
recursion: it is a shame that you are not capable of doing the same.
/Flibble
olcott
May 21, 2022, 7:07:05 PM5/21/22
to
function calls another function with the same parameters from the same
machine address twice in sequence that this specifies infinite recursion.
Mr Flibble
May 21, 2022, 7:12:02 PM5/21/22
to
On Sat, 21 May 2022 18:06:57 -0500
But that doesn't happen in the proofs you are attempting to refute as
THERE IS NO INFINITE RECURSION PRESENT IN THOSE PROOFS.
/Flibble
THERE IS NO INFINITE RECURSION PRESENT IN THOSE PROOFS.
/Flibble
olcott
May 21, 2022, 7:22:27 PM5/21/22
to
point. To actually understand my proof we must move point by point
one-at-at-time achieving mutual agreement on each point before moving on
to the next point.
The C function named H does correctly determine that the its input
parameters point to the machine language of a C function that never
reaches its last instruction.
Halting problem undecidability and infinitely nested simulation (V5)
Mr Flibble
May 21, 2022, 8:34:24 PM5/21/22
to
On Sat, 21 May 2022 18:22:19 -0500
Given that there is no infinite recursion in the proof you are trying
to refute then what is the point in going through your proof given it
is based on a false premise?
/Flibble
to refute then what is the point in going through your proof given it
is based on a false premise?
/Flibble
olcott
May 21, 2022, 8:39:07 PM5/21/22
to
be able to begin to understand that until we go through many steps of my
other proof first.
Richard Damon
May 21, 2022, 9:00:21 PM5/21/22
to
THE FOLLOWING DOESN'T ACTUALLY HAPPEN, AND IS A LIE>
> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50 push eax // push P
> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> H sees that P is calling the same function from the same machine address
> with identical parameters, twice in sequence. This is the infinite
> recursion (infinitely nested simulation) non-halting behavior pattern.
comes up with a wrong answer.
You are just showing YOUR technical incompitence in making your claim.
>
> ...[00001384][0010229e][00000000] 83c408 add esp,+08
> ...[00001387][0010229a][00000000] 50 push eax
> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
> "Input_Halts = "
> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408 add esp,+08
> ...[00001395][0010229e][00000000] 33c0 xor eax,eax
> ...[00001397][001022a2][00100000] 5d pop ebp
> ...[00001398][001022a6][00000004] c3 ret
> Number_of_User_Instructions(1)
> Number of Instructions Executed(15892) = 237 pages
>
> The correct simulation of the input to H(P,P) and the direct execution
> of P(P) are not computationally equivalent thus need not have the same
> halting behavior.
>
because BY DEFINITION a correct simulation of X will exactly emulate the
actual behavior of X.
Thus the simulation that H(P,P) does, must match P(P), or it is BY
DEFINTION not correct.
If you claim that can't be done, then you have just proved the theorem
you are trying to disprove.
Note, the correct simulation CAN occur, it is just that H can't do that
and give an answer in finite time for H(P,P).
Richard Damon
May 21, 2022, 9:02:26 PM5/21/22
to
On 5/21/22 6:55 PM, olcott wrote:
> On 5/21/2022 5:51 PM, Mr Flibble wrote:
>> On Sat, 21 May 2022 16:48:26 -0500
>> olcott <No...@NoWhere.com> wrote:
>>>
>>> H simulates its input one x86 instruction at a time using an x86
>>> emulator. As soon as H(P,P) detects the same infinitely repeating
>>> pattern (that we can all see), it aborts its simulation and rejects
>>> its input.
>>
>> There is no infinitely repeating pattern except the one you are making
>> up in your head based on your misunderstanding of the halting problem
>> theorem proof. How many times do you have to be told this? You've got
>> nothing.
>>
>> /Flibble
>>
>
> Clearly you do not have the technical competence to evaluate my paper:
>
> To fully understand this paper a software engineer must be an expert in:
> the C programming language, the x86 programming language, exactly how C
> translates into x86 and what an x86 processor emulator is. No knowledge
> of the halting problem is required.
>
> and the ability to recognize infinite recursion at the x86 assembly
> language level.
>
You don't have the technical competenct to write a correct paper, or the
> On 5/21/2022 5:51 PM, Mr Flibble wrote:
>> On Sat, 21 May 2022 16:48:26 -0500
>> olcott <No...@NoWhere.com> wrote:
>>>
>>> H simulates its input one x86 instruction at a time using an x86
>>> emulator. As soon as H(P,P) detects the same infinitely repeating
>>> pattern (that we can all see), it aborts its simulation and rejects
>>> its input.
>>
>> There is no infinitely repeating pattern except the one you are making
>> up in your head based on your misunderstanding of the halting problem
>> theorem proof. How many times do you have to be told this? You've got
>> nothing.
>>
>> /Flibble
>>
>
> Clearly you do not have the technical competence to evaluate my paper:
>
> To fully understand this paper a software engineer must be an expert in:
> the C programming language, the x86 programming language, exactly how C
> translates into x86 and what an x86 processor emulator is. No knowledge
> of the halting problem is required.
>
> and the ability to recognize infinite recursion at the x86 assembly
> language level.
>
ability to correctly recognize infinite recursion at the x86 assembly
level, since you have shown that P(P) Halts, and thus CAN'T have
infinite recursion, because your H incorrectly aborts its simulation and
says it is not Halting.
olcott
May 21, 2022, 9:04:01 PM5/21/22
to
The correct simulation of the input to H(P,P) and the direct execution
of P(P) are not computationally equivalent thus need not have the same
halting behavior.
of P(P) are not computationally equivalent thus need not have the same
halting behavior.
Richard Damon
May 21, 2022, 9:18:46 PM5/21/22
to
in the context of a Halting Decider.
What is YOUR definition of a Correct Simulation, if it doesn't need to
match that actual behavior of that which is simulated?
FAIL.
olcott
May 21, 2022, 9:33:29 PM5/21/22
to
> if it doesn't need to
> match that actual behavior of that which is simulated?
>
> FAIL.
>
Richard Damon
May 21, 2022, 10:32:29 PM5/21/22
to
decide that its input is non-halting, and abort its simulation and
return a 0 so P(P) halts.
THAT is the behavior that the x86 source-code specifies when we add your
definition of the behavior of H.
Since that is the ACTUAL behavior the source code specifies, but is NOT
the behavior your "Correct Simulation" shows, it is thus, by your
definition NOT a correct simulation.
That, or you are incorrect that you H(P,P) will "correctly" return 0.
(which actually turns out to be incorrectly).
The other correct simulation would be to show the instructions of H
being simulated, since that is what the ACTUAL x86 code specifies.
(There is no grounds for no showing those instructions).
olcott
May 21, 2022, 10:36:54 PM5/21/22
to
H(P,P) simulates its input that calls H(P,P) that simulates its input.
P(P) calls H(P,P) that simulates its input has a provably entirely
different execution trace.
Richard Damon
May 21, 2022, 11:20:55 PM5/21/22
to
H(P,P) always does the same thing, right? if not, H fails to be an
actual computation.
Since you say the outer H(P,P) returns 0, then it MUST be true that the
H that P calls also returns 0, as we KNOW from your stipulation what
H(P,P) does.
All you have done is proved that you must be lying about something.
Either the H you have doesn't return 0 for this H(P,P), or
This H(P,P) isn't a computation, returning different values from
different calls with the same parameter, or
H(P,P) is just wrong about its answer.
You are running into a problem of definition. You seem to be envisioning
an H that uses "magic" to do the impossible.
So, which case isn't true?
Does H(P,P) not abort this simulation and return 0, or
Do different calls to H(P,P) have different behaviors (showing it is not
a computation)? or
Is H(P,P) just wrong, because the CORRECT (and thus one that doesn't
abort) simulation of its input will halt.
You are assuming that H does a correct simulation, when it can't, and
answer non-halting correctly at the same time for this input.
FAIL.
olcott
May 21, 2022, 11:34:17 PM5/21/22
to
The simulated input to H(P,P) does not do the same thing as the directly
executed P(P). This is an easily verifiable fact.
It gets me very angry when people disagree with easily verifiable facts.
(1) There is zero proof (none at all) of consequential election fraud in
the 2020 presidential election.
(2) The two MRNA Covid-19 vaccines have proved to save very many lives
and have close to zero cases of bad side effects.
(3) Very severe climate change caused by humans is real and we are
quickly reaching the point of no return. If not corrected there will be
very dire consequences.
Richard Damon
May 22, 2022, 12:03:00 AM5/22/22
to
The only possible answer is that your H isn't actually a Halt Decider
and thus the input P,P doesn't actually represent P(P).
If this is because you claim it can't be given a representation of that
computation, that PROVES the Halting Theorem, as if you can't ask the
question, the decider can't give the right answer.
>
> It gets me very angry when people disagree with easily verifiable facts.
> (1) There is zero proof (none at all) of consequential election fraud in
> the 2020 presidential election.
>
> (2) The two MRNA Covid-19 vaccines have proved to save very many lives
> and have close to zero cases of bad side effects.
>
> (3) Very severe climate change caused by humans is real and we are
> quickly reaching the point of no return. If not corrected there will be
> very dire consequences.
>
You claim it is easily verified, and then don't actually show a
verification.
This implies that you really can't show what you claim.
You didn't answer ANY of the questions I put to you, which implies that
you don't have answers, because you are caught in your lie,
Your claimed rebutal doesn't meet the definiton of the problem, so is
invalid.
You must follow the rules to be in the game, don't follow the rules, and
you can't be actually playing in the game, and you arguement is meaningless.
Someday you may find this out the hard way. You don't get to change the
rules to a game you didn't create and still be playing it.
That is like bringing a rifle to an archery contest and wondering why
you are disqualified even though you put every shot in the bullseye.
0 new messages