On Saturday, April 16, 2022 at 6:33:04 PM UTC-4, olcott wrote:
On 4/16/2022 5:27 PM, Dennis Bush wrote:
On Saturday, April 16, 2022 at 6:21:10 PM UTC-4, olcott wrote:You must show how this input simulated by to H will reach its final
On 4/16/2022 5:14 PM, Dennis Bush wrote:If we give the input of Ha(Pa,Pa) to Hb as Hb(Pa,Pa), it simulates for a few extra steps more than Ha does. Specifically it sees Pa call Ha, then it sees Ha return false, then it continues simulating Pa until a final state is reached.
On Saturday, April 16, 2022 at 5:46:07 PM UTC-4, olcott wrote:Can you show how the simulated input to H(P,P) reaches its final state? >>>
On 4/16/2022 3:53 PM, Dennis Bush wrote:
On Saturday, April 16, 2022 at 4:48:01 PM UTC-4, olcott wrote:Everyone understanding what I said knows that your attempt at rebuttal >>>>>> is nothing more that a deceitful attempt to get away with the strawman >>>>>> error. I know that you know this too.
On 4/16/2022 3:39 PM, Dennis Bush wrote:
On Saturday, April 16, 2022 at 4:22:34 PM UTC-4, olcott wrote: >>>>>>>>>> On 4/16/2022 3:12 PM, Dennis Bush wrote:LIAR LIAR INCINERATED ON THE SURFACE OF THE SUN FOR ALL ETERNITY >>>>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
On Saturday, April 16, 2022 at 3:57:37 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 4/16/2022 1:50 PM, Dennis Bush wrote:When we confirm by its x86 code that the simulated input to H(P,P) is
On Saturday, April 16, 2022 at 1:41:26 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 4/16/2022 12:36 PM, Dennis Bush wrote:The easily verified fact is that the input to H(P,P) is not halting thus
On Saturday, April 16, 2022 at 1:32:43 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 4/16/2022 12:24 PM, Dennis Bush wrote:Do you want to be plonked?
On Saturday, April 16, 2022 at 1:02:30 PM UTC-4, olcott wrote:God damn liars continue to pretend that verified facts can be correctly
On 4/16/2022 11:51 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>> On Saturday, April 16, 2022 at 12:27:25 PM UTC-4, olcott wrote:I proved that the input to Ha(Pa,Pa) does in fact halt when given to Hb.
It is a verified fact that the input to H(P,P) is non-halting.On 4/16/2022 11:23 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>> On Saturday, April 16, 2022 at 12:03:37 PM UTC-4, olcott wrote:
If {an X is a Y} then anything that disagrees is incorrect.On 4/16/2022 11:00 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>> On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
I know that Bill Jones robbed the liquor store and no amount of evidenceOn 4/16/2022 10:17 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:Anyone that knows the x86 language can see that the simulated input to
If you disagree that France exists I do not need to read the wholeOn 4/16/2022 7:27 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
LIAR LIAR PANTS ON FIREOn 4/15/2022 5:18 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
When H correctly determines that its input would never reach its ownThe following simplifies the syntax for the definition of the Linz
Turing machine Ĥ. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
There is no need for the infinite loop after H.qy because it is never
reached.
You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
times"
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
own final state.
The correct specification is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
void P(u32 x)
{
if (H(x, x)) //
HERE: goto HERE;
}
You've told us that H(P,P) is false even though P(P) halts. That's the
wrong result for a simple model of a C halt decider.
final state
Which is doesn't.
The simulated input to H(P,P) cannot possibly reach its own final state
it keeps repeating [00000956] to [00000961] until aborted.
_P()
[00000956](01) 55 push ebp >>>>>>>>>>>>>>>>>>>>>>>>>> [00000957](02) 8bec mov ebp,esp >>>>>>>>>>>>>>>>>>>>>>>>>> [00000959](03) 8b4508 mov eax,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>>>> [0000095c](01) 50 push eax // push P >>>>>>>>>>>>>>>>>>>>>>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08] >>>>>>>>>>>>>>>>>>>>>>>>>> [00000960](01) 51 push ecx // push P >>>>>>>>>>>>>>>>>>>>>>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
The above keeps repeating until aborted >>>>>>>>>>>>>>>>>>>>>>>>>>
[00000966](03) 83c408 add esp,+08 >>>>>>>>>>>>>>>>>>>>>>>>>> [00000969](02) 85c0 test eax,eax >>>>>>>>>>>>>>>>>>>>>>>>>> [0000096b](02) 7402 jz 0000096f >>>>>>>>>>>>>>>>>>>>>>>>>> [0000096d](02) ebfe jmp 0000096d >>>>>>>>>>>>>>>>>>>>>>>>>> [0000096f](01) 5d pop ebp
[00000970](01) c3 ret // final state. >>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [00000970] >>>>>>>>>>>>>>>>>>>>>>>>>>
THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
All of my reviewers take the position that the fact that the input to
H(P,P) is non-halting is not an entirely sufficient reason for H to
report that its input is non-halting. >>>>>>>>>>>>>>>>>>>>>>>>>
message to see that you are wrong. >>>>>>>>>>>>>>>>>>>>>>>>
Anyone that knows the x86 language can see that the simulated input to
H(P,P) never reaches its own final state. >>>>>>>>>>>>>>>>>>>>>>>
Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.
that Bill Smith didn't do it exonerates Bill Jones, Jackass.
Another bad analogy with no explanation. Again showing that you know that you're wrong and have no rebuttal.
If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
correct.
The problem is that you don't have an X. >>>>>>>>>>>>>>>>>>>
NOTHING IN THE UNIVERSE CAN POSSIBLY CORRECTLY CONTRADICT THIS:
The easily verified fact is that the input to H(P,P) is not halting
No it's not, as proved by Hb. So prove that Hb (Pa,Pa) == true is not correct or admit defeat.
That you rebut this conclusively proves that you are a liar. >>>>>>>>>>>>>>>>>
contradicted. Maybe I should put you on Thunderbird filters delete posts
from "Dennis Bush".
Still no rebuttal.
You know that you cannot correctly contradict a verified fact thus every
detail of all of your dialogue is nothing but a head game. >>>>>>>>>>>>>>
Ha and Hb are both simulating halt deciders and both are given the same input, but they get different answers. This means one must be correct and the other must be incorrect.
H(P,P)==false is necessarily correct.
The easily verified fact is that the input to Hb(Pa,Pa), which is the same as the input to Ha(Pa,Pa) (which you call H(P,P)), DOES halt.
non-halting then anyone in the world that attempts to rebut this is >>>>>>>>>> proven to be a liar.
The x86 code you've shown only shows that Ha is unable to simulate its input to completion. A similar x86 trace of the same input given to Hb shows that it halts (just like the post you made a year ago that Richard recently reposted).
of [000009f0] it keeps repeating [000009d6] to [000009e1] until aborted.
_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]
Begin Local Halt Decider Simulation
...[000009d6][00211368][0021136c] 55 push ebp // enter P
...[000009d7][00211368][0021136c] 8bec mov ebp,esp
...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
...[000009dc][00211364][000009d6] 50 push eax // Push P
...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][00211360][000009d6] 51 push ecx // Push P
...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H >>>>>>>> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H >>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>> Because the correctly simulated input to H(P,P) cannot possibly reach >>>>>>>> its own final state at [000009f0] it is necessarily correct for H to >>>>>>>> reject this input as non-halting.
Ha(Pa,Pa) does not correctly simulate its input. Hb(Pa,Pa) does. >>>>>>>
You've claimed that it's a strawman error numerous times but you've never stated why. At this point it just sounds like whining.
You've agreed earlier that either Hb(Pa,Pa) is correct or Ha(Pa,Pa) is correct. So if Hb simulates its input to its final state, how can it possibly be wrong?
So Hb proves that the input to Ha(Pa,Pa) reaches a final state, and so the correct return value is true.
state, changing the subject counts as lying.
_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]
So you're saying that *only* Ha can be correct about its own simulation?
Alex C <immibis@gmail.com> writes:
You guys might all be missing something simple: The "correct
simulation" does halt. So when the decider says it doesn't halt, it's
wrong.
Who are "you guys"? I see this point being made daily. PO misses that,
but he's not plural!
And there is an even simpler point than this. PO tells us that
H(P,P)==false "even though P(P) halts". He now denies that this is in
anyway significant, but it's the "top-level" reason why he is wrong.
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.
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.
On 5/21/2022 5:51 PM, Mr Flibble wrote:
On Sat, 21 May 2022 16:48:26 -0500
olcott <NoOne@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.
On Sat, 21 May 2022 16:48:26 -0500
olcott <NoOne@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
On Sat, 21 May 2022 17:55:18 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/21/2022 5:51 PM, Mr Flibble wrote:
On Sat, 21 May 2022 16:48:26 -0500
olcott <NoOne@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
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
On 5/21/2022 6:01 PM, Mr Flibble wrote:
On Sat, 21 May 2022 17:55:18 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/21/2022 5:51 PM, Mr Flibble wrote:
On Sat, 21 May 2022 16:48:26 -0500
olcott <NoOne@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 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
If you can recognize infinite recursion then you know that when one
function calls another function with the same parameters from the
same machine address twice in sequence that this specifies infinite recursion.
Halting problem undecidability and infinitely nested simulation (V5)
On Sat, 21 May 2022 18:06:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/21/2022 6:01 PM, Mr Flibble wrote:
On Sat, 21 May 2022 17:55:18 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/21/2022 5:51 PM, Mr Flibble wrote:
On Sat, 21 May 2022 16:48:26 -0500
olcott <NoOne@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
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
If you can recognize infinite recursion then you know that when one
function calls another function with the same parameters from the
same machine address twice in sequence that this specifies infinite
recursion.
But that doesn't happen in the proofs you are attempting to refute as
THERE IS NO INFINITE RECURSION PRESENT IN THOSE PROOFS.
/Flibble
On 5/21/2022 6:11 PM, Mr Flibble wrote:
On Sat, 21 May 2022 18:06:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/21/2022 6:01 PM, Mr Flibble wrote:
On Sat, 21 May 2022 17:55:18 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/21/2022 5:51 PM, Mr Flibble wrote:
On Sat, 21 May 2022 16:48:26 -0500
olcott <NoOne@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
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
If you can recognize infinite recursion then you know that when one
function calls another function with the same parameters from the
same machine address twice in sequence that this specifies infinite
recursion.
But that doesn't happen in the proofs you are attempting to refute
as THERE IS NO INFINITE RECURSION PRESENT IN THOSE PROOFS.
/Flibble
If you keep changing the subject we will never get any closure on any
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)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
On Sat, 21 May 2022 18:22:19 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/21/2022 6:11 PM, Mr Flibble wrote:
On Sat, 21 May 2022 18:06:57 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/21/2022 6:01 PM, Mr Flibble wrote:
On Sat, 21 May 2022 17:55:18 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/21/2022 5:51 PM, Mr Flibble wrote:
On Sat, 21 May 2022 16:48:26 -0500
olcott <NoOne@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
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
If you can recognize infinite recursion then you know that when one
function calls another function with the same parameters from the
same machine address twice in sequence that this specifies infinite
recursion.
But that doesn't happen in the proofs you are attempting to refute
as THERE IS NO INFINITE RECURSION PRESENT IN THOSE PROOFS.
/Flibble
If you keep changing the subject we will never get any closure on any
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)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
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
On 5/21/2022 5:51 PM, Mr Flibble wrote:
On Sat, 21 May 2022 16:48:26 -0500
olcott <NoOne@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.
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.
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 <NoOne@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 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.
On 5/21/2022 8:02 PM, Richard Damon wrote:
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 <NoOne@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 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.
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.
On 5/21/22 9:03 PM, olcott wrote:
On 5/21/2022 8:02 PM, Richard Damon wrote:
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 <NoOne@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 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.
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.
Nope. Can't be and meet the definition of Correct Simulation, at least
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.
On 5/21/2022 8:18 PM, Richard Damon wrote:
On 5/21/22 9:03 PM, olcott wrote:
On 5/21/2022 8:02 PM, Richard Damon wrote:
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 <NoOne@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 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.
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.
Nope. Can't be and meet the definition of Correct Simulation, at least
in the context of a Halting Decider.
What is YOUR definition of a Correct Simulation,
The code does exactly what its x86 source-code specifies.
if it doesn't need to match that actual behavior of that which is
simulated?
FAIL.
On 5/21/22 9:33 PM, olcott wrote:
On 5/21/2022 8:18 PM, Richard Damon wrote:
On 5/21/22 9:03 PM, olcott wrote:
On 5/21/2022 8:02 PM, Richard Damon wrote:
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 <NoOne@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 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.
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.
Nope. Can't be and meet the definition of Correct Simulation, at
least in the context of a Halting Decider.
What is YOUR definition of a Correct Simulation,
The code does exactly what its x86 source-code specifies.
Right, P(P) calls H(P,P)
On 5/21/2022 9:32 PM, Richard Damon wrote:
On 5/21/22 9:33 PM, olcott wrote:
On 5/21/2022 8:18 PM, Richard Damon wrote:
On 5/21/22 9:03 PM, olcott wrote:
On 5/21/2022 8:02 PM, Richard Damon wrote:
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 <NoOne@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 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.
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.
Nope. Can't be and meet the definition of Correct Simulation, at
least in the context of a Halting Decider.
What is YOUR definition of a Correct Simulation,
The code does exactly what its x86 source-code specifies.
Right, P(P) calls H(P,P)
No that is not what is being analyzed.
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.
On 5/21/22 10:36 PM, olcott wrote:
On 5/21/2022 9:32 PM, Richard Damon wrote:
On 5/21/22 9:33 PM, olcott wrote:
On 5/21/2022 8:18 PM, Richard Damon wrote:
On 5/21/22 9:03 PM, olcott wrote:
On 5/21/2022 8:02 PM, Richard Damon wrote:
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 <NoOne@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 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.
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.
Nope. Can't be and meet the definition of Correct Simulation, at
least in the context of a Halting Decider.
What is YOUR definition of a Correct Simulation,
The code does exactly what its x86 source-code specifies.
Right, P(P) calls H(P,P)
No that is not what is being analyzed.
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.
Nope.
H(P,P) always does the same thing, right? if not, H fails to be an
actual computation.
On 5/21/2022 10:20 PM, Richard Damon wrote:
On 5/21/22 10:36 PM, olcott wrote:Every H(P,P) that is invoked or simulated must do the same thing.
On 5/21/2022 9:32 PM, Richard Damon wrote:
On 5/21/22 9:33 PM, olcott wrote:
On 5/21/2022 8:18 PM, Richard Damon wrote:
On 5/21/22 9:03 PM, olcott wrote:
On 5/21/2022 8:02 PM, Richard Damon wrote:
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 <NoOne@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 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.
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.
Nope. Can't be and meet the definition of Correct Simulation, at
least in the context of a Halting Decider.
What is YOUR definition of a Correct Simulation,
The code does exactly what its x86 source-code specifies.
Right, P(P) calls H(P,P)
No that is not what is being analyzed.
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.
Nope.
H(P,P) always does the same thing, right? if not, H fails to be an
actual computation.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 125:51:10 |
| Calls: | 6,663 |
| Calls today: | 1 |
| Files: | 12,212 |
| Messages: | 5,334,951 |