I am cross-posting this to comp.lang.c and comp.lang.c++ because any
C/C++ professional can correctly answer it and the code is written in C.

#define u32 uint32_t

int Simulate(u32 P, u32 I)
{ ((void(*)(u32))P)(I);
return 1;
}

int D(u32 P)
{ if ( H(P, P) )
return 0;
return 1;
}

int main()
{ H((u32)D, (u32)D);
}

H is simulating partial halt decider based on an x86 emulator. Its input
is the machine address of a C function that has been cast to 32-bit
unsigned integer. H simulates its first parameter on the input of its
second parameter. In the above case H would simulate D(D).

--
Copyright 2021 Pete Olcott

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

STOP POSTING in comp.lang.c/c++.

On 5/29/2021 8:15 PM, Bonita Montero wrote:
> STOP POSTING in comp.lang.c/c++.

He's obviously not going to stop, so just killfile the idiot.

On 5/30/2021 2:18 PM, Kaz Kylheku wrote:
> On 2021-05-30, red floyd <no.spam.here@its.invalid> wrote:
>> On 5/29/2021 8:15 PM, Bonita Montero wrote:
>>> STOP POSTING in comp.lang.c/c++.
>>
>> He's obviously not going to stop, so just killfile the idiot.
>
> Why would you care whether those two killfile each other?
>

By suggesting that they kill-file then unnecessary chatter is reduced.

This seems to be the final draft of the diagonalization argument's
error. I am very very happy that you suggested that I look into that. I
was able to completely abolish the contradiction.

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

--
Copyright 2021 Pete Olcott

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

> By suggesting that they kill-file then unnecessary chatter is reduced.
> This seems to be the final draft of the diagonalization argument's
> error. I am very very happy that you suggested that I look into that. I
> was able to completely abolish the contradiction.
> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument

Your stop-problem-issues are interesting no one here.
They're generic to any language, so they're off-topic here.

On 5/30/2021 11:18 PM, Bonita Montero wrote:
>> By suggesting that they kill-file then unnecessary chatter is reduced.
>> This seems to be the final draft of the diagonalization argument's
>> error. I am very very happy that you suggested that I look into that.
>> I was able to completely abolish the contradiction.
>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>
>
> Your stop-problem-issues are interesting no one here.
> They're generic to any language, so they're off-topic here.
>

Kaz was my best reviewer.

--
Copyright 2021 Pete Olcott

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

>>> By suggesting that they kill-file then unnecessary chatter is reduced.
>>> This seems to be the final draft of the diagonalization argument's
>>> error. I am very very happy that you suggested that I look into that.
>>> I was able to completely abolish the contradiction.
>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument

>> Your stop-problem-issues are interesting no one here.
>> They're generic to any language, so they're off-topic here.

> Kaz was my best reviewer.

Then Kaz made the same mistake like you.

On 5/31/2021 12:24 AM, Bonita Montero wrote:
>>>> By suggesting that they kill-file then unnecessary chatter is reduced.
>>>> This seems to be the final draft of the diagonalization argument's
>>>> error. I am very very happy that you suggested that I look into
>>>> that. I was able to completely abolish the contradiction.
>>>>
>
>
>>> Your stop-problem-issues are interesting no one here.
>>> They're generic to any language, so they're off-topic here.
>
>> Kaz was my best reviewer.
>
> Then Kaz made the same mistake like you.
>

Kaz suggested that I study diagonalization and now I can easily refute
this much simpler proof. My refutation is on page 1 and Sipser's whole
proof is on page 2. So far the only critiques have been about punctuation.

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

--
Copyright 2021 Pete Olcott

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

>>>>> By suggesting that they kill-file then unnecessary chatter is reduced.
>>>>> This seems to be the final draft of the diagonalization argument's
>>>>> error. I am very very happy that you suggested that I look into
>>>>> that. I was able to completely abolish the contradiction.

>>>> Your stop-problem-issues are interesting no one here.
>>>> They're generic to any language, so they're off-topic here.

>>> Kaz was my best reviewer.

>> Then Kaz made the same mistake like you.

> Kaz suggested that I study diagonalization and now I can easily refute
> this much simpler proof. My refutation is on page 1 and Sipser's  whole
> proof is on page 2. So far the only critiques have been about punctuation.
> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument

Are you stupid ? It's no matter what Kaz said.
HERE IS THE WRONG PLACE !

On 5/31/2021 1:14 AM, Bonita Montero wrote:
>>>>>> By suggesting that they kill-file then unnecessary chatter is
>>>>>> reduced.
>>>>>> This seems to be the final draft of the diagonalization argument's
>>>>>> error. I am very very happy that you suggested that I look into
>>>>>> that. I was able to completely abolish the contradiction.
>
>>>>> Your stop-problem-issues are interesting no one here.
>>>>> They're generic to any language, so they're off-topic here.
>
>>>> Kaz was my best reviewer.
>
>>> Then Kaz made the same mistake like you.
>
>> Kaz suggested that I study diagonalization and now I can easily refute
>> this much simpler proof. My refutation is on page 1 and Sipser's
>> whole proof is on page 2. So far the only critiques have been about
>> punctuation.
>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>
>
> Are you stupid ? It's no matter what Kaz said.
> HERE IS THE WRONG PLACE !
>

If here really was the wrong place then I would not have been able to
get Kaz to come back to comp.theory by posting here.

--
Copyright 2021 Pete Olcott

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

> If here really was the wrong place then I would not have been
> able to get Kaz to come back to comp.theory by posting here.

No matter what you say - your halting-problem-idea are always
off-topic here.

Not to feed the troll, which apparently the poster is, but just saying
their piece of code is horrendously non-portable.

- It's not going to work on any platform on which function pointers are
not 32-bit wide. If you absolutely want to cast integers to pointers and
conversely, use uintptr_t.

- Oh, and I don't see the point of defining u32. Grow up and use the
standard types. That just contributes to making things unreadable in the
end. Why not redefine keywords while you're at it.

On 5/31/2021 10:00 AM, Guillaume wrote:
> Not to feed the troll, which apparently the poster is, but just saying
> their piece of code is horrendously non-portable.
>
> - It's not going to work on any platform on which function pointers are
> not 32-bit wide. If you absolutely want to cast integers to pointers and
> conversely, use uintptr_t.
>
> - Oh, and I don't see the point of defining u32. Grow up and use the
> standard types. That just contributes to making things unreadable in the
> end. Why not redefine keywords while you're at it.
>

I created a whole 32-bit operating system that runs on Windows and
Linux. x86utm directly executes COFF object files compiled with the
Microsoft C compiler. The purpose of this system is to examine the
halting problem concretely at the high level of abstraction of the C
programming language.

Since these programs only need to run in the x86utm operating system
portability is moot. The operating system itself is portable.

This system does concretely prove that the halting problem decider/input
pairs are decidable as non halting.

#define u32 uint32_t

int Simulate(u32 P, u32 I)
{ ((void(*)(u32))P)(I);
return 1;
}

int D(u32 P) // P is a machine address
{ if ( H(P, P) )
return 0 // reject when H accepts
return 1; // accept when H rejects
}

int main()
{ H((u32)D, (u32)D);
}

We can know that simulating halt decider H must stop simulating its
input because if H did not stop simulating its input then D would have
the same halting behavior as if D called Simulate instead of H.

The above analysis is confirmed by actual execution of the above
function in the x86utm operating system. H detects an infinitely
repeating non-halting pattern that never reaches the second line of D.
Because the execution of D would be infinite if D did not abort its
simulation H can stop simulating D and decide not halting.

--
Copyright 2021 Pete Olcott

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

On 31/05/2021 07:34, olcott wrote:
>
>
> If here really was the wrong place then I would not have been able to
> get Kaz to come back to comp.theory by posting here.
>
>
If this is the case then just post to comp.theory like I have done in this post.

Bonita Montero is right. C++ and C newsgroups should only discuss those languages.

Coincidence or you watch the youtube video too ?

H needs to detect H in H+ and then ignore H+ and keep H result.

In other words self-reference detecting and thus also contradiction
detecting.

Basically this reduces the halting problem to a
self-detection/reduction problem.

Cya,
Skybuck.

On 6/13/2021 9:15 AM, Skybuck Flying wrote:
> Coincidence or you watch the youtube video too ?
>
> H needs to detect H in H+ and then ignore H+ and keep H result.
>
> In other words self-reference detecting and thus also contradiction
> detecting.
>
> Basically this reduces the halting problem to a
> self-detection/reduction problem.
>
> Cya,
> Skybuck.
>

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

int main()
{ H((u32)P, (u32)P);
}

I have been working on this since 2018-12-13 when I first figured out
how to detect that P calls H in infinite recursion. I first figured out
that P call H in infinite recursion in August of 2016.

Since that time I created the x86utm operating system that directly
executes the COFF object file output of the Microsoft C compiler using a
powerful 32-bit x86 emulator.

The key feature of this operating system is this function:

u32 DebugStep(Registers* master_state,
Registers* slave_state,
Decoded_Line_Of_Code* decoded) {}

That executes the machine language of another C function in a separate
process context, one x86 instruction at a time.

*Every time that an x86 instruction is executed:*
(a) the next instruction to be simulated is returned in decoded and
stored in an execution trace list.

(b) The whole list is examined to determine whether or not it shows
infinite recursion or infinite loops.

(c) If the execution trace of the input shows infinite execution then H
aborts its simulation of this input and reports that its input does not
halt.

(d) If the execution trace of the input never shows infinite execution
then H is merely a simulator of this input until it halts on its own.

(1) Anyone that knows the x86 language well enough can know for sure
that simulating partial halt decider H must abort its simulation of P.
(see x86 execution trace below)

(2) Anyone that knows the theory of computation well enough knows that
any computation that never halts unless its simulation is aborted is a
non-halting computation.

(3) Putting (1) and (2) together proves that H stops its simulation of P
and correctly reports that P does not halt.

Begin Halt Decider Simulation at Machine Address:af8
[00000af8][0021157e][00211582] 55 push ebp
[00000af9][0021157e][00211582] 8bec mov ebp,esp
[00000afb][0021157a][0020154e] 51 push ecx
[00000afc][0021157a][0020154e] 8b4508 mov eax,[ebp+08]
[00000aff][00211576][00000af8] 50 push eax
[00000b00][00211576][00000af8] 8b4d08 mov ecx,[ebp+08]
[00000b03][00211572][00000af8] 51 push ecx
[00000b04][0021156e][00000b09] e81ffeffff call 00000928

[00000af8][0025bfa6][0025bfaa] 55 push ebp
[00000af9][0025bfa6][0025bfaa] 8bec mov ebp,esp
[00000afb][0025bfa2][0024bf76] 51 push ecx
[00000afc][0025bfa2][0024bf76] 8b4508 mov eax,[ebp+08]
[00000aff][0025bf9e][00000af8] 50 push eax
[00000b00][0025bf9e][00000af8] 8b4d08 mov ecx,[ebp+08]
[00000b03][0025bf9a][00000af8] 51 push ecx
[00000b04][0025bf96][00000b09] e81ffeffff call 00000928
Halt Decider: Infinite Recursion Detected Simulation Stopped

In column 3 of the prior two push instructions we can see that P pushed
its own machine address 0xaf8 onto the stack calling H(P,P) at 0x928 in
an infinitely repeating cycle of the first eight x86 instructions of P.

--
Copyright 2021 Pete Olcott

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

On 6/13/21 10:15 AM, Skybuck Flying wrote:
> Coincidence or you watch the youtube video too ?
>
> H needs to detect H in H+ and then ignore H+ and keep H result.
>
> In other words self-reference detecting and thus also contradiction
> detecting.
>
> Basically this reduces the halting problem to a
> self-detection/reduction problem.
>
> Cya,
> Skybuck.
>

A decider that can detect that it is in a self-reference like this can
take steps to try to solve it and get more cases right.

As I mentioned last year, IF you can solve that detection problem (which
isn't really possible in general with Turing Machines) you would detect
it and then check if either response gives a consistent results, so the
machine P(I) could be accurate decider to be Halting or Non-Halting. The
issue is that if P(I) halts when we return non-halting and doesn't halt
when we return halting (like H^ does) then we have no correct answer to
return.

The interesting question is what if we admit that we can't always decide
Halting, but can divide the machines into 3 classes, those that Halt,
those that Don't Halt, and those that act contrary by giving the decider
a third option to return.

The question comes, is such a division useful.

Of course the other part of the problem is that there will be other
cases which we won't be able to decide, not just this self-contradictory
case, so can we somehow detect this and allow the decider to return an
answer of not-provable.

The issue with this is that at least for the Halting Problem, the ONLY
cases that can REALLY be non-provable are non-halting machines, as any
machine that does halt can be proven in finite time that it halts just
by running it. Thus 'Not-Provable' becomes just a subset of Non-Halting,
so the machine that totally accurately decides Halting / Non-Halting /
Non-Provable could also be used to detect just Halting / Non-Halting,
which we know can't exist.