Proof that H(P,P)==0 is correct [ refuting the halting problem proofs ]

[Skepdick]

You simply do not have enough sufficiently relevant technical background to correctly review my work.

This work has already been very extensively reviewed with thousands of reviews and none of the reviews brought up the issue that you raised about source-code versus x86 machine language.

Pete. Your work is junk. It serves no purpose.

And it doesn't address the problem you profess it to be addressing. All the other reviewers are probably as incompetent as you are.

The issue between source code and x86 machine language is not a problem. IF you are passing a string-representation of your program to H.

It doesn't matter if the string contains x86 assembly; or C source code. It just has to be a string. A text representation of your program!

[PeteOlcott]

It need not be text. This is over your head.

[Skepdick]

It need not be text.

Definition of "source code".

a text listing of commands to be compiled or assembled into an executable computer program.

Another definition

a computer program written in text form that must be translated into another form, such as machine code, before it can run on a computer

Wikipedia entry

Source code (also referred to as source or code) is the version of software as it is originally written (i.e., typed into a computer) by a human in plain text (i.e., human readable alphanumeric characters).

This is over your head.

Now I understand why you've wasted 15000 hours on this. Because you are unable to parse/lex anything you read.

[PeteOlcott]

I give up. You are incompetent on this subject.

[Skepdick]

I give up. You are incompetent on this subject.

Your competence decider is as broken as your halting decider.

You are still oblivious to the fact that the definition of P (in the form of plain-text source code) is not being passed as an input to H!

Learn about quoting, and self-evaluating forms dumb ass.

https://www.gnu.org/software/emacs/manu ... oting.html
https://www.gnu.org/software/emacs/manu ... Forms.html

[PeteOlcott]

You prove that you don't have a clue in this post:
Pure functions? What the heck are those ?!?!

[Skepdick]

You prove that you don't have a clue in this post:
Pure functions? What the heck are those ?!?!

Q.E.D Your decider keeps being wrong. Every. Damn. Time.

If you decide to stop being an idiot maybe you'll spot the difference between applying the function "max" to parameters "1 2 3 4 5" - which returns the maximal element of the list.

Code: Select all

user=> (max 1 2 3 4 5)
5

And applying the function "source" to parameters "max" - which returns the source code of "max".

Code: Select all

user=> (source max)
(defn max
  "Returns the greatest of the nums."
  {:added "1.0"
   :inline-arities >1?
   :inline (nary-inline 'max)}
  ([x] x)
  ([x y] (. clojure.lang.Numbers (max x y)))
  ([x y & more]
   (reduce1 max (max x y) more)))
nil

And what do we have here?!?! Applying source to source returns the source of source.

Code: Select all

user=> (source source)
(defmacro source
  "Prints the source code for the given symbol, if it can find it.
  This requires that the symbol resolve to a Var defined in a
  namespace for which the .clj is in the classpath.

  Example: (source filter)"
  [n]
  `(println (or (source-fn '~n) (str "Source not found"))))
nil

The programming languages you are using cannot do that! They are too low-level - not abstract enough!
If you use Lambda calculus instead of Turing machines it might help you draw the necessary conceptual distinctions to recognize that

applying H to P

Code: Select all

(H P)

is very very different to

applying H to the source code of P

Code: Select all

(H (source P))

[Skepdick]

It does not have to be source-code. In only has to specify the actual behavior of the actual input.

This right here is why you don't understand the issue.

You can't specify the "actual behavior" of a self-modifying program at compile-time, because a self-modifying program changes its own "actual behavior" at runtime!

That is the essence of reflective programming.

That is why you can't have H interpret the behavior of P, because P interprets and alters its own behavior.

You are stuck in this limbo...

The earliest computers were programmed in their native assembly languages, which were inherently reflective, as these original architectures could be programmed by defining instructions as data and using self-modifying code. As the bulk of programming moved to higher-level compiled languages such as Algol, Cobol, Fortran, Pascal, and C, this reflective ability largely disappeared until new programming languages with reflection built into their type systems appeared.

A language supporting reflection provides a number of features available at runtime that would otherwise be difficult to accomplish in a lower-level language. Some of these features are the abilities to:

* Discover and modify source-code constructions (such as code blocks, classes, methods, protocols, etc.) as first-class objects at runtime.[/color]
* Convert a string matching the symbolic name of a class or function into a reference to or invocation of that class or function.
* Evaluate a string as if it were a source-code statement at runtime.[/color]
* Create a new interpreter for the language's bytecode to give a new meaning or purpose for a programming construct.[/color]

[PeteOlcott]

It doesn't take any of these things for a C function to analyze the x86 machine language trace of another C function.

Code: Select all

#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
[00001359](03)  8b4d08          mov ecx,[ebp+08]
[0000135c](01)  51              push ecx
[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

[Skepdick]

It doesn't take any of these things for a C function to analyze the x86 machine language trace of another C function.

Pete, you are a fucking bullshitter.

How have you obtained the "x86 execution trace" of a C program which doesn't compile to an x86 executable?

Code: Select all

#include <stdint.h>
#define u32 uint32_t
void P(u32 x)
{
  if (H(x, x))
    HERE: goto HERE;
  return;
}
int main()
{
   return H((u32)P, (u32)P);
}

This source code doesn't compile because H is undefined

Code: Select all

➜  ~ gcc -Wno-pointer-to-int-cast -Wno-implicit-function-declaration p.c
Undefined symbols for architecture x86_64:
  "_H", referenced from:
      _P in p-66fc8e.o
      _main in p-66fc8e.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This assembly is deceitful horseshit which doesn't correspond to the C source code because H is undefined!!!

Code: Select all

[0000137f](05)  e81efeffff      call 000011a2 // call H

[PeteOlcott]

It doesn't take any of these things for a C function to analyze the x86 machine language trace of another C function.

How have you obtained the "x86 execution trace" of a C program which doesn't compile to an x86 executable?

By reverse engineering what the behavior of the input to H(P,P) would be if we
assume that H performs a pure x86 emulation of its input for the first emulation
and the first nested emulation. The x86 source-code of P specifies everything
that we need to know to do this.

Code: Select all

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

It is dead obvious that when H(P,P) correctly emulates its
input that the first 7 instructions of P are emulated. It is also dead
obvious that when P calls H(P,P) that H emulates the first 7 instructions
of P again.

[Skepdick]

By reverse engineering what the behavior of the input to H(P,P) would be if we
assume that H performs a pure x86 emulation of its input for the first emulation
and the first nested emulation. The x86 source-code of P specifies everything
that we need to know to do this.

Code: Select all

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

It is dead obvious that when H(P,P) correctly emulates its
input that the first 7 instructions of P are emulated. It is also dead
obvious that when P calls H(P,P) that H emulates the first 7 instructions
of P again.

Seriously. who are you trying to bullshit? Your peers?

Do you actually understand the concept of a dependency?

The C source code depends on the source code of function H. Which you have failed to provide!.
The Assembly source which starts at memory address 00001352 and ends at address 0000136c depends on memory address 000011a2 (outside the bounds of 00001352-0000136c). Which you have failed to provide!

Both representations (C and Assembly) have dependencies - the function H (memory address 000011a2). Which you continuously refuse to provide.

It is dead obvious to any non-idiot (and you are excluded from this category) that if H needs to emulate P, then P needs to emulate H also.

And if H can emulate P, then P can emulate H emulating P.
And if P can emulate H emulating P, then H can emulate P emulating H emulating P.
ANd if H can emulate P emulating H emulating P then P can emulate H emulating P emulating H emulating P.

Ad infinitum.


P depends on H.
H depends on P.
P and H depend on each other!

Therefore you need to provide the source code for H and P!


The fact that you continue to withhold the source code for H despite numerous requests to furnish it only speaks to your intellectual dishonesty and utter lack of integrity.

[PeteOlcott]

I only glanced at your words for a half second to realize that you are still denying the dead obvious verified facts.

[Skepdick]

I only glanced at your words for a half second to realize that you are still denying the dead obvious verified facts.

That only speaks to your inability to process feedback and correct your work. There are no facts in your work - only bullshit.

I am denying the validity of your methodology and dismissing your conclusions.
On the basis of your intellectual dishonesty and continual witholding the source code (in C or Assembly) for H.

Your "analysis" is a fabrication because your source code doesn't compile to X86.
And if it doesn't compile to x86 there's no way to execute it.
And if there's no way to execute it - there's no way for you to produce that trace.
And if there's no way to produce the trace - there's no way to analyse the trace.

Your work fails to meet the scientific criterion of reproducibility.
Your data is manufactured.

[PeteOlcott]

I only glanced at your words for a half second to realize that you are still denying the dead obvious verified facts.

That only speaks to your inability to process feedback and correct your work - There are no facts in your work - only bullshit.

Ah so you simply "do not believe in" x86 assembly language.