P was designed to model the standard pseudo-code halting problem proofs.
P calls H with its own machine address and then the does opposite of
whatever H decides.

These standard proofs have been understood to show that no universal
halt decider could possibly exist because such a decider would have to
be able to correctly decide whether or not an input like P halts.

The simple way around this problem is to define a halt decider that
simulates its inputs as its halt deciding basis. When we do this then an
input such as P can be determined to call H in infinite recursion.

H is able to recognize the infinitely repeating behavior of P and aborts
its simulation of P before ever returning any value to P. This makes it
impossible for P do do the opposite of whatever H decides.

procedure compute_g(i):
if f(i, i) == 0 then
return 0
else
loop forever // (Wikipedia:Halting Problem)

Here is the concrete version of the pseudo-code. It is written in C and
executed in the x86utm operating system.

// Simplified version of the Peter Linz Ĥ
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

The above is fully operational in the x86utm operating system, it is
based on an x86 emulator that does a debug step trace of its input. It
examines the stored execution trace after it simulates each instruction
of this input.

*Three key elements refuting the pseudo-code HP proof*
(a) We can know that the input to H(P,P) is input that never halts with
100% perfect certainty on the basis of the x86 execution trace of P(P)
shown below.

(b) This means that we can know with 100% perfect certainty that a
simulating halt decider must abort its simulation of its input.

(c) This means that we can know with 100% perfect certainty that a
simulating halt decider correctly reports that this input never halts.

Begin Halt Decider Simulation at Machine Address:b10
[00000b10][002115d3][002115d7] 55 push ebp
[00000b11][002115d3][002115d7] 8bec mov ebp,esp
[00000b13][002115cf][002015a3] 51 push ecx
[00000b14][002115cf][002015a3] 8b4508 mov eax,[ebp+08]
[00000b17][002115cb][00000b10] 50 push eax // P
[00000b18][002115cb][00000b10] 8b4d08 mov ecx,[ebp+08]
[00000b1b][002115c7][00000b10] 51 push ecx // P
[00000b1c][002115c3][00000b21] e81ffeffff call 00000940 // H

[00000b10][0025bffb][0025bfff] 55 push ebp
[00000b11][0025bffb][0025bfff] 8bec mov ebp,esp
[00000b13][0025bff7][0024bfcb] 51 push ecx
[00000b14][0025bff7][0024bfcb] 8b4508 mov eax,[ebp+08]
[00000b17][0025bff3][00000b10] 50 push eax // P
[00000b18][0025bff3][00000b10] 8b4d08 mov ecx,[ebp+08]
[00000b1b][0025bfef][00000b10] 51 push ecx // P
[00000b1c][0025bfeb][00000b21] e81ffeffff call 00000940 // H
Infinite Recursion Detected Simulation Stopped

H ignores its own execution trace, thus when P calls H(P,P) this merely
invokes P(P). Anyone knowing the x86 language can easily see that none
of the above repeating eight instructions can possibly break this
repeating cycle.

Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott is a god damned spammer. do not help him anymore.

On 6/19/21 11:54 AM, olcott wrote:
> P was designed to model the standard pseudo-code halting problem proofs.
> P calls H with its own machine address and then the does opposite of
> whatever H decides.

First, the proofs are based on Turing Machines, so 'machine address'
isn't a valid concept, and in fact your requirement that P be in the
same code space as H actually means it is IMPOSSIBLE to consider H a
Universal Decider, as it can not be provided a program that overlaps the
address space of the program using the decider.

FATAL FLAW.

You really need to go back to your original concept when H was given the
file containing the COFF file of the program to decide, not the
'address' of the program to decide.

But this then shows the flaw in your design, so you won't do it.

>
> These standard proofs have been understood to show that no universal
> halt decider could possibly exist because such a decider would have to
> be able to correctly decide whether or not an input like P halts.
>
> The simple way around this problem is to define a halt decider that
> simulates its inputs as its halt deciding basis. When we do this then an
> input such as P can be determined to call H in infinite recursion.

No, you incorreected decide that P calls H in infinite recursion, the P
call to H is only infinite recursion if H will never terminate its
simulation, but then H will fail to provide an answer for deciding on P(P)

Once H does decide that it will abort at some point the simulation of P,
the we no longer actually have the infinite recursion that H thought it
detected, and thus it is incorrect.

>
> H is able to recognize the infinitely repeating behavior of P and aborts
> its simulation of P before ever returning any value to P. This makes it
> impossible for P do do the opposite of whatever H decides.

But since the first H still must return an answer to its caller (or it
won't be a decider) it still must return that answer to the top most P
when P is run as the machine, and that allows that P to still act
contrary to what H predicts.

>
> procedure compute_g(i):
>   if f(i, i) == 0 then
>     return 0
>   else
>     loop forever    // (Wikipedia:Halting Problem)
>
> Here is the concrete version of the pseudo-code. It is written in C and
> executed in the x86utm operating system.
>
> // Simplified version of the Peter Linz Ĥ
> void P(u32 x)
> {
>   u32 Input_Halts = H(x, x);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
> int main()
> {
>   u32 Input_Halts = H((u32)P, (u32)P);
>   Output("Input_Halts = ", Input_Halts);
> }

Which is of course the wrong test program.

We need to see what

int main()
{ P(u32)P);
Output("P Halted");
}

does too, as THAT is the real question being asked.

It WILL Halt. Thus H was wrong.

>
> The above is fully operational in the x86utm operating system, it is
> based on an x86 emulator that does a debug step trace of its input. It
> examines the stored execution trace after it simulates each instruction
> of this input.
>
> *Three key elements refuting the pseudo-code HP proof*
> (a) We can know that the input to H(P,P) is input that never halts with
> 100% perfect certainty on the basis of the x86 execution trace of P(P)
> shown below.
>
> (b) This means that we can know with 100% perfect certainty that a
> simulating halt decider must abort its simulation of its input.
>
> (c) This means that we can know with 100% perfect certainty that a
> simulating halt decider correctly reports that this input never halts.
>
> Begin Halt Decider Simulation at Machine Address:b10
> [00000b10][002115d3][002115d7] 55         push ebp
> [00000b11][002115d3][002115d7] 8bec       mov ebp,esp
> [00000b13][002115cf][002015a3] 51         push ecx
> [00000b14][002115cf][002015a3] 8b4508     mov eax,[ebp+08]
> [00000b17][002115cb][00000b10] 50         push eax          // P
> [00000b18][002115cb][00000b10] 8b4d08     mov ecx,[ebp+08]
> [00000b1b][002115c7][00000b10] 51         push ecx          // P
> [00000b1c][002115c3][00000b21] e81ffeffff call 00000940     // H
>
> [00000b10][0025bffb][0025bfff] 55         push ebp
> [00000b11][0025bffb][0025bfff] 8bec       mov ebp,esp
> [00000b13][0025bff7][0024bfcb] 51         push ecx
> [00000b14][0025bff7][0024bfcb] 8b4508     mov eax,[ebp+08]
> [00000b17][0025bff3][00000b10] 50         push eax         // P
> [00000b18][0025bff3][00000b10] 8b4d08     mov ecx,[ebp+08]
> [00000b1b][0025bfef][00000b10] 51         push ecx         // P
> [00000b1c][0025bfeb][00000b21] e81ffeffff call 00000940    // H
> Infinite Recursion Detected Simulation Stopped
>
> H ignores its own execution trace, thus when P calls H(P,P) this merely
> invokes P(P). Anyone knowing the x86 language can easily see that none
> of the above repeating eight instructions can possibly break this
> repeating cycle.
>
>
> Halting problem undecidability and infinitely nested simulation
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>

On 6/19/2021 11:31 AM, Richard Damon wrote:
> On 6/19/21 11:54 AM, olcott wrote:
>> P was designed to model the standard pseudo-code halting problem proofs.
>> P calls H with its own machine address and then the does opposite of
>> whatever H decides.
>
> First, the proofs are based on Turing Machines,
I say the house across the street is red and you say no I disagree the
house up the street two blocks away is not red.

The pseudo-code halting problem proofs are based on freaking pseudo-code
nitwit.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On Saturday, June 19, 2021 at 12:38:47 PM UTC-4, olcott wrote:
> On 6/19/2021 11:31 AM, Richard Damon wrote:
> > On 6/19/21 11:54 AM, olcott wrote:
> >> P was designed to model the standard pseudo-code halting problem proofs.
> >> P calls H with its own machine address and then the does opposite of
> >> whatever H decides.
> >
> > First, the proofs are based on Turing Machines,
> I say the house across the street is red and you say no I disagree the
> house up the street two blocks away is not red.
>
> The pseudo-code halting problem proofs are based on freaking pseudo-code
> nitwit.
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein
olcott is a god damned spammer. do not help him anymore.

On 6/19/21 12:39 PM, olcott wrote:
> On 6/19/2021 11:31 AM, Richard Damon wrote:
>> On 6/19/21 11:54 AM, olcott wrote:
>>> P was designed to model the standard pseudo-code halting problem proofs.
>>> P calls H with its own machine address and then the does opposite of
>>> whatever H decides.
>>
>> First, the proofs are based on Turing Machines,
> I say the house across the street is red and you say no I disagree the
> house up the street two blocks away is not red.
>
> The pseudo-code halting problem proofs are based on freaking pseudo-code
> nitwit.
>

No, They are all based on Turing Machines. READ THEM. Note, they might
use the term Computation, but that is a technical term in this context,
and it can be shown that all computation can be calculated by a Turing
Machine.

Show a REAL halting problem proof that doesn't refer back to Turing
Machines or Computation in the technical sense.

olcott is a god damned spammer. do not help him.
team of russian trolls

On 6/19/2021 12:49 PM, Daniel Pehoushek wrote:
> olcott is a god damned spammer. do not help him.
> team of russian trolls
>

This is my 2004 work on the same problem:
https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

Russian trolls on Facebook did not prove to be a problem until it was
shown that they interferred with the 2016 election.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 6/19/2021 12:03 PM, Richard Damon wrote:
> On 6/19/21 12:39 PM, olcott wrote:
>> On 6/19/2021 11:31 AM, Richard Damon wrote:
>>> On 6/19/21 11:54 AM, olcott wrote:
>>>> P was designed to model the standard pseudo-code halting problem proofs.
>>>> P calls H with its own machine address and then the does opposite of
>>>> whatever H decides.
>>>
>>> First, the proofs are based on Turing Machines,
>> I say the house across the street is red and you say no I disagree the
>> house up the street two blocks away is not red.
>>
>> The pseudo-code halting problem proofs are based on freaking pseudo-code
>> nitwit.
>>
>
> No, They are all based on Turing Machines. READ THEM. Note, they might
> use the term Computation, but that is a technical term in this context,
> and it can be shown that all computation can be calculated by a Turing
> Machine.
>
> Show a REAL halting problem proof that doesn't refer back to Turing
> Machines or Computation in the technical sense.

void P(u32 x)
{ u32 Input_Halts = H(x, x);
Output("P:Input_Halts:", Input_Halts);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

(a) We can know that the simulation of the input to H(P,P) never halts
with 100% perfect certainty on the basis of its x86 execution trace.

(b) This means that we can know with 100% perfect certainty that
simulating halt decider H must abort its simulation of its input (P,P).

(c) This means that we can know with 100% perfect certainty that
simulating halt decider H correctly reports that its input: (P,P) never
halts.

Clueless wonders can deny any one of these three steps on the basis of
ignorance or simply not paying attention.

What no one can do is point out any actual error in any of the above
steps because each of the above steps can be verified as completely true
entirely on the basis of the meaning of its words.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein