This is an explanation of a possible new insight into the halting
problem provided in the language of software engineering. Technical
computer science terms are explained using software engineering terms.
No knowledge of the halting problem is required.

When the conventional “pathological” input (that does the opposite of
whatever the halt decider decides) is the first argument to a simulating
halt decider then this input becomes decidable as specifying infinitely
recursive simulation.

This paper is based on fully operational software executed in the x86utm
operating system. The x86utm operating system (based on an excellent
open source x86 emulator) was created to study the details of the
halting problem proof counter-examples at the much higher level of
abstraction of C/x86.

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

// P does the opposite of whatever H decides
void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status) // if H(P,P) reports that its input halts
HERE: goto HERE; // P loops and never halts
return; // else P halts
}

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

A simulating halt decider (SHD) continues to simulate its input until
the behavior of this input matches a non-halting behavior pattern or the
simulated input halts on its own. If a non-halting behavior pattern is
matched the SHD aborts the simulation of its input and reports
non-halting. Otherwise as soon as the simulated input halts on its own
the SHD reports halting.

The execution trace of the above code (if the simulation is never aborted)
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...

When H(P,P) correctly predicts that its correct and complete x86
emulation of its input would never halt, then H aborts the simulation of
this input and correctly reports non-halting.

Since we can see that the correct and complete x86 emulation by H(P,P)
of its first argument would never halt, H can be adapted to see this too.

A halt decider must compute the mapping from its arguments to an accept
or reject state on the basis of the actual behavior that is actually
specified by these arguments. The correct x86 emulation by H(P,P) of its
first argument is the correct measure of the behavior of P.

*Halting problem proofs refuted on the basis of software engineering* ?

https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/16/2022 4:19 PM, olcott wrote:
> This is an explanation of a possible new insight into the halting
[...]

BARF! Puke...

On 8/16/2022 7:36 PM, Chris M. Thomasson wrote:
> On 8/16/2022 4:19 PM, olcott wrote:
>> This is an explanation of a possible new insight into the halting
> [...]
>
> BARF! Puke...
>

None-the-less now that I have simplified my explanation C programmers
can easily verify that H does correctly determine the halt status of the
halting problem's "impossible" input.

All rebuttals to my work have been based on the strawman deception and
did not actually provide any rebuttal to the words that I actually said.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/16/22 7:19 PM, olcott wrote:
> This is an explanation of a possible new insight into the halting
> problem provided in the language of software engineering. Technical
> computer science terms are explained using software engineering terms.
> No knowledge of the halting problem is required.

No knowledge of the Halting Problem is ALLOWED, because knowledge of it
shows the errors in the definitions and logic.

>
> When the conventional “pathological” input (that does the opposite of
> whatever the halt decider decides) is the first argument to a simulating
> halt decider then this input becomes decidable as specifying infinitely
> recursive simulation.

Except it isn't, as shown by an ACTUAL correct and complete trace of the
H, if the H answers the problem as non-halting.

>
> This paper is based on fully operational software executed in the x86utm
> operating system. The x86utm operating system (based on an excellent
> open source x86 emulator) was created to study the details of the
> halting problem proof counter-examples at the much higher level of
> abstraction of C/x86.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> // P does the opposite of whatever H decides
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)    // if H(P,P) reports that its input halts
>     HERE: goto HERE;  // P loops and never halts
>   return;             // else P halts
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> A simulating halt decider (SHD) continues to simulate its input until
> the behavior of this input matches a non-halting behavior pattern or the
> simulated input halts on its own. If a non-halting behavior pattern is
> matched the SHD aborts the simulation of its input and reports
> non-halting. Otherwise as soon as the simulated input halts on its own
> the SHD reports halting.
>
> The execution trace of the above code (if the simulation is never aborted)
> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...

Except if that IS what H does, then H never answer, and so isn't a decider.

>
> When H(P,P) correctly predicts that its correct and complete x86
> emulation of its input would never halt, then H aborts the simulation of
> this input and correctly reports non-halting.
>

Excpet that when it does THAT, then it doesn't actually do a correct and
complete simulation of its input, and the ACTUAL correct and complete
simulation of the input will trace the behavior of that input past the
point that H aborted its simulation of it, to the point where the H in
the simulation does that same abort, and then sees it return to its
caller and the input halt.

> Since we can see that the correct and complete x86 emulation by H(P,P)
> of its first argument would never halt, H can be adapted to see this too.

Excpet that the input only never halts if H never aborts. Since P, by
DEFINITION, is using the exact same algorithm in its copy of H as the H
that you claim is being correct in deciding,

>
> A halt decider must compute the mapping from its arguments to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these arguments. The correct x86 emulation by H(P,P) of its
> first argument is the correct measure of the behavior of P.

Nope. The ACUTAL correct and complete simulation of the input is. If H
doesn't do that, then we need to look at a simulation that does.

The only H you have proven generates a non-halting P, is the H that
NEVER aborts its simulation, and that one never gives the "correct" answer.

For any H that does abort, the input is now different than what was seen
in that case, since it is based on the H that is aborting, and we just
showed that for THAT input, it Halts, so H is incorrect.

>
>
> *Halting problem proofs refuted on the basis of software engineering* ?
>
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>

Just more of your lies, as explained above.

This has been explained to you MANY times, and you still don't seem to
understand it.

Either you are just mentally dificient and just can't learn these basic
facts, or you are just a pathelogical liar that doesn't care about what
is true.

You logic is JUST WRONG.

It is NOT "Correct Software Engineering Principles", it is just ERROR.

On 8/16/2022 6:19 PM, olcott wrote:
> This is an explanation of a possible new insight into the halting
> problem provided in the language of software engineering. Technical
> computer science terms are explained using software engineering terms.
> No knowledge of the halting problem is required.
>
> When the conventional “pathological” input (that does the opposite of
> whatever the halt decider decides) is the first argument to a simulating
> halt decider then this input becomes decidable as specifying infinitely
> recursive simulation.
>
> This paper is based on fully operational software executed in the x86utm
> operating system. The x86utm operating system (based on an excellent
> open source x86 emulator) was created to study the details of the
> halting problem proof counter-examples at the much higher level of
> abstraction of C/x86.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> // P does the opposite of whatever H decides
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)    // if H(P,P) reports that its input halts
>     HERE: goto HERE;  // P loops and never halts
>   return;             // else P halts
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> A simulating halt decider (SHD) continues to simulate its input until
> the behavior of this input matches a non-halting behavior pattern or the
> simulated input halts on its own. If a non-halting behavior pattern is
> matched the SHD aborts the simulation of its input and reports
> non-halting. Otherwise as soon as the simulated input halts on its own
> the SHD reports halting.
>
> The execution trace of the above code (if the simulation is never aborted)
> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...
>
> When H(P,P) correctly predicts that its correct and complete x86
> emulation of its input would never halt, then H aborts the simulation of
> this input and correctly reports non-halting.
>
> Since we can see that the correct and complete x86 emulation by H(P,P)
> of its first argument would never halt, H can be adapted to see this too.
>
> A halt decider must compute the mapping from its arguments to an accept
> or reject state on the basis of the actual behavior that is actually
> specified by these arguments. The correct x86 emulation by H(P,P) of its
> first argument is the correct measure of the behavior of P.
>
>
> *Halting problem proofs refuted on the basis of software engineering* ?
>
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>

*This now builds under Ubuntu 16.04 with Makefile*
https://www.liarparadox.org/2022_08_16.zip
This is the complete system that compiles under:

Microsoft Visual Studio Community 2017
https://visualstudio.microsoft.com/vs/older-downloads/

The above is still required to build Halt7.c
*I am planning on writing a ELF object file interface*
This means that the whole system will work under Linux.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 8/16/2022 6:59 PM, olcott wrote:
> On 8/16/2022 6:19 PM, olcott wrote:
>> This is an explanation of a possible new insight into the halting
>> problem provided in the language of software engineering. Technical
>> computer science terms are explained using software engineering terms.
>> No knowledge of the halting problem is required.
>>
>> When the conventional “pathological” input (that does the opposite of
>> whatever the halt decider decides) is the first argument to a
>> simulating halt decider then this input becomes decidable as
>> specifying infinitely recursive simulation.
>>
>> This paper is based on fully operational software executed in the
>> x86utm operating system. The x86utm operating system (based on an
>> excellent open source x86 emulator) was created to study the details
>> of the halting problem proof counter-examples at the much higher level
>> of abstraction of C/x86.
>>
>> typedef void (*ptr)();
>> int H(ptr p, ptr i); // simulating halt decider
>>
>> // P does the opposite of whatever H decides
>> void P(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)    // if H(P,P) reports that its input halts
>>      HERE: goto HERE;  // P loops and never halts
>>    return;             // else P halts
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(P, P));
>> }
>>
>> A simulating halt decider (SHD) continues to simulate its input until
>> the behavior of this input matches a non-halting behavior pattern or
>> the simulated input halts on its own. If a non-halting behavior
>> pattern is matched the SHD aborts the simulation of its input and
>> reports non-halting. Otherwise as soon as the simulated input halts on
>> its own the SHD reports halting.
>>
>> The execution trace of the above code (if the simulation is never
>> aborted)
>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>> (b) that simulates P(P) that calls a simulated H(P,P)
>> (c) that simulates P(P) that calls a simulated H(P,P)
>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>
>> When H(P,P) correctly predicts that its correct and complete x86
>> emulation of its input would never halt, then H aborts the simulation
>> of this input and correctly reports non-halting.
>>
>> Since we can see that the correct and complete x86 emulation by H(P,P)
>> of its first argument would never halt, H can be adapted to see this too.
>>
>> A halt decider must compute the mapping from its arguments to an
>> accept or reject state on the basis of the actual behavior that is
>> actually specified by these arguments. The correct x86 emulation by
>> H(P,P) of its first argument is the correct measure of the behavior of P.
>>
>>
>> *Halting problem proofs refuted on the basis of software engineering* ?
>>
>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>
>>
>
> *This now builds under Ubuntu 16.04 with Makefile*
> https://www.liarparadox.org/2022_08_16.zip
> This is the complete system that compiles under:
>
> Microsoft Visual Studio Community 2017
> https://visualstudio.microsoft.com/vs/older-downloads/
>
> The above is still required to build Halt7.c
> *I am planning on writing a ELF object file interface*
> This means that the whole system will work under Linux.

I have the code. I only have Microsoft Visual Studio Community 2022
Version 17.2.5. Your code should compile.

On 8/16/2022 9:35 PM, Chris M. Thomasson wrote:
> On 8/16/2022 6:59 PM, olcott wrote:
>> On 8/16/2022 6:19 PM, olcott wrote:
>>> This is an explanation of a possible new insight into the halting
>>> problem provided in the language of software engineering. Technical
>>> computer science terms are explained using software engineering
>>> terms. No knowledge of the halting problem is required.
>>>
>>> When the conventional “pathological” input (that does the opposite of
>>> whatever the halt decider decides) is the first argument to a
>>> simulating halt decider then this input becomes decidable as
>>> specifying infinitely recursive simulation.
>>>
>>> This paper is based on fully operational software executed in the
>>> x86utm operating system. The x86utm operating system (based on an
>>> excellent open source x86 emulator) was created to study the details
>>> of the halting problem proof counter-examples at the much higher
>>> level of abstraction of C/x86.
>>>
>>> typedef void (*ptr)();
>>> int H(ptr p, ptr i); // simulating halt decider
>>>
>>> // P does the opposite of whatever H decides
>>> void P(ptr x)
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)    // if H(P,P) reports that its input halts
>>>      HERE: goto HERE;  // P loops and never halts
>>>    return;             // else P halts
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> A simulating halt decider (SHD) continues to simulate its input until
>>> the behavior of this input matches a non-halting behavior pattern or
>>> the simulated input halts on its own. If a non-halting behavior
>>> pattern is matched the SHD aborts the simulation of its input and
>>> reports non-halting. Otherwise as soon as the simulated input halts
>>> on its own the SHD reports halting.
>>>
>>> The execution trace of the above code (if the simulation is never
>>> aborted)
>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>
>>> When H(P,P) correctly predicts that its correct and complete x86
>>> emulation of its input would never halt, then H aborts the simulation
>>> of this input and correctly reports non-halting.
>>>
>>> Since we can see that the correct and complete x86 emulation by
>>> H(P,P) of its first argument would never halt, H can be adapted to
>>> see this too.
>>>
>>> A halt decider must compute the mapping from its arguments to an
>>> accept or reject state on the basis of the actual behavior that is
>>> actually specified by these arguments. The correct x86 emulation by
>>> H(P,P) of its first argument is the correct measure of the behavior
>>> of P.
>>>
>>>
>>> *Halting problem proofs refuted on the basis of software engineering* ?
>>>
>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>
>>>
>>
>> *This now builds under Ubuntu 16.04 with Makefile*
>> https://www.liarparadox.org/2022_08_16.zip
>> This is the complete system that compiles under:
>>
>> Microsoft Visual Studio Community 2017
>> https://visualstudio.microsoft.com/vs/older-downloads/
>>
>> The above is still required to build Halt7.c
>> *I am planning on writing a ELF object file interface*
>> This means that the whole system will work under Linux.
>
> I have the code. I only have Microsoft Visual Studio Community 2022
> Version 17.2.5. Your code should compile.
>

You can use the project file to build everything including Halt.c.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Tue, 16 Aug 2022 18:19:56 -0500
olcott <NoOne@NoWhere.com> wrote:

> This is an explanation of a possible new insight into the halting
> problem provided in the language of software engineering. Technical
> computer science terms are explained using software engineering
> terms. No knowledge of the halting problem is required.
>
> When the conventional “pathological” input (that does the opposite of
> whatever the halt decider decides) is the first argument to a
> simulating halt decider then this input becomes decidable as
> specifying infinitely recursive simulation.
>
> This paper is based on fully operational software executed in the
> x86utm operating system. The x86utm operating system (based on an
> excellent open source x86 emulator) was created to study the details
> of the halting problem proof counter-examples at the much higher
> level of abstraction of C/x86.
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> // P does the opposite of whatever H decides
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status) // if H(P,P) reports that its input halts
> HERE: goto HERE; // P loops and never halts
> return; // else P halts
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> A simulating halt decider (SHD) continues to simulate its input until
> the behavior of this input matches a non-halting behavior pattern or
> the simulated input halts on its own. If a non-halting behavior
> pattern is matched the SHD aborts the simulation of its input and
> reports non-halting. Otherwise as soon as the simulated input halts
> on its own the SHD reports halting.
>
> The execution trace of the above code (if the simulation is never
> aborted) (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...
>
> When H(P,P) correctly predicts that its correct and complete x86
> emulation of its input would never halt, then H aborts the simulation
> of this input and correctly reports non-halting.
>
> Since we can see that the correct and complete x86 emulation by
> H(P,P) of its first argument would never halt, H can be adapted to
> see this too.
>
> A halt decider must compute the mapping from its arguments to an
> accept or reject state on the basis of the actual behavior that is
> actually specified by these arguments. The correct x86 emulation by
> H(P,P) of its first argument is the correct measure of the behavior
> of P.
>
>
> *Halting problem proofs refuted on the basis of software engineering*
> ?
>
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

I think you meant to type: "Halting problem proofs not refuted on the
basis of serial incompetence."

/Flibble