Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Halting problem proofs refuted on the basis of software engineering (Simplified so that most anyone here can validate it)

144 views
Skip to first unread message

olcott

unread,
Jul 14, 2022, 3:20:00 PM7/14/22
to
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. No
knowledge of the halting problem is required.

It 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

void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

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

When simulating halt decider H(P,P) simulates its input we can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P).

The above shows that the simulated P cannot possibly terminate normally.
Because H can see the same (1)(2)(3) that we see H aborts its simulation
of P and rejects P as non-halting.

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

H and P implement the exact pathological relationship to each other as
described above. Because H(P,P) does handle this case the above halting
problem undecidable input template has been refuted.

*When this halt deciding principle understood to be correct*
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

*Then (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never terminate
normally, correctly rejects this input as non-halting.

*H is a Pure function*
https://en.wikipedia.org/wiki/Pure_function

thus implements a *Computable function*
https://en.wikipedia.org/wiki/Computable_function

Thus H is Turing computable.

*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

Mr Flibble

unread,
Jul 14, 2022, 3:29:03 PM7/14/22
to
You forgot to mention infinite recursion which I suppose is progress.

/Flibble

olcott

unread,
Jul 14, 2022, 4:02:42 PM7/14/22
to
I have proved that H(P,P) == 0 is correct.

I have shown that H/P does implement the HP's "impossible input" template.

Therefore I have refuted all of the halting problem proofs that rely on
this template.

Mr Flibble

unread,
Jul 14, 2022, 4:22:48 PM7/14/22
to
Equating pathological input with non-halting is erroneous: you are only
doing that because your broken solution treats it as "infinite
recursion". There is no recursion in [Strachey 1965] and the HP proofs
based on it.

/Flibble

Chris M. Thomasson

unread,
Jul 14, 2022, 4:27:43 PM7/14/22
to
On 7/14/2022 12:19 PM, olcott wrote:
> 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. No
> knowledge of the halting problem is required.
>
> It 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
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }

Where is the guts of function H?

Richard Harnden

unread,
Jul 14, 2022, 4:53:16 PM7/14/22
to
On 14/07/2022 21:27, Chris M. Thomasson wrote:
> On 7/14/2022 12:19 PM, olcott wrote:
>>
>> int H(ptr p, ptr i); // simulating halt decider
>
> Where is the guts of function H?

This doesn't exist. It never has, it never will.



olcott

unread,
Jul 14, 2022, 5:02:57 PM7/14/22
to
There is no recursion in any of the conventional proofs only because no
one ever previously bothered to fully examine how a simulating halt
decider would address these otherwise "impossible" inputs.

I first addressed this here: comp.theory (more than five years ago)
[Solution to one instance of the Halting Problem]
On 3/14/2017 9:05 AM, peteolcott wrote:

Prior to this I made this discovery:
"It looks like the original specification provided in the Linz text may
be infinitely recursive in that each TM requires its own input."

In this Researchgate paper:
Self Modifying Turing Machine (SMTM) Solution to the Halting Problem
(concrete example) August 2016 (almost six years ago)


This revision that I made today is much simpler than all the rest:
*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

olcott

unread,
Jul 14, 2022, 5:06:52 PM7/14/22
to
I have to refactor about 50 pages of code before I can publish it.
My current paper is so simple that H can be validated as correct without
any need to see its source-code.

olcott

unread,
Jul 14, 2022, 5:09:41 PM7/14/22
to
Try carefully studying the first page of my paper and see if you still
feel the same way. I have revised this paper thousands of times based on
many thousands or reviews. It is finally simple enough that most
everyone here can validate it.

Chris M. Thomasson

unread,
Jul 14, 2022, 5:16:50 PM7/14/22
to
Well, does refactor mean porting to another language/machine and/or
changing the actual logic of function H?

Chris M. Thomasson

unread,
Jul 14, 2022, 5:21:20 PM7/14/22
to
On 7/14/2022 2:09 PM, olcott wrote:
> On 7/14/2022 3:53 PM, Richard Harnden wrote:
>> On 14/07/2022 21:27, Chris M. Thomasson wrote:
>>> On 7/14/2022 12:19 PM, olcott wrote:
>>>>
>>>> int H(ptr p, ptr i); // simulating halt decider
>>>
>>> Where is the guts of function H?
>>
>> This doesn't exist.  It never has, it never will.
>>
>>
>>
>
> Try carefully studying the first page of my paper and see if you still
> feel the same way. I have revised this paper thousands of times based on
> many thousands or reviews. It is finally simple enough that most
> everyone here can validate it.
>
> *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
>
>

Can I code up H by reading the paper?

olcott

unread,
Jul 14, 2022, 5:25:03 PM7/14/22
to
No the actual code for H is clean, correct, complete and finally (after
nine months of work) Turing computable. It is the 50 pages of the x86utm
operating system that are still quite messy.

>>
>> *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
>>
>>
>


Chris M. Thomasson

unread,
Jul 14, 2022, 5:32:21 PM7/14/22
to
Slap a copyright on H, and state that it is as it is, and post it?

Say the docs are soon to come?

olcott

unread,
Jul 14, 2022, 5:32:36 PM7/14/22
to
No but you can verify that H(P,P) correctly determines the halt status
of the halting problem's "impossible" input by carefully studying the
first page of the paper.

Example 03 (on another page) has the annotated x86 source-code of P()
and main() the execution trace of main and the execution trace of P()
simulated by H().

In Example 03 I annotated the x86 source-code to make it much easier for
C programmers. I explain how each line of x86 code corresponds to its C
source.

olcott

unread,
Jul 14, 2022, 5:35:31 PM7/14/22
to
I want to hold that back so that academic journals have something brand
new never seen before that they can publish.

It really is very easy to validate my work without seeing the
source-code for H.

>
>>
>>>>
>>>> *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
>
>
>
>


Chris M. Thomasson

unread,
Jul 14, 2022, 5:40:15 PM7/14/22
to
On 7/14/2022 2:24 PM, olcott wrote:
> On 7/14/2022 4:16 PM, Chris M. Thomasson wrote:
>> On 7/14/2022 2:06 PM, olcott wrote:
>>> On 7/14/2022 3:27 PM, Chris M. Thomasson wrote:
>>>> On 7/14/2022 12:19 PM, olcott wrote:
[...]
>>>> Where is the guts of function H?
>>>>
>>>
>>> I have to refactor about 50 pages of code before I can publish it.
>>> My current paper is so simple that H can be validated as correct
>>> without any need to see its source-code.
>>
>> Well, does refactor mean porting to another language/machine and/or
>> changing the actual logic of function H?
>>
>
> No the actual code for H is clean, correct, complete and finally (after
> nine months of work) Turing computable. It is the 50 pages of the x86utm
> operating system that are still quite messy.
[...]

Humm... I still think I have a new fractal because I posted my ideas and
code about it, and so far... No hits about "I have seen this before".
You should just post your H code, and say the fifty pages of doc's are
well in progress. Fwiw, here is my code for said fractal:

https://fractalforums.org/fractal-mathematics-and-new-theories/28/experimental-tangent-fractal/4817/msg34795#new

read all. Can you get to the link? Also, just because docs are not 100%
in order, it can be interesting to post them anyway. To show progress in
a history, so to speak:

http://funwithfractals.atspace.cc/ct_cipher/

Click here:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=b8dfbc29229ce2a681ac17429316ce6e230066676e14f824acc106436f2ae64cd7d2535f41ecfc9aa189a486e568c232061ed41d9e59b015cc30b2f6df5fe99529b96f1c000005e56b839f1299fd3baf4353

;^)

Chris M. Thomasson

unread,
Jul 14, 2022, 5:45:50 PM7/14/22
to
On 7/14/2022 12:19 PM, olcott wrote:
Step by step docs, lol. By me. Why do you sort of seem a bit "afraid" to
post your own "cool" work:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/Pre-Alpha%20Rough%20Draft%20FFE%20Tutorial.pdf

olcott

unread,
Jul 14, 2022, 5:46:16 PM7/14/22
to
Another reason that I will not post the code is "Pearls before swine".
It really is easy to see that H(P,P) does correctly determine the halt
status of the halting problem's "impossible" input template on the first
page of my paper. People not willing to do that have not demonstrated
enough sincerity in the desire for an honest dialogue.

olcott

unread,
Jul 14, 2022, 5:57:50 PM7/14/22
to
It loses all patent rights once it is published.

Chris M. Thomasson

unread,
Jul 14, 2022, 6:21:38 PM7/14/22
to
Are you referring to transferring ownership to public domain?

Mr Flibble

unread,
Jul 14, 2022, 6:30:46 PM7/14/22
to
On Thu, 14 Jul 2022 16:02:35 -0500
I have shown that a simulating halt decider needn't be recursive in
nature:

https://github.com/i42output/halting-problem/blob/main/README.txt

/Flibble

olcott

unread,
Jul 14, 2022, 6:37:31 PM7/14/22
to
No. Because the halting problem proofs have withstood the test of 87
years of scrutiny my simple solution would pass the patent office's
requirement that a solution not be obvious.

olcott

unread,
Jul 14, 2022, 6:41:27 PM7/14/22
to
You sure do make it easy to review your work.

"When the simulator detects the call to H in P it forks
the simulation into a non-halting branch"

There is an infinite set of cases where this overly simplistic criteria
gets the wrong answer.

Chris M. Thomasson

unread,
Jul 14, 2022, 6:44:17 PM7/14/22
to
When do you feel that you are in a position to go ahead and submit your
work to a patent office? Less than a year?

olcott

unread,
Jul 14, 2022, 6:55:06 PM7/14/22
to
I could easily do it right now.
It only costs $100 to lock in patent rights for a year.

Chris M. Thomasson

unread,
Jul 14, 2022, 7:06:10 PM7/14/22
to
Be careful, and watch out for challenges!

Chris M. Thomasson

unread,
Jul 14, 2022, 7:07:16 PM7/14/22
to
Have you conducted a patent feasibility check, yet?

Chris M. Thomasson

unread,
Jul 14, 2022, 7:08:40 PM7/14/22
to
Do not let what happened to me happen to you!

olcott

unread,
Jul 14, 2022, 7:12:29 PM7/14/22
to
I have already prosecuted two of my own patents myself.
They are both currently in force. One of them seems to expire next
month. The other one is good until 2034.

olcott

unread,
Jul 14, 2022, 7:15:51 PM7/14/22
to
I already know the whole process from prosecuting two of my own patents
myself. I was wrong it only costs $75 to lock in patent rights for a
year for a micro entity. A provisional patent can be the whole actual
patent.

Chris M. Thomasson

unread,
Jul 14, 2022, 7:17:33 PM7/14/22
to
20070067770

Chris M. Thomasson

unread,
Jul 14, 2022, 7:18:36 PM7/14/22
to
A challenge, by say IBM?

Chris M. Thomasson

unread,
Jul 14, 2022, 7:19:15 PM7/14/22
to
Ever heard the term, my lawyers are bigger than yours?

olcott

unread,
Jul 14, 2022, 7:25:44 PM7/14/22
to
I don't want to continue to stray off-topic for this group. I only want
to focus on validating the software engineering of my paper.


*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


Chris M. Thomasson

unread,
Jul 14, 2022, 8:15:48 PM7/14/22
to
Show code that we all can compile, show H?

Siri Cruise

unread,
Jul 14, 2022, 8:25:02 PM7/14/22
to
In article <taqbj4$2revn$1...@dont-email.me>,
"Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:

> Show code that we all can compile, show H?

Conjectures like Goldbach can be written as programs that halt
(on a counterexample) if false, and do not halt if true. Use a
halting decider to prove number theory conjectures, and I'll take
it seriously.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Chen sockpuppet. insults Islam. Mohammed

olcott

unread,
Jul 14, 2022, 8:33:37 PM7/14/22
to
On 7/14/2022 7:24 PM, Siri Cruise wrote:
> In article <taqbj4$2revn$1...@dont-email.me>,
> "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>
>> Show code that we all can compile, show H?
>
> Conjectures like Goldbach can be written as programs that halt
> (on a counterexample) if false, and do not halt if true. Use a
> halting decider to prove number theory conjectures, and I'll take
> it seriously.
>

I already addressed this. A computer program that has infallible
mathematical reasoning has a broader scope that a program that can
correctly determine whether or not another program will normally
terminate on some fixed finite string input.

Chris M. Thomasson

unread,
Jul 14, 2022, 8:51:54 PM7/14/22
to
On 7/14/2022 5:24 PM, Siri Cruise wrote:
> In article <taqbj4$2revn$1...@dont-email.me>,
> "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>
>> Show code that we all can compile, show H?
>
> Conjectures like Goldbach can be written as programs that halt
> (on a counterexample) if false, and do not halt if true. Use a
> halting decider to prove number theory conjectures, and I'll take
> it seriously.
>

Is a program that halts or not based on a random number, coin toss so to
speak, well, is that a valid program or not?

olcott

unread,
Jul 14, 2022, 9:00:40 PM7/14/22
to
All software random number generators are pseudo-random and depend on a
defined process. Hardware random number generators exist, yet are
outside the scope of pure mathematical analysis.

Richard Damon

unread,
Jul 14, 2022, 9:22:15 PM7/14/22
to

On 7/14/22 4:02 PM, olcott wrote:

> I have proved that H(P,P) == 0 is correct.

No, you haven't. You have used unsound logic to make the claim. H(P,P)
returning 0 can't be correct, because P(P) Halts if H(P,P) returns 0,
and the behavior of the input to H(P,P) is the behavior of P(P) since
that is what P is asking about when it calls H)P,P).

>
> I have shown that H/P does implement the HP's "impossible input" template.

No, since P calls H(P,P) to ask it about P(P), but you claim that isn't
what it means. Therefore, you haven't implemented the "impossib;e input"
template.

Therefore either you are a Liar, or incompetent.

>
> Therefore I have refuted all of the halting problem proofs that rely on
> this template.
>
>

Nope, just prved you don't understand the template.

Siri Cruise

unread,
Jul 14, 2022, 9:28:20 PM7/14/22
to
In article <taqdmr$2rk1e$2...@dont-email.me>,
"Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:

> On 7/14/2022 5:24 PM, Siri Cruise wrote:
> > In article <taqbj4$2revn$1...@dont-email.me>,
> > "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
> >
> >> Show code that we all can compile, show H?
> >
> > Conjectures like Goldbach can be written as programs that halt
> > (on a counterexample) if false, and do not halt if true. Use a
> > halting decider to prove number theory conjectures, and I'll take
> > it seriously.
> >
>
> Is a program that halts or not based on a random number, coin toss so to
> speak, well, is that a valid program or not?

That's Microsoft Widows.

Chris M. Thomasson

unread,
Jul 14, 2022, 9:28:29 PM7/14/22
to
On 7/14/2022 6:00 PM, olcott wrote:
> On 7/14/2022 7:51 PM, Chris M. Thomasson wrote:
>> On 7/14/2022 5:24 PM, Siri Cruise wrote:
>>> In article <taqbj4$2revn$1...@dont-email.me>,
>>>   "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>>>
>>>> Show code that we all can compile, show H?
>>>
>>> Conjectures like Goldbach can be written as programs that halt
>>> (on a counterexample) if false, and do not halt if true. Use a
>>> halting decider to prove number theory conjectures, and I'll take
>>> it seriously.
>>>
>>
>> Is a program that halts or not based on a random number, coin toss so
>> to speak, well, is that a valid program or not?
>
> All software random number generators are pseudo-random and depend on a
> defined process. Hardware random number generators exist, yet are
> outside the scope of pure mathematical analysis.
>

A rnd. No more, no less... So, your claims do not hold against it?

Chris M. Thomasson

unread,
Jul 14, 2022, 9:28:51 PM7/14/22
to
On 7/14/2022 6:28 PM, Siri Cruise wrote:
> In article <taqdmr$2rk1e$2...@dont-email.me>,
> "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>
>> On 7/14/2022 5:24 PM, Siri Cruise wrote:
>>> In article <taqbj4$2revn$1...@dont-email.me>,
>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>>>
>>>> Show code that we all can compile, show H?
>>>
>>> Conjectures like Goldbach can be written as programs that halt
>>> (on a counterexample) if false, and do not halt if true. Use a
>>> halting decider to prove number theory conjectures, and I'll take
>>> it seriously.
>>>
>>
>> Is a program that halts or not based on a random number, coin toss so to
>> speak, well, is that a valid program or not?
>
> That's Microsoft Widows.
>

LOL! :^)

Chris M. Thomasson

unread,
Jul 14, 2022, 9:29:18 PM7/14/22
to
Do you have access to a coin? ;^)

Richard Damon

unread,
Jul 14, 2022, 9:32:46 PM7/14/22
to
On 7/14/22 5:09 PM, olcott wrote:
> On 7/14/2022 3:53 PM, Richard Harnden wrote:
>> On 14/07/2022 21:27, Chris M. Thomasson wrote:
>>> On 7/14/2022 12:19 PM, olcott wrote:
>>>>
>>>> int H(ptr p, ptr i); // simulating halt decider
>>>
>>> Where is the guts of function H?
>>
>> This doesn't exist.  It never has, it never will.
>>
>>
>>
>
> Try carefully studying the first page of my paper and see if you still
> feel the same way. I have revised this paper thousands of times based on
> many thousands or reviews. It is finally simple enough that most
> everyone here can validate it.
>
> *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
>
>

Your rule (3) is incorrect, because you omit some of the algorithm of P
that can break the loop.

Unless you can show some proof that allows you to use this rule the way
you are using it, it is just an unproved (actually disproven) claim.

Your repeating this claim after it has been pointed out without
providing any actual rebutal of the pointing out of error shows that you
don't know what you are talking about.

Chris M. Thomasson

unread,
Jul 14, 2022, 9:34:39 PM7/14/22
to
On 7/14/2022 2:45 PM, olcott wrote:
> On 7/14/2022 4:39 PM, Chris M. Thomasson wrote:
>> On 7/14/2022 2:24 PM, olcott wrote:
>>> On 7/14/2022 4:16 PM, Chris M. Thomasson wrote:
>>>> On 7/14/2022 2:06 PM, olcott wrote:
>>>>> On 7/14/2022 3:27 PM, Chris M. Thomasson wrote:
>>>>>> On 7/14/2022 12:19 PM, olcott wrote:
>> [...]
>>>>>> Where is the guts of function H?
>>>>>>
>>>>>
>>>>> I have to refactor about 50 pages of code before I can publish it.
>>>>> My current paper is so simple that H can be validated as correct
>>>>> without any need to see its source-code.
>>>>
>>>> Well, does refactor mean porting to another language/machine and/or
>>>> changing the actual logic of function H?
>>>>
>>>
>>> No the actual code for H is clean, correct, complete and finally
>>> (after nine months of work) Turing computable. It is the 50 pages of
>>> the x86utm operating system that are still quite messy.
>> [...]
>>
>> Humm... I still think I have a new fractal because I posted my ideas
>> and code about it, and so far... No hits about "I have seen this
>> before". You should just post your H code, and say the fifty pages of
>> doc's are well in progress. Fwiw, here is my code for said fractal:
>>
>> https://fractalforums.org/fractal-mathematics-and-new-theories/28/experimental-tangent-fractal/4817/msg34795#new
>>
>>
>> read all. Can you get to the link? Also, just because docs are not
>> 100% in order, it can be interesting to post them anyway. To show
>> progress in a history, so to speak:
>>
>> http://funwithfractals.atspace.cc/ct_cipher/
>>
>> Click here:
>>
>> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=b8dfbc29229ce2a681ac17429316ce6e230066676e14f824acc106436f2ae64cd7d2535f41ecfc9aa189a486e568c232061ed41d9e59b015cc30b2f6df5fe99529b96f1c000005e56b839f1299fd3baf4353
>>
>>
>> ;^)
>
> Another reason that I will not post the code is "Pearls before swine".

If your work has any merit, let everybody see it! Right?

> It really is easy to see that H(P,P) does correctly determine the halt
> status of the halting problem's "impossible" input template on the first
> page of my paper. People not willing to do that have not demonstrated
> enough sincerity in the desire for an honest dialogue.
>

olcott

unread,
Jul 14, 2022, 9:44:20 PM7/14/22
to
There is no sense continuing this dialogue until after you carefully
study the first page of my paper:

*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

It really is easy to see that H(P,P) does correctly determine the halt
status of the halting problem's "impossible" input template on the
first page of my paper. People not willing to do that have not
demonstrated enough sincerity in the desire for an honest dialogue.



Chris M. Thomasson

unread,
Jul 14, 2022, 9:47:11 PM7/14/22
to
How do I construct H?

Richard Damon

unread,
Jul 14, 2022, 9:53:43 PM7/14/22
to
On 7/14/22 8:33 PM, olcott wrote:
> On 7/14/2022 7:24 PM, Siri Cruise wrote:
>> In article <taqbj4$2revn$1...@dont-email.me>,
>>   "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>>
>>> Show code that we all can compile, show H?
>>
>> Conjectures like Goldbach can be written as programs that halt
>> (on a counterexample) if false, and do not halt if true. Use a
>> halting decider to prove number theory conjectures, and I'll take
>> it seriously.
>>
>
> I already addressed this. A computer program that has infallible
> mathematical reasoning has a broader scope that a program that can
> correctly determine whether or not another program will normally
> terminate on some fixed finite string input.
>

And that is part of your problem, the Halting Problem isn't about
programs "normally terminating", but will the program terminate when it
is run. (on the "hardware" that such programs run is presumed idea so
the program won't stop unless it should stop).

It is NOT about anything else, in particular, not about what happens
when it is simulated by a program that doesn't EXACTLY replicate the
ideal hardware.

The fact that such a determination isn't actually prossible makes the
problem non-calculatable, not wrong.

This shows you claims about "not being the input" to be just dishonest
dodges, as the input (if done correctly) FULLY defines the behavior of
the machine, and thus all the behavior of that machine with that input
IS specified by the input, the machine just can't determine what it will
do in finite time as required to be a decider.

Mr Flibble

unread,
Jul 15, 2022, 2:23:52 AM7/15/22
to
On Thu, 14 Jul 2022 17:41:06 -0500
olcott <No...@NoWhere.com> wrote:

> On 7/14/2022 5:30 PM, Mr Flibble wrote:
> > On Thu, 14 Jul 2022 16:02:35 -0500
> > olcott <No...@NoWhere.com> wrote:
> >
> >> On 7/14/2022 3:22 PM, Mr Flibble wrote:
> >>> On Thu, 14 Jul 2022 15:02:21 -0500
> >>> olcott <No...@NoWhere.com> wrote:
> >>>
> >>>> On 7/14/2022 2:28 PM, Mr Flibble wrote:
> >>>>> On Thu, 14 Jul 2022 14:19:38 -0500
> >>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>
> >>>>>> 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. No knowledge of the halting problem is
> >>>>>> required.
> >>>>>>
> >>>>>> It 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
> >>>>>>
> >>>>>> *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
> >>>>>>
> >>>>>
> >>>>> You forgot to mention infinite recursion which I suppose is
> >>>>> progress.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> I have proved that H(P,P) == 0 is correct.
> >>>>
> >>>> I have shown that H/P does implement the HP's "impossible input"
> >>>> template.
> >>>>
> >>>> Therefore I have refuted all of the halting problem proofs that
> >>>> rely on this template.
> >>>
> >>> Equating pathological input with non-halting is erroneous: you are
> >>> only doing that because your broken solution treats it as
> >>> "infinite recursion". There is no recursion in [Strachey 1965]
> >>> and the HP proofs based on it.
> >>>
> >>> /Flibble
> >>>
> >>
> >> There is no recursion in any of the conventional proofs only
> >> because no one ever previously bothered to fully examine how a
> >> simulating halt decider would address these otherwise "impossible"
> >> inputs.
> >
> > I have shown that a simulating halt decider needn't be recursive in
> > nature:
> >
> > https://github.com/i42output/halting-problem/blob/main/README.txt
> >
> > /Flibble
> >
>
> You sure do make it easy to review your work.
>
> "When the simulator detects the call to H in P it forks
> the simulation into a non-halting branch"
>
> There is an infinite set of cases where this overly simplistic
> criteria gets the wrong answer.

That is neither an honest review or any kind of rebuttal: I have told
you before: assertions made without evidence can be dismissed without
evidence.

If you claim there are an infinite number of cases where it gets the
wrong answer then it shouldn't be too hard for to provide ONE case
backing up your claim.

/Flibble

olcott

unread,
Jul 15, 2022, 2:46:49 AM7/15/22
to
Sure:

void P(ptr x)
{
static int count = 3;
count--;
if (!count) goto exit;
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
exit:
return;
}

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


Chris M. Thomasson

unread,
Jul 15, 2022, 3:01:55 AM7/15/22
to
On 7/14/2022 6:53 PM, Richard Damon wrote:
> On 7/14/22 8:33 PM, olcott wrote:
>> On 7/14/2022 7:24 PM, Siri Cruise wrote:
>>> In article <taqbj4$2revn$1...@dont-email.me>,
>>>   "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>>>
>>>> Show code that we all can compile, show H?
>>>
>>> Conjectures like Goldbach can be written as programs that halt
>>> (on a counterexample) if false, and do not halt if true. Use a
>>> halting decider to prove number theory conjectures, and I'll take
>>> it seriously.
>>>
>>
>> I already addressed this. A computer program that has infallible
>> mathematical reasoning has a broader scope that a program that can
>> correctly determine whether or not another program will normally
>> terminate on some fixed finite string input.
>>
>
> And that is part of your problem, the Halting Problem isn't about
> programs "normally terminating", but will the program terminate when it
> is run.

Right. Program A just might terminate sometime after the last star in
the universe burns out, some really old red dwarf. Program B will
continue on forever. A halting decider should tell me that A will halt,
or not. It depends on the logic of program A. So, if olcott has solved
it, well, that is interesting.

Richard Damon

unread,
Jul 15, 2022, 7:48:56 AM7/15/22
to
I thought that program was illegal in your system as your system didn't
allow the use of static memory?

Note, P isn't a pure function, as there is a variable that affects it
that isn't an actual defined input.

Note, properly per a real definition of what a Halt Decider should do,
the H(P,P) needs to create a BRAND NEW instance of P to simulate, just
like starting a new program, so that P has ITS OWN copy of count, that
has been initialized to 3.

Remember, you have defined H to SIMULATE its input, which means that its
input is ISOLATED from the current environment, so it shouldn't be
accessing the count from the calling routine.

That is violating the concept of what is a computation.

Of course, you just don't understand ANY of that, which is why you think
you have actually acheived something when you haven't.


Remember, in the C context, Halting Deciders work on PROGRAMS, as
complete entities, because C functions don't represent represent the
Mathematical function BECAUSE they can cross communicate in ways that
aren't allowed.

WHen you try to translate that above code into a Turing Machine, you
will find out that if H sctually is a Turing Machine, based on using a
modified UTM to decide, the the P that the H will simulate will start
with its own value of count starting at 3.

Since P NEVER calls P, the first decrement from 3 to 2 is the ONLY
change in value that count will have.

H isn't allowed to access it to let its copy of P that it is simulating
to affect it.

You are just PROVING that you H isn't actually a Pure Function, as its
behavior is shown to be a changed by things other than its direct
parameters.

Richard Damon

unread,
Jul 15, 2022, 7:56:23 AM7/15/22
to
On 7/15/22 3:01 AM, Chris M. Thomasson wrote:
> On 7/14/2022 6:53 PM, Richard Damon wrote:
>> On 7/14/22 8:33 PM, olcott wrote:
>>> On 7/14/2022 7:24 PM, Siri Cruise wrote:
>>>> In article <taqbj4$2revn$1...@dont-email.me>,
>>>>   "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>>>>
>>>>> Show code that we all can compile, show H?
>>>>
>>>> Conjectures like Goldbach can be written as programs that halt
>>>> (on a counterexample) if false, and do not halt if true. Use a
>>>> halting decider to prove number theory conjectures, and I'll take
>>>> it seriously.
>>>>
>>>
>>> I already addressed this. A computer program that has infallible
>>> mathematical reasoning has a broader scope that a program that can
>>> correctly determine whether or not another program will normally
>>> terminate on some fixed finite string input.
>>>
>>
>> And that is part of your problem, the Halting Problem isn't about
>> programs "normally terminating", but will the program terminate when
>> it is run.
>
> Right. Program A just might terminate sometime after the last star in
> the universe burns out, some really old red dwarf. Program B will
> continue on forever. A halting decider should tell me that A will halt,
> or not. It depends on the logic of program A. So, if olcott has solved
> it, well, that is interesting.
>
>

Right. Mathematics (or at least this part of this branch) isn't
concerend so much about "Practical", but Theoretical.

Part of the key is that "time" isn't a factor, it is the number of steps
done (is if finite or infinite).

In one sense, the sequence of states from a given machine and input
appear INSTANTLY when the question is posed, and the question is about
the length of that sequence of states, is it finite or infinite.

If it is finite, then there is a "Last" state that has the answer.

If it is infinite, then there is no "Last" state to have an answer.

Just as mathematics talks about numbers that are bigger then the number
of particles in the universe without problem (and considers that finite)
so to is the computation that uses more state than the univese could
hold might be halting.

Mr Flibble

unread,
Jul 15, 2022, 8:06:36 AM7/15/22
to
On Fri, 15 Jul 2022 01:46:23 -0500
Nope; you seem to have forgotten that my decider is not recursive in
nature: my decider will correctly determine that that input is
pathological so will signal an exception.

/Flibble


olcott

unread,
Jul 15, 2022, 10:20:20 AM7/15/22
to
The above terminates normally so your decider gets the wrong answer.

olcott

unread,
Jul 15, 2022, 10:22:50 AM7/15/22
to
On 7/15/2022 2:01 AM, Chris M. Thomasson wrote:
> On 7/14/2022 6:53 PM, Richard Damon wrote:
>> On 7/14/22 8:33 PM, olcott wrote:
>>> On 7/14/2022 7:24 PM, Siri Cruise wrote:
>>>> In article <taqbj4$2revn$1...@dont-email.me>,
>>>>   "Chris M. Thomasson" <chris.m.t...@gmail.com> wrote:
>>>>
>>>>> Show code that we all can compile, show H?
>>>>
>>>> Conjectures like Goldbach can be written as programs that halt
>>>> (on a counterexample) if false, and do not halt if true. Use a
>>>> halting decider to prove number theory conjectures, and I'll take
>>>> it seriously.
>>>>
>>>
>>> I already addressed this. A computer program that has infallible
>>> mathematical reasoning has a broader scope that a program that can
>>> correctly determine whether or not another program will normally
>>> terminate on some fixed finite string input.
>>>
>>
>> And that is part of your problem, the Halting Problem isn't about
>> programs "normally terminating", but will the program terminate when
>> it is run.
>
> Right. Program A just might terminate sometime after the last star in
> the universe burns out, some really old red dwarf. Program B will
> continue on forever. A halting decider should tell me that A will halt,
> or not. It depends on the logic of program A. So, if olcott has solved
> it, well, that is interesting.
>
>

*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



Mr Flibble

unread,
Jul 15, 2022, 10:32:27 AM7/15/22
to
On Fri, 15 Jul 2022 09:19:59 -0500
It is a pathological input so neither halts nor doesn't halt:
pathological input is INVALID so the correct "answer" is to signal an
exception.

/Flibble

olcott

unread,
Jul 15, 2022, 11:07:57 AM7/15/22
to
So you don't know how static variables work?
I am not surprised.


void P(ptr x)
{
static int count = 0;
if (count++ >= 2) goto exit;
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
exit:
return;
}

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

_Pm()
[0000141e](01) 55 push ebp
[0000141f](02) 8bec mov ebp,esp
[00001421](03) 83ec08 sub esp,+08
[00001424](05) a100000000 mov eax,[00000000]
[00001429](03) 8945fc mov [ebp-04],eax
[0000142c](06) 8b0d00000000 mov ecx,[00000000]
[00001432](03) 83c101 add ecx,+01
[00001435](06) 890d00000000 mov [00000000],ecx
[0000143b](04) 837dfc02 cmp dword [ebp-04],+02
[0000143f](02) 7c02 jl 00001443
[00001441](02) eb1b jmp 0000145e
[00001443](03) 8b5508 mov edx,[ebp+08]
[00001446](01) 52 push edx
[00001447](03) 8b4508 mov eax,[ebp+08]
[0000144a](01) 50 push eax
[0000144b](05) e8defcffff call 0000112e
[00001450](03) 83c408 add esp,+08
[00001453](03) 8945f8 mov [ebp-08],eax
[00001456](04) 837df800 cmp dword [ebp-08],+00
[0000145a](02) 7402 jz 0000145e
[0000145c](02) ebfe jmp 0000145c
[0000145e](02) 8be5 mov esp,ebp
[00001460](01) 5d pop ebp
[00001461](01) c3 ret
Size in bytes:(0068) [00001461]

_main()
[0000146e](01) 55 push ebp
[0000146f](02) 8bec mov ebp,esp
[00001471](05) 681e140000 push 0000141e
[00001476](05) 681e140000 push 0000141e
[0000147b](05) e8aefcffff call 0000112e
[00001480](03) 83c408 add esp,+08
[00001483](01) 50 push eax
[00001484](05) 685f050000 push 0000055f
[00001489](05) e820f1ffff call 000005ae
[0000148e](03) 83c408 add esp,+08
[00001491](02) 33c0 xor eax,eax
[00001493](01) 5d pop ebp
[00001494](01) c3 ret
Size in bytes:(0039) [00001494]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000146e][00102462][00000000] 55 push ebp
[0000146f][00102462][00000000] 8bec mov ebp,esp
[00001471][0010245e][0000141e] 681e140000 push 0000141e
[00001476][0010245a][0000141e] 681e140000 push 0000141e
[0000147b][00102456][00001480] e8aefcffff call 0000112e

H: Begin Simulation Execution Trace Stored at:11250e
Address_of_H:112e
[0000141e][001124fa][001124fe] 55 push ebp
[0000141f][001124fa][001124fe] 8bec mov ebp,esp
[00001421][001124f2][90909090] 83ec08 sub esp,+08
[00001424][001124f2][90909090] a100000000 mov eax,[00000000]
[00001429][001124f2][90909090] 8945fc mov [ebp-04],eax
[0000142c][001124f2][90909090] 8b0d00000000 mov ecx,[00000000]
[00001432][001124f2][90909090] 83c101 add ecx,+01
[00001435][001124f2][90909090] 890d00000000 mov [00000000],ecx
[0000143b][001124f2][90909090] 837dfc02 cmp dword [ebp-04],+02
[0000143f][001124f2][90909090] 7c02 jl 00001443
[00001441][001124f2][90909090] eb1b jmp 0000145e
[0000145e][001124fa][001124fe] 8be5 mov esp,ebp
[00001460][001124fe][00001217] 5d pop ebp
[00001461][00112502][0000141e] c3 ret
H: End Simulation Input Terminated Normally

[00001480][00102462][00000000] 83c408 add esp,+08
[00001483][0010245e][00000001] 50 push eax
[00001484][0010245a][0000055f] 685f050000 push 0000055f
[00001489][0010245a][0000055f] e820f1ffff call 000005ae
Input_Halts = 1
[0000148e][00102462][00000000] 83c408 add esp,+08
[00001491][00102462][00000000] 33c0 xor eax,eax
[00001493][00102466][00000018] 5d pop ebp
[00001494][0010246a][00000000] c3 ret
Number of Instructions Executed(1317) == 20 Pages

Mr Flibble

unread,
Jul 15, 2022, 11:19:07 AM7/15/22
to
On Fri, 15 Jul 2022 10:07:36 -0500
Of course I know how static variables work: in this case the static
variable is initialised to 3 when P is first entered and then
decremented however P is *not* called again as my decider is not
recursive so its value will stay at 2 and never reach zero meaning the
input is always pathological.
This is a different P that also is also always pathological in nature
which means your H is getting the answer wrong.

/Flibble

olcott

unread,
Jul 15, 2022, 11:27:24 AM7/15/22
to
Yet the actual behavior of the correct simulation of this input proves
that it halts. So although it is pathological this does not prevent its
halt status from being correctly determined.

Mr Flibble

unread,
Jul 15, 2022, 11:29:53 AM7/15/22
to
On Fri, 15 Jul 2022 10:27:04 -0500
No, this input is pathological in nature, i.e. a [Strachey 1965]
"impossible program" so to say it halts is incorrect.

/Flibble

Mr Flibble

unread,
Jul 15, 2022, 11:49:16 AM7/15/22
to
On Fri, 15 Jul 2022 10:07:36 -0500
For this particular stack trace I notice that the function symbol at
the top of it is Pm not P which suggests to me one of two things:

1) It is not the actual trace of the input you posted with it,
or
2) There is something wrong with the compiler/linker you are using and
it is not initializing static variables correctly resulting in an early
termination.

If (1) is correct then you are a dishonest trolling fucktard; if (2) is
correct then I suggest you resolve that issue rather than assuming
incompetence in your honest reviewers.

/Flibble

olcott

unread,
Jul 15, 2022, 11:58:33 AM7/15/22
to
I already had a P so I renamed it to Pm so it would not disturb my
existing code. When I changed all the Pm references to your name I
forgot one.

> 1) It is not the actual trace of the input you posted with it,
> or
> 2) There is something wrong with the compiler/linker you are using and
> it is not initializing static variables correctly resulting in an early
> termination.
>
> If (1) is correct then you are a dishonest trolling fucktard; if (2) is
> correct then I suggest you resolve that issue rather than assuming
> incompetence in your honest reviewers.
>
> /Flibble
>


Mr Flibble

unread,
Jul 15, 2022, 12:03:56 PM7/15/22
to
On Fri, 15 Jul 2022 10:58:14 -0500
Then I suggest you check the output of compilation/linking is actually
initializing static variables correctly. Are you even using a linker
or are you just executing an object file? Static data normally goes
into a separate data segment during the linking process.

/Flibble

olcott

unread,
Jul 15, 2022, 1:01:19 PM7/15/22
to
I haven't used static data in such a long time that I forgot the
compiler does not allocate any space for static variables unless they
have been initialized to a non-zero value.

void Pm(u32 x)
{
static int count = 0x777;
if (count++ > 0x777) goto exit;
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
exit:
return;
}

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


_Pm()
[00000a1a](01) 55 push ebp
[00000a1b](02) 8bec mov ebp,esp
[00000a1d](03) 83ec08 sub esp,+08
[00000a20](05) a107030000 mov eax,[00000307]
[00000a25](03) 8945fc mov [ebp-04],eax
[00000a28](06) 8b0d07030000 mov ecx,[00000307]
[00000a2e](03) 83c101 add ecx,+01
[00000a31](06) 890d07030000 mov [00000307],ecx
[00000a37](07) 817dfc77070000 cmp dword [ebp-04],00000777
[00000a3e](02) 7e02 jng 00000a42
[00000a40](02) eb1b jmp 00000a5d
[00000a42](03) 8b5508 mov edx,[ebp+08]
[00000a45](01) 52 push edx
[00000a46](03) 8b4508 mov eax,[ebp+08]
[00000a49](01) 50 push eax
[00000a4a](05) e8ebfdffff call 0000083a // call H
[00000a4f](03) 83c408 add esp,+08
[00000a52](03) 8945f8 mov [ebp-08],eax
[00000a55](04) 837df800 cmp dword [ebp-08],+00
[00000a59](02) 7402 jz 00000a5d
[00000a5b](02) ebfe jmp 00000a5b
[00000a5d](02) 8be5 mov esp,ebp
[00000a5f](01) 5d pop ebp
[00000a60](01) c3 ret
Size in bytes:(0071) [00000a60]

_main()
[00000a6a](01) 55 push ebp
[00000a6b](02) 8bec mov ebp,esp
[00000a6d](05) 681a0a0000 push 00000a1a // push address of P
[00000a72](05) 681a0a0000 push 00000a1a // push address of P
[00000a77](05) e8befdffff call 0000083a // call H
[00000a7c](03) 83c408 add esp,+08
[00000a7f](01) 50 push eax
[00000a80](05) 680b030000 push 0000030b
[00000a85](05) e8d0f8ffff call 0000035a
[00000a8a](03) 83c408 add esp,+08
[00000a8d](02) 33c0 xor eax,eax
[00000a8f](01) 5d pop ebp
[00000a90](01) c3 ret
Size in bytes:(0039) [00000a90]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00000a6a][0010137b][00000000] 55 push ebp
...[00000a6b][0010137b][00000000] 8bec mov ebp,esp
...[00000a6d][00101377][00000a1a] 681a0a0000 push 00000a1a
...[00000a72][00101373][00000a1a] 681a0a0000 push 00000a1a
...[00000a77][0010136f][00000a7c] e8befdffff call 0000083a
New slave_stack at:201427

Begin Local Halt Decider Simulation Execution Trace Stored at:21142f
...[00000a1a][0021141b][0021141f] 55 push ebp
...[00000a1b][0021141b][0021141f] 8bec mov ebp,esp
...[00000a1d][00211413][90909090] 83ec08 sub esp,+08
...[00000a20][00211413][90909090] a107030000 mov eax,[00000307]
...[00000a25][00211413][90909090] 8945fc mov [ebp-04],eax
...[00000a28][00211413][90909090] 8b0d07030000 mov ecx,[00000307]
...[00000a2e][00211413][90909090] 83c101 add ecx,+01
...[00000a31][00211413][90909090] 890d07030000 mov [00000307],ecx
...[00000a37][00211413][90909090] 817dfc77070000 cmp dword
[ebp-04],00000777
...[00000a3e][00211413][90909090] 7e02 jng 00000a42
...[00000a42][00211413][90909090] 8b5508 mov edx,[ebp+08]
...[00000a45][0021140f][00000a1a] 52 push edx // push
address of P
...[00000a46][0021140f][00000a1a] 8b4508 mov eax,[ebp+08]
...[00000a49][0021140b][00000a1a] 50 push eax // push
address of P
...[00000a4a][00211407][00000a4f] e8ebfdffff call 0000083a // call H
New slave_stack at:24be4f
...[00000a1a][0025be43][0025be47] 55 push ebp
...[00000a1b][0025be43][0025be47] 8bec mov ebp,esp
...[00000a1d][0025be3b][90909090] 83ec08 sub esp,+08
...[00000a20][0025be3b][90909090] a107030000 mov eax,[00000307]
...[00000a25][0025be3b][90909090] 8945fc mov [ebp-04],eax
...[00000a28][0025be3b][90909090] 8b0d07030000 mov ecx,[00000307]
...[00000a2e][0025be3b][90909090] 83c101 add ecx,+01
...[00000a31][0025be3b][90909090] 890d07030000 mov [00000307],ecx
...[00000a37][0025be3b][90909090] 817dfc77070000 cmp dword
[ebp-04],00000777
...[00000a3e][0025be3b][90909090] 7e02 jng 00000a42
...[00000a40][0025be3b][90909090] eb1b jmp 00000a5d // jmp to
exit
...[00000a5d][0025be43][0025be47] 8be5 mov esp,ebp
...[00000a5f][0025be47][00000904] 5d pop ebp
...[00000a60][0025be4b][00000a1a] c3 ret
...[00000a7c][0010137b][00000000] 83c408 add esp,+08
...[00000a7f][00101377][00000001] 50 push eax
...[00000a80][00101373][0000030b] 680b030000 push 0000030b
---[00000a85][00101373][0000030b] e8d0f8ffff call 0000035a
Input_Halts = 1
...[00000a8a][0010137b][00000000] 83c408 add esp,+08
...[00000a8d][0010137b][00000000] 33c0 xor eax,eax
...[00000a8f][0010137f][00100000] 5d pop ebp
...[00000a90][00101383][00000004] c3 ret
Number of Instructions Executed(27278)

Mr Flibble

unread,
Jul 15, 2022, 1:08:38 PM7/15/22
to
On Fri, 15 Jul 2022 12:00:59 -0500
Still seems wrong: post increment of the static variable should ensure
that it does NOT goto exit but instead should call H which should
presumably cause your "infinite recursion detected" bollocks to
manifest.

/Flibble

olcott

unread,
Jul 15, 2022, 1:27:16 PM7/15/22
to
On 7/15/2022 12:08 PM, Mr Flibble wrote:
> On Fri, 15 Jul 2022 12:00:59 -0500
> olcott <No...@NoWhere.com> wrote:
>

void Pm(ptr x)
{
static int count = 0x777;
if (count++ > 0x777) goto exit;
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
exit:
return;
}



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

_Pm()
[000013fa](01) 55 push ebp
[000013fb](02) 8bec mov ebp,esp
[000013fd](03) 83ec08 sub esp,+08
[00001400](05) a137050000 mov eax,[00000537]
[00001405](03) 8945fc mov [ebp-04],eax
[00001408](06) 8b0d37050000 mov ecx,[00000537]
[0000140e](03) 83c101 add ecx,+01
[00001411](06) 890d37050000 mov [00000537],ecx
[00001417](07) 817dfc77070000 cmp dword [ebp-04],00000777
[0000141e](02) 7e02 jng 00001422
[00001420](02) eb1b jmp 0000143d
[00001422](03) 8b5508 mov edx,[ebp+08]
[00001425](01) 52 push edx
[00001426](03) 8b4508 mov eax,[ebp+08]
[00001429](01) 50 push eax
[0000142a](05) e8dbfcffff call 0000110a
[0000142f](03) 83c408 add esp,+08
[00001432](03) 8945f8 mov [ebp-08],eax
[00001435](04) 837df800 cmp dword [ebp-08],+00
[00001439](02) 7402 jz 0000143d
[0000143b](02) ebfe jmp 0000143b
[0000143d](02) 8be5 mov esp,ebp
[0000143f](01) 5d pop ebp
[00001440](01) c3 ret
Size in bytes:(0071) [00001440]

_main()
[0000144a](01) 55 push ebp
[0000144b](02) 8bec mov ebp,esp
[0000144d](05) 68fa130000 push 000013fa
[00001452](05) 68fa130000 push 000013fa
[00001457](05) e8aefcffff call 0000110a
[0000145c](03) 83c408 add esp,+08
[0000145f](01) 50 push eax
[00001460](05) 683b050000 push 0000053b
[00001465](05) e820f1ffff call 0000058a
[0000146a](03) 83c408 add esp,+08
[0000146d](02) 33c0 xor eax,eax
[0000146f](01) 5d pop ebp
[00001470](01) c3 ret
Size in bytes:(0039) [00001470]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000144a][00102412][00000000] 55 push ebp
[0000144b][00102412][00000000] 8bec mov ebp,esp
[0000144d][0010240e][000013fa] 68fa130000 push 000013fa
[00001452][0010240a][000013fa] 68fa130000 push 000013fa
[00001457][00102406][0000145c] e8aefcffff call 0000110a

H: Begin Simulation Execution Trace Stored at:1124be
Address_of_H:110a
[000013fa][001124aa][001124ae] 55 push ebp
[000013fb][001124aa][001124ae] 8bec mov ebp,esp
[000013fd][001124a2][90909090] 83ec08 sub esp,+08
[00001400][001124a2][90909090] a137050000 mov eax,[00000537]
[00001405][001124a2][90909090] 8945fc mov [ebp-04],eax
[00001408][001124a2][90909090] 8b0d37050000 mov ecx,[00000537]
[0000140e][001124a2][90909090] 83c101 add ecx,+01
[00001411][001124a2][90909090] 890d37050000 mov [00000537],ecx
[00001417][001124a2][90909090] 817dfc77070000 cmp dword [ebp-04],00000777
[0000141e][001124a2][90909090] 7e02 jng 00001422
[00001422][001124a2][90909090] 8b5508 mov edx,[ebp+08]
[00001425][0011249e][000013fa] 52 push edx
[00001426][0011249e][000013fa] 8b4508 mov eax,[ebp+08]
[00001429][0011249a][000013fa] 50 push eax
[0000142a][00112496][0000142f] e8dbfcffff call 0000110a

H: Begin Simulation Execution Trace Stored at:15cee6
Address_of_H:110a
[000013fa][0015ced2][0015ced6] 55 push ebp
[000013fb][0015ced2][0015ced6] 8bec mov ebp,esp
[000013fd][0015ceca][90909090] 83ec08 sub esp,+08
[00001400][0015ceca][90909090] a137050000 mov eax,[00000537]
[00001405][0015ceca][90909090] 8945fc mov [ebp-04],eax
[00001408][0015ceca][90909090] 8b0d37050000 mov ecx,[00000537]
[0000140e][0015ceca][90909090] 83c101 add ecx,+01
[00001411][0015ceca][90909090] 890d37050000 mov [00000537],ecx
[00001417][0015ceca][90909090] 817dfc77070000 cmp dword [ebp-04],00000777
[0000141e][0015ceca][90909090] 7e02 jng 00001422
[00001420][0015ceca][90909090] eb1b jmp 0000143d
[0000143d][0015ced2][0015ced6] 8be5 mov esp,ebp
[0000143f][0015ced6][000011f3] 5d pop ebp
[00001440][0015ceda][000013fa] c3 ret
H: End Simulation Input Terminated Normally

[0000142f][001124a2][90909090] 83c408 add esp,+08
[00001432][001124a2][00000001] 8945f8 mov [ebp-08],eax
[00001435][001124a2][00000001] 837df800 cmp dword [ebp-08],+00
[00001439][001124a2][00000001] 7402 jz 0000143d
[0000143b][001124a2][00000001] ebfe jmp 0000143b
[0000143b][001124a2][00000001] ebfe jmp 0000143b
H: Infinite Loop Detected Simulation Stopped

[0000145c][00102412][00000000] 83c408 add esp,+08
[0000145f][0010240e][00000000] 50 push eax
[00001460][0010240a][0000053b] 683b050000 push 0000053b
[00001465][0010240a][0000053b] e820f1ffff call 0000058a
Input_Halts = 0
[0000146a][00102412][00000000] 83c408 add esp,+08
[0000146d][00102412][00000000] 33c0 xor eax,eax
[0000146f][00102416][00000018] 5d pop ebp
[00001470][0010241a][00000000] c3 ret
Number of Instructions Executed(887380) == 13244 Pages


> Still seems wrong: post increment of the static variable should ensure
> that it does NOT goto exit but instead should call H which should
> presumably cause your "infinite recursion detected" bollocks to
> manifest.
>
> /Flibble
>

I rewrote it so that my latest version of H could process it.
I was surprised and pleased that the version of H that has been
transformed into a computable function can still correctly perform
recursive emulation.

I was also surprised and pleased that H(Pm,Pm) determined that its input
is non-halting. It did not occur to me that the outer nested simulation
would return 1 to the inner nested simulation causing its P to get into
an infinite loop.

Mr Flibble

unread,
Jul 15, 2022, 1:28:17 PM7/15/22
to
OK, I've looked at your assembly trace and it is recursing into Pm from
H and then halting but I am not sure what you are trying to prove?
Again [Strachey 1965] and associated proofs are not recursive in nature.

/Flibble

olcott

unread,
Jul 15, 2022, 1:39:53 PM7/15/22
to
(1) H cannot correctly determine the halt status of the HP
counter-examples unless H is a simulating halt decider.

(2) The claim of the halting problem proofs is that no H in the universe
can possibly correctly determine the halt status of its corresponding
pathological input.

(3) H(P,P) does correctly determine that its correponding pathological
input would never halt.

(4) It is ridiculously stupid of you to say that [Strachey 1965] does
not specify infinitely recursive simulation when it is an easily
verified fact that when Strachey T <is> a simulating halt decider that
Strachey P <does> specify infinitely recursive simulation.

It does not say this directly in [Strachey 1965] only because no one
ever previously bothered to fully examine the effect of a simulating
halt decider on the HP's pathological inputs.

Mr Flibble

unread,
Jul 15, 2022, 1:46:34 PM7/15/22
to
On Fri, 15 Jul 2022 12:39:31 -0500
I see I have to repeat myself yet again: a simulating halt decider
needn't be recursive in nature and I have sketched a design of such a
halt decider:

https://github.com/i42output/halting-problem/blob/main/README.txt

You are incorrect to claim an equivalence between pathological input
and non-halting.

/Flibble


olcott

unread,
Jul 15, 2022, 1:58:15 PM7/15/22
to
19 When the simulator detects the call to H in P it forks the simulation
20 into a non-halting branch (returning 0 to P) and a halting branch
21 (returning 1 to P)

Software engineers at the low end of technical competence may not fully
comprehend the common knowledge that:

Whenever a function is called in what is essentially infinite recursion
this function cannot possibly correctly return any value to its caller.
You don't seem to understand that.

Mr Flibble

unread,
Jul 15, 2022, 2:04:57 PM7/15/22
to
On Fri, 15 Jul 2022 12:57:53 -0500
Why are you so fucking obtuse? My forking simulating decider IS NOT
RECURSIVE. My decider when detecting a call to H will NOT call it
but will instead fork the simulation into two COPIES and continue with
the next instruction after the call *as if* the call was made and
returned halting to one copy and not-halting to the other. This is no
less valid than your method of detecting a call to H and
instead of calling it, aborting your simulation.

/Flibble

olcott

unread,
Jul 15, 2022, 2:17:58 PM7/15/22
to
It is directly disobeying the actual behavior specified by the actual
input by returning a value to a function that called it in infinite
recursion.

Mr Flibble

unread,
Jul 15, 2022, 2:23:22 PM7/15/22
to
On Fri, 15 Jul 2022 13:17:37 -0500
There is no infinite recursion in [Strachey 1965]. There is no infinite
recursion in the proofs based on [Strachey 1965]. There is no infinite
recursion in my forking simulating decider. The only infinite recursion
is that infinite recursion associated with your broken decider.

/Flibble


olcott

unread,
Jul 15, 2022, 2:32:11 PM7/15/22
to
Even if we did accept that your pathological self-reference detector is
valid it is only a copycat of my idea and it provides a weaker result.
It answers: I don't know and mine answers: non-halting.

Because you did not even copycat my criteria correctly your H gets the
wrong answer on this input.

int add(int N)
{
return N + 3;
}

void Pc(ptr x)
{
H(add, (ptr)7);
return;
}

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

olcott

unread,
Jul 15, 2022, 2:35:04 PM7/15/22
to
The pathological input ([Strachey 1965] and others) to every simulating
halt decider specifies infinitely nested simulution to every simulating
halt decider.

Mr Flibble

unread,
Jul 15, 2022, 2:42:04 PM7/15/22
to
On Fri, 15 Jul 2022 13:31:50 -0500
I could trivially change my decider to return a decision of non-halting
instead of signaling an exception if I believed such a mapping was
correct, but I don't, so I won't.

>
> Because you did not even copycat my criteria correctly your H gets
> the wrong answer on this input.
>
> int add(int N)
> {
> return N + 3;
> }
>
> void Pc(ptr x)
> {
> H(add, (ptr)7);
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(Pc,Pc));
> }

My decider would correctly answer that Pc halts: passing a different
input to H would be equivalent to the call to H from main(), i.e. it
would be a function call rather than a fork detection: forks only
happen if H is called with the same input more than once.

/Flibble

Mr Flibble

unread,
Jul 15, 2022, 2:47:05 PM7/15/22
to
On Fri, 15 Jul 2022 13:34:43 -0500
My simulating halt decider does not have any infinite nesting or
infinite recursion.

/Flibble


Mr Flibble

unread,
Jul 15, 2022, 2:50:05 PM7/15/22
to
On Fri, 15 Jul 2022 13:31:50 -0500
Except if it returns an answer of non-halting there is no way to
differentiate between a non-halting non-pathological input and a
non-halting pathological input. Which is a mistake.

/Flibble

olcott

unread,
Jul 15, 2022, 3:04:43 PM7/15/22
to
https://github.com/i42output/halting-problem/blob/main/README.txt

You did not bother to copycat my criteria: "with the same input"
therefore your specification fails the above test.

When simulating halt decider H(P,P) simulates its input we can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P).

As already shown before you also did not bother to copycat my criteria
(3) which provides another escape route from non-termination.

When you add these crriteria I insist on a reference to my copyright
notice for these criteria.

*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


A copy of your github post as of 2022-07-15 1:58 PM CDT


Hi!

I have an idea for a simulating halt decider that forks the
simulation into two branches if the input calls the halt decider as
per [Strachey 1965]'s "Impossible Program":

void P(void (*x)())
{
if (H(x, x))
infinite_loop: goto infinite_loop;
return;
}

int main()
{
std::cout << "Input halts: " << H(P, P) << std::endl;
}

*When the simulator detects the call to H in P* it forks the simulation
into a non-halting branch (returning 0 to P) and a halting branch
(returning 1 to P) and continues the simulation of these two branches
in parallel.

If the non-halting branch is determined to halt AND the halting branch
is determined to not halt then pathology is detected and reported.

If EITHER branch is determined to be correctly decided then that will
be the decision of the halting decider.

Crucially this scheme will handle (and correctly decide) the
following case whereby the result of H is discarded by the input:

void Px(void (*x)())
{
(void) H(x, x);
return;
}

Thoughts? I am probably missing something obvious.

Mr Flibble

unread,
Jul 15, 2022, 3:11:31 PM7/15/22
to
On Fri, 15 Jul 2022 14:04:22 -0500
The only thing my decider and your decider have in common is that they
are both simulating halt deciders.

>
> When simulating halt decider H(P,P) simulates its input we can see
> that: (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P).
>
> As already shown before you also did not bother to copycat my
> criteria (3) which provides another escape route from non-termination.
>
> When you add these crriteria I insist on a reference to my copyright
> notice for these criteria.
>
> *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

No. You cannot copyright the idea of a simulating halt decider; you only
have a copyright for your broken simulating halt decider.

/Flibble

Skep Dick

unread,
Jul 15, 2022, 3:14:34 PM7/15/22
to
Pete,

We have gone over this stuff on PhilosophyNow a million times ( https://bit.ly/3APqNIt ).
I am telling you what these poor people are telling you.

Why are wasting everyone's time?!?

On Thursday, 14 July 2022 at 21:20:00 UTC+2, olcott wrote:
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }

Your code doesn't even compile!

If you just want to argue - then argue with your compiler/linker. Leave the poor souls alone!

➜ ~ gcc halt-decider.c
Undefined symbols for architecture x86_64:
"_H", referenced from:
_P in halt-decider-e72906.o
_main in halt-decider-e72906.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


Skep Dick

unread,
Jul 15, 2022, 3:20:57 PM7/15/22
to
On Friday, 15 July 2022 at 21:04:43 UTC+2, olcott wrote:
> Thoughts? I am probably missing something obvious.

Yeah. You are missing the most obvious things of all.

If H can execute P in a sandbox, then P can execute H in a sandbox.

Function H **executing** function P in isolated runtime is not the same thing as function H **calling** function P within the same runtime.

But, of course you know this. You are just going to conveniently ignore it (again) for your usual contrarian reasons.

It's really boresone that the only way you know how to learn is through conflict and exploiting Cunningham's law.





Mr Flibble

unread,
Jul 15, 2022, 3:23:44 PM7/15/22
to
That is my prose you are replying to not Olcott's, he just copy pasted
my idea from https://github.com/i42output/halting-problem

/Flibble

Skep Dick

unread,
Jul 15, 2022, 3:26:41 PM7/15/22
to
On Friday, 15 July 2022 at 21:23:44 UTC+2, Mr Flibble wrote:
> That is my prose you are replying to not Olcott's, he just copy pasted
> my idea from https://github.com/i42output/halting-problem
>
> /Flibble

Ah, right!

You are making the exact same conceptual error he's making.


Mr Flibble

unread,
Jul 15, 2022, 3:27:26 PM7/15/22
to
What error is that? My approach and Olcott's approach are quite
different.

/Flibble

olcott

unread,
Jul 15, 2022, 3:28:24 PM7/15/22
to
*I have a copyright on these words and every precise paraphrase*

When simulating halt decider H(P,P) simulates its input we can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P).

https://en.wikipedia.org/wiki/Paraphrasing_of_copyrighted_material

You are expressing using (1)
"When the simulator detects the call to H in P"
https://github.com/i42output/halting-problem/blob/main/README.txt

have referred to (2) after the fact when I pointed out that it was
missing from your spec

On 7/15/2022 1:41 PM, Mr Flibble wrote:
> ... if H is called with the same input more than once.

and have not bothered to correct the (false positive) error of your
specification by failing to include (3).

You may use the above three criteria in your spec only if you post my
copyright notice: Copyright 2022 PL Olcott

After you fully copycat my criteria your pathological reference detector
might be valid. You may not copycat this criteria without my copyright
notice.

*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


Mr Flibble

unread,
Jul 15, 2022, 3:34:14 PM7/15/22
to
On Fri, 15 Jul 2022 14:28:03 -0500
You cannot copyright the idea of a simulating halt decider and I have
not copied your words: your approach and my approach are quite
different; my approach works whilst your approach fails to decide the
following correctly:

void Px(void (*x)())
{
(void) H(x, x);
return;
}

Px always halts and my approach returns a correct decision of halting
whilst your approach returns an incorrect decision of non-halting
proving that our approaches are fundamentally different.

/Flibble


Scott Lurndal

unread,
Jul 15, 2022, 3:37:49 PM7/15/22
to
It's a very simple error. Your ridiculous back and forth has nothing
to do with either C++ or C. Please stop.

Skep Dick

unread,
Jul 15, 2022, 3:39:30 PM7/15/22
to
On Friday, 15 July 2022 at 21:27:26 UTC+2, Mr Flibble wrote:
> What error is that? My approach and Olcott's approach are quite
> different.

The approach is different. The error is the same.

Whatever strategy is available to H for evaluating P is also available to P for evaluating H.

So you will start with H(P) which branches into P(1) and P(0).
P(1) runs H(P(1)) - it returns a Boolean.
If H(P(1)) says P(1) halts then P(1) doesn't halt.
If H(P(1)) says P(1) doesn't halt then P(1) halts.

P(0) runs H(P(0)) - it returns a Boolean.
If H(P(0)) says P(0) halts then P(0) doesn't halt.
If H(P(0)) says that P(0) doesn't halt then P(0) halts.

H and P have a circular dependency on each other. When the branches keep branching you end up with a fork bomb.

https://en.wikipedia.org/wiki/Fork_bomb

Mr Flibble

unread,
Jul 15, 2022, 3:41:57 PM7/15/22
to
However H and P are not equivalent: H is a "special" function known to
the simulator.

/Flibble

olcott

unread,
Jul 15, 2022, 3:49:13 PM7/15/22
to
On 7/15/2022 2:14 PM, Skep Dick wrote:
> Pete,
>
> We have gone over this stuff on PhilosophyNow a million times ( https://bit.ly/3APqNIt ).
> I am telling you what these poor people are telling you.
>
> Why are wasting everyone's time?!?
>
> On Thursday, 14 July 2022 at 21:20:00 UTC+2, olcott wrote:
>> typedef void (*ptr)();
>> int H(ptr p, ptr i); // simulating halt decider
>>
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>
> Your code doesn't even compile!
>
> If you just want to argue - then argue with your compiler/linker. Leave the poor souls alone!
>

That I have not yet released my proprietary code is no indication
what-so-ever that this code does not exist. The halt decider code has
been finally transformed into a computable function and cleaned up so
that it could be released at any time. The 50 pages of the x86utm
operating system need much refactoring code clean up.

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

void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

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

When simulating halt decider H(P,P) simulates its input we can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P).

The above shows that the simulated P cannot possibly terminate normally.
H(P,P) simulates its input then P calls H(P,P) to simulate itself again.

Because H sees the same (1)(2)(3) that we see H can see that this
otherwise infinitely nested simulation would never end. H aborts its
simulation of P and rejects P as non-halting.

Competent software engineers can verify that the above is correct if
they can get over their strongly held false assumption that I must be
incorrect and actually carefully study the above analysis.

That this can be easily validated is indicated by thousands of reviews
that found no mistake in the claim that H does correctly determine that
the actual behavior of its actual input is correctly rejected as
non-halting.

The only "rebuttal" left is that some people believe that the halting
theorem requires H to determine the halt status of a sequence of
instructions that is not the actual behavior of the actual input.

People just can't believe that when H correctly simulates its input this
simulated input has different behavior than the direct execution of P(P)
even though this difference in behavior is an easily verified fact.

*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


Skep Dick

unread,
Jul 15, 2022, 3:53:18 PM7/15/22
to
On Friday, 15 July 2022 at 21:41:57 UTC+2, Mr Flibble wrote:
> However H and P are not equivalent: H is a "special" function known to
> the simulator.
Which is a configuration entirely not in the spirit of the halting problem.

We know that there are particular solutions to the halting problem.
We know that more powerful models of computations (Turing machines with Oracles) can solve the halting problem for less powerful models of computation (Turing machines without Oracles).

But the halting problem is explicit about seeking a general solution.

No model of computation can solve the halting problem for computational systems of equal power.

Skep Dick

unread,
Jul 15, 2022, 4:01:20 PM7/15/22
to
On Friday, 15 July 2022 at 21:49:13 UTC+2, olcott wrote:
> That I have not yet released my proprietary code is no indication
> what-so-ever that this code does not exist.

Yeah. It is. From P's perspective H doesn't exist.
From the compiler's perspective H doesn't exist.

Obviously - it's undefined.

>The halt decider code has
> been finally transformed into a computable function and cleaned up so
> that it could be released at any time. The 50 pages of the x86utm
> operating system need much refactoring code clean up.

Great! When you release the source code, I will happily do the following...

P launches a virtual machine (QEMU, VMware, EC2 - doesn't matter).
This virtual machine will run your x86utm operating system and will contain your halting decider H.
I will proceed to execute the halting decider

If QEMU running x86utm running H running P decides that P halts then P goes into infinite loop.
If QEMU running x86utm running H running P decides that P doesn't halt then P halts.






olcott

unread,
Jul 15, 2022, 4:04:03 PM7/15/22
to
I am not solving the halting problem that would require that I present
an omniscient (all knowing) computer program.

I have correctly refuted the conventional halting problem proofs by
showing how a Turing a computable function would correctly determine the
halt status of the previously "impossible" pathological inputs.

*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

Skep Dick

unread,
Jul 15, 2022, 4:06:30 PM7/15/22
to
On Friday, 15 July 2022 at 22:04:03 UTC+2, olcott wrote:
> I have correctly refuted the conventional halting problem proofs by
> showing how a Turing a computable function would correctly determine the
> halt status of the previously "impossible" pathological inputs.

And I am refuting your refutation.

By showing you that if H can simulate P (with any input) to determine its result, then P can also simulate H (with any input) to determine its result.


olcott

unread,
Jul 15, 2022, 4:12:08 PM7/15/22
to
The DebugStep(*master_state, *slave_state, *decoded);
function of my x86utm operating system already embeds a world class x86
emulator to provide its core functionality.

Because the correctly emulated P calls H(P,P) in what is essentially
infinite recursion this correctly emulated P never reaches the point in
its execution trace where it can possibly do the opposite of whatever
H(P,P) returns.

It is quite common knowledge among software engineers that functions
called in infinite recursion never return to their caller.

olcott

unread,
Jul 15, 2022, 4:16:29 PM7/15/22
to
I am not solving the halting problem. I am refuting the conventional
proofs of the halting theorem by showing how a Turing computable
function correctly determines the halt status of the previously
"impossible" pathologocal inputs. That is 100% of the entire scope of my
project. References to things outside of this scope are not rebuttals.

Skep Dick

unread,
Jul 15, 2022, 4:19:36 PM7/15/22
to
On Friday, 15 July 2022 at 22:12:08 UTC+2, olcott wrote:
> The DebugStep(*master_state, *slave_state, *decoded);
> function of my x86utm operating system already embeds a world class x86
> emulator to provide its core functionality.
Great!

> Because the correctly emulated P calls H(P,P) in what is essentially
> infinite recursion this correctly emulated P never reaches the point in
> its execution trace where it can possibly do the opposite of whatever
> H(P,P) returns.
Precisely!

And the correctly emulated H(P,P) determines that P is stuck in an infinite loop, so the correctly emulated H(P,P) reports that P doesn't halt.

And what does P (which is correctly emulating H(P,P) ) do when it hears that H says it won't halt?

That's right!

It halts.


It is loading more messages.
0 new messages