Simulating halt decider applied to conventional pathological input

[olcott]

After very extensive discussions (23 emails) with a leading computer
scientist I have a much simpler way to make my point.

typedef void (*ptr)();

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

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

*H and P implement this pathological relationship*
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

All of the conventional proofs of the halting problem (including the
diagonalization proof) correctly prove that H cannot possibly return a
correct halt status to its caller P.

None of these proofs ever notice that when H is a simulating halt
decider it cannot possibly correctly return any value to the simulated P
because no function that is (essentially) called in infinite recursion
ever returns to its caller.

This provides the basis for H(P,P) to correctly determine that its
correct and complete simulation of its input would never reach the final
state of this simulated input, thus never halts.

*Once this halt deciding principle is accepted*
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 this method is understood to implement that principle*
Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never reach its
final state, correctly rejects this input as non-halting.

--
Copyright 2022 Pete Olcott

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

[Juha Nieminen]

In comp.lang.c++ olcott <No...@nowhere.com> wrote:
> After very extensive discussions (23 emails) with a leading computer
> scientist I have a much simpler way to make my point.

At least you seem to be willing to engage in *some* kind of conversation
with experts on the matter.

I would still say that you could get much better feedback to your work
if you did all these posts in a forum dedicated to computer science and
mathematics with an active community of expects, rather than here in
some random usenet group (especially since usenet is almost dead, and
has been for over a decade).

[Mut...@dastardlyhq.com]

On Mon, 11 Jul 2022 09:20:09 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>In comp.lang.c++ olcott <No...@nowhere.com> wrote:
>> After very extensive discussions (23 emails) with a leading computer
>> scientist I have a much simpler way to make my point.
>
>At least you seem to be willing to engage in *some* kind of conversation
>with experts on the matter.

Its probably a friend of his.

>mathematics with an active community of expects, rather than here in
>some random usenet group (especially since usenet is almost dead, and
>has been for over a decade).

Not all that dead right now.

[olcott]

My proof is verified through software engineering and not verified
through computer science. The people in the comp.theory forum don't seem
to know jack shit about software engineering.

Most crucially they don't understand that a function called in infinite
recursion never returns to its caller.

[olcott]

On 7/11/2022 4:41 AM, Mut...@dastardlyhq.com wrote:
> On Mon, 11 Jul 2022 09:20:09 -0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>> In comp.lang.c++ olcott <No...@nowhere.com> wrote:
>>> After very extensive discussions (23 emails) with a leading computer
>>> scientist I have a much simpler way to make my point.
>>
>> At least you seem to be willing to engage in *some* kind of conversation
>> with experts on the matter.
>
> Its probably a friend of his.

No. He is a world class computer scientist that I reached out to at
random. He was unable to validate my work because he did not know the
x86 language. He found no mistakes with my work.

>
>> mathematics with an active community of expects, rather than here in
>> some random usenet group (especially since usenet is almost dead, and
>> has been for over a decade).
>
> Not all that dead right now.
>

[Mut...@dastardlyhq.com]

On Mon, 11 Jul 2022 08:24:38 -0500
olcott <No...@NoWhere.com> wrote:
>On 7/11/2022 4:41 AM, Mut...@dastardlyhq.com wrote:
>> On Mon, 11 Jul 2022 09:20:09 -0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>> In comp.lang.c++ olcott <No...@nowhere.com> wrote:
>>>> After very extensive discussions (23 emails) with a leading computer
>>>> scientist I have a much simpler way to make my point.
>>>
>>> At least you seem to be willing to engage in *some* kind of conversation
>>> with experts on the matter.
>>
>> Its probably a friend of his.
>
>No. He is a world class computer scientist that I reached out to at
>random. He was unable to validate my work because he did not know the
>x86 language. He found no mistakes with my work.

If he didn't validate it then he wouldn't find any mistakes would he. I imagine
he had more important things to do than get into a discussion with a crank.
Probably some urgent coffee to make or paper to shuffle.

[olcott]

On the basis of his feedback I rewrote the first page so that it can be
understood to be correct with only ordinary understanding of the C
programming language and software engineering.

The first page of this updated paper makes my point much more clearly in
that it requires no knowledge of the x86 assembly language. The
subsequent pages can be skipped.

Simulating halt decider H(P,P) detects that its simulated P is
essentially calling it in infinite recursion, H aborts its simulation of
this input then rejects it as non-halting.

typedef void (*ptr)();
int H(ptr p, ptr i);

void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, 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

[Richard Damon]

Except that P only calls H in infinite recursion if H doesn't know
enough to stop the recursion, at which point it can't answer non-halting.

If it DOES answer non-halting, then it never lets the infinite recursion
happen in the first place.

H can't use logic based on H never aborting if it DOES abort, as that
makes the logic invalid and unsound.

It is IMPOSSIBLE for H to do both, emulate forever and abort and answer
and be a "Pure Function" at the same time.

Your assumption that H can do this, or can decide in finite time is
flawed and based on incorrect assumptions and definitions.

[olcott]

I was able to simplify my presentation so that everyone here can easily
verify that I have correctly refuted the halting theorem on this pure
software engineering basis:

understanding that the simulated P essentially calls simulating halt
decider H in infinite recursion such that the simulated P cannot
possibly terminate normally.

*if you are saying that the simulated P can possibly*
*terminate normally then your software engineering*
*skills are woefully inadequate*

[Richard Damon]

P terminates normally if, and only if, H(P,P) returns 0.

Thus H(P,P) can NEVER be returning 0 correctly, since by the definition
of P that answer is wrong. Remember the DEFINITION of P, P will be given
an input so that it asks H to tell it what it will do given its input,
and then do the opposite. So if H says that P given P will never halt,
it will halt. (The only way P can fail is if H never returns, at which
point H fails to be the decider it is required to be).

The input to H(P,P) MUST represent P(P), or your P isn't written
correctly, as P is DEFINED to ask H about itself applied to its input,
thus H(P,P) MUST refer to P(P) or you haven't defined things correctly.

if H can't be asked about P(P), then H just fails to be the needed
decider, as H needs to be able to be asked about ANY machine with ANY
input. (Not just every machine that can be encoded to it, if some
machine can't be encoded, it just FAIL to be the requried computation).

[olcott]

*The simulated P never returns normally no matter what*
*The simulated P never returns normally no matter what*
*The simulated P never returns normally no matter what*

I am not going to go around and around with you on your strawman
deception, this may be the last time that I ever talk to you unless you
once-and-for-all utterly abandon every slight nuance of any attempt to
deceive.

*straw man*
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

My words have finally become clear enough that I maintained a dialogue
with a leading computer scientist for 23 emails over the weekend.

[Juha Nieminen]

olcott <No...@nowhere.com> wrote:
> On 7/11/2022 4:20 AM, Juha Nieminen wrote:
>> In comp.lang.c++ olcott <No...@nowhere.com> wrote:
>>> After very extensive discussions (23 emails) with a leading computer
>>> scientist I have a much simpler way to make my point.
>>
>> At least you seem to be willing to engage in *some* kind of conversation
>> with experts on the matter.
>>
>> I would still say that you could get much better feedback to your work
>> if you did all these posts in a forum dedicated to computer science and
>> mathematics with an active community of expects, rather than here in
>> some random usenet group (especially since usenet is almost dead, and
>> has been for over a decade).
>
> My proof is verified through software engineering and not verified
> through computer science. The people in the comp.theory forum don't seem
> to know jack shit about software engineering.
>
> Most crucially they don't understand that a function called in infinite
> recursion never returns to its caller.

It appears to me that you are just making up excuses to *not* go to the
actual experts on the subject matter, for your work to be actually
scrutinized and criticized and any possible flaws and errors pointed out.

Most people in comp.lang.c++ are C++ programmers, not mathematicians with
an expertise in computer science. You are not going to get any actual good
feedback and criticism here. But time and again you refuse to go to a forum
where you would.

I think that's because deep down you *know* that there's something wrong
with your work, and you just don't want it to be pointed out.

You claiming that your own proof is correct has about as much credibility
as you declaring yourself the winner of a debate.

[Juha Nieminen]

olcott <No...@nowhere.com> wrote:
> No. He is a world class computer scientist that I reached out to at
> random. He was unable to validate my work because he did not know the
> x86 language. He found no mistakes with my work.

"Found no mistakes" does not mean the same thing as "corroborated as being
valid". It could simply mean that he didn't bother. (Even if it meant that
he was unable doesn't mean that the proof is actually correct. It simply
means that this one person was unable to find the error.)

[Richard Damon]

WRONG. If H(P,P) returns 0, then P(P) will return normally.

If you saw the code:

void foo(void* bar) {
if(baz(bar, bar) {
while(1) continue;
}
return;
}

wouldn't you say that foo will return normally ANYTIME baz(bar,bar)
returns 0?

Isn't that what the code says?

The problem is you think that H is somehow able to be two different
programs at the same time.

That it can get stuck in the infinite recursion when P call it, but not
when main calls it, which only proves that your H, if it does actually
exists and does what you claim, isn't actually a pure function of its
inputs (or is just plain wrong).

>
> I am not going to go around and around with you on your strawman
> deception, this may be the last time that I ever talk to you unless you
> once-and-for-all utterly abandon every slight nuance of any attempt to
> deceive.

Why do you keep on insisting of making false statements

>
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man

Which is what YOU keep on settting up.

You make a strawman of having two different defintions of your H, or you
assume that H can do something you haven't actually proven it can do.

Please PRECISELY identify what "strawman" I have brought up.

H(P,P) MUST be deciding on the behavior of P(P) or P isn't the function
it is defined to be.

>
> My words have finally become clear enough that I maintained a dialogue
> with a leading computer scientist for 23 emails over the weekend.
>

No, you have just gotten better and being glib and making your lies
sound more possible.

You CLAIM H is correct, but only because you use a fault proof to show
it, claiming a rule that is incorrect.

It doesn't matter that there is no conditional in the C function P that
breaks the loop, since the H that P calls is part of the algorithm of P
and that H has the conditional that breaks the loop.

You rule in essence says that H is two different functions that don't
behave the same, which is an IMPOSSIBILITY for C or x86 code (that is a
pure function).

You make the H that P calls a pure emulator that won't stop, but the H
that main calls stops when it thinks that the behavior is non-halting,
using logic that shows that P will be non-halting if H doesn't abort its
simulation, but since H DOES abort its simulation, that proof isn't
satisfied, so is unsound.

The question isn't what does P do if H doesn't abort its simulation, it
is what does P do when H does what it does. If the H(P,P) returns 0,
then what H(P,P) does IS return 0, and there is no H that actually
emulates until it proves its input is actually non-halting.

[olcott]

On 7/12/2022 4:48 AM, Juha Nieminen wrote:
> olcott <No...@nowhere.com> wrote:
>> On 7/11/2022 4:20 AM, Juha Nieminen wrote:
>>> In comp.lang.c++ olcott <No...@nowhere.com> wrote:
>>>> After very extensive discussions (23 emails) with a leading computer
>>>> scientist I have a much simpler way to make my point.
>>>
>>> At least you seem to be willing to engage in *some* kind of conversation
>>> with experts on the matter.
>>>
>>> I would still say that you could get much better feedback to your work
>>> if you did all these posts in a forum dedicated to computer science and
>>> mathematics with an active community of expects, rather than here in
>>> some random usenet group (especially since usenet is almost dead, and
>>> has been for over a decade).
>>
>> My proof is verified through software engineering and not verified
>> through computer science. The people in the comp.theory forum don't seem
>> to know jack shit about software engineering.
>>
>> Most crucially they don't understand that a function called in infinite
>> recursion never returns to its caller.
>
> It appears to me that you are just making up excuses to *not* go to the
> actual experts on the subject matter, for your work to be actually
> scrutinized and criticized and any possible flaws and errors pointed out.
>

I had my work extensively reviewed (23 emails) by a leading computer
scientist over the weekend.

> Most people in comp.lang.c++ are C++ programmers, not mathematicians with
> an expertise in computer science. You are not going to get any actual good
> feedback and criticism here. But time and again you refuse to go to a forum
> where you would.
>

I already had all the computer science review that I need, Because H is
a pure function we know that H it implements a computable function.

> I think that's because deep down you *know* that there's something wrong
> with your work, and you just don't want it to be pointed out.
>

It took me nine months to transform H into a computable function.

> You claiming that your own proof is correct has about as much credibility
> as you declaring yourself the winner of a debate.

Any software engineer of ordinary skill can easily verify that the
simulated P would never terminate normally.

[olcott]

For his review my proof could not be fully understood without knowledge
of the x86 language. Back in the day 10% of all programmers knew the x86
language. It seems that there are none of these left so I transformed my
presentation so that a C programmer could validate it.

[David Brown]

There are a number of people in these groups who have expertise in the
relevant computer science and mathematics. All those that commented,
have discussed the flaws in Olcott's reasoning. People have given good
feedback and helpful criticism. All but a few have given up long ago in
the face of Olcott's insults, arrogance and pig-headedness. Richard
Damon is one of the few who keeps trying, with apparently infinite patience.

Some people get themselves stuck in a particular idea, and can't let go
- they have invested too much time, effort and pride to be able to
accept that they are wrong. There are those that are convinced they can
trisect an angle with ruler and compass, or prove that the cardinality
of the integers and reals is the same, or that the world is flat - or
that the halting problem is computable. It doesn't matter what you say
to Olcott, he will always believe he is right and that everyone else is
incompetent or ignorant. The alternative would be for him to accept
that he has wasted years - perhaps decades - with nothing to show but a
dozen lines of meaningless code. I think we just have to let him keep
his harmless fantasy.

[Mr Flibble]

On Mon, 11 Jul 2022 21:41:59 -0500

I have shown that a simulation-based decider needn't be recursive in
nature and indeed the Halting Problem proofs predicated on [Strachey
1965] mandate no recursion. You are simply barking up the wrong tree
and your decider is worthless and certainly doesn't refute any HP
proofs.

/Flibble

[olcott]

David Brown <david...@hesbynett.no> Wrote in message:r
> On 12/07/2022 11:48, Juha Nieminen wrote:> olcott <No...@nowhere.com> wrote:>> On 7/11/2022 4:20 AM, Juha Nieminen wrote:>>> In comp.lang.c++ olcott <No...@nowhere.com> wrote:>>>> After very extensive discussions (23 emails) with a leading computer>>>> scientist I have a much simpler way to make my point.>>>>>> At least you seem to be willing to engage in *some* kind of conversation>>> with experts on the matter.>>>>>> I would still say that you could get much better feedback to your work>>> if you did all these posts in a forum dedicated to computer science and>>> mathematics with an active community of expects, rather than here in>>> some random usenet group (especially since usenet is almost dead, and>>> has been for over a decade).>>>> My proof is verified through software engineering and not verified>> through computer science. The people in the comp.theory forum don't seem>> to know jack shit about software engineering.>>>> Most crucially they don't understand that a function called in infinite>> recursion never returns to its caller.> > It appears to me that you are just making up excuses to *not* go to the> actual experts on the subject matter, for your work to be actually> scrutinized and criticized and any possible flaws and errors pointed out.> > Most people in comp.lang.c++ are C++ programmers, not mathematicians with> an expertise in computer science. You are not going to get any actual good> feedback and criticism here. But time and again you refuse to go to a forum> where you would.> There are a number of people in these groups who have expertise in the relevant computer science and mathematics. All those that commented, have discussed the flaws in Olcott's reasoning. People have given good feedback and helpful criticism. All but a few have given up long ago in the face of Olcott's insults, arrogance and pig-headedness. Richard Damon is one of the few who keeps trying, with apparently infinite patience.Some people get themselves stuck in a particular idea, and can't let go - they have invested too much time, effort and pride to be able to accept that they are wrong. There are those that are convinced they can trisect an angle with ruler and compass, or prove that the cardinality of the integers and reals is the same, or that the world is flat - or that the halting problem is computable. It doesn't matter what you say to Olcott, he will always believe he is right and that everyone else is incompetent or ignorant. The alternative would be for him to accept that he has wasted years - perhaps decades - with nothing to show but a dozen lines of meaningless code. I think we just have to let him keep his harmless fantasy.> I think that's because deep down you *know* that there's something wrong> with your work, and you just don't want it to be pointed out.> > You claiming that your own proof is correct has about as much credibility> as you declaring yourself the winner of a debate.

Richard and Flibble do not understand that when a function is
called in what is essentially infinite recursion this function
never returns to it's caller.

Furthermore the calling function cannot possibly terminate normally.
--


----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

[Mr Flibble]

On Tue, 12 Jul 2022 12:30:59 -0500 (CDT)
olcott <polc...@gmail.com> wrote:

> David Brown <david...@hesbynett.no> Wrote in message:r
> > On 12/07/2022 11:48, Juha Nieminen wrote:> olcott
> > <No...@nowhere.com> wrote:>> On 7/11/2022 4:20 AM, Juha Nieminen
> > wrote:>>> In comp.lang.c++ olcott <No...@nowhere.com> wrote:>>>>
> > After very extensive discussions (23 emails) with a leading
> > computer>>>> scientist I have a much simpler way to make my

> > computer>>>> point.>>>>>> At least you seem to be willing to engage
> > computer>>>> in *some* kind of conversation>>> with experts on the
> > computer>>>> matter.>>>>>> I would still say that you could get
> > computer>>>> much better feedback to your work>>> if you did all
> > computer>>>> these posts in a forum dedicated to computer science
> > computer>>>> and>>> mathematics with an active community of
> > computer>>>> and>>> expects, rather than here in>>> some random
> > computer>>>> and>>> usenet group (especially since usenet is almost
> > computer>>>> and>>> dead, and>>> has been for over a decade).>>>>
> > computer>>>> and>>> My proof is verified through software
> > computer>>>> and>>> engineering and not verified>> through computer
> > computer>>>> and>>> science. The people in the comp.theory forum
> > computer>>>> and>>> don't seem>> to know jack shit about software
> > computer>>>> and>>> engineering.>>>> Most crucially they don't
> > computer>>>> and>>> understand that a function called in infinite>>
> > computer>>>> and>>> recursion never returns to its caller.> > It
> > computer>>>> and>>> appears to me that you are just making up
> > computer>>>> and>>> excuses to *not* go to the> actual experts on
> > computer>>>> and>>> the subject matter, for your work to be
> > computer>>>> and>>> actually> scrutinized and criticized and any
> > computer>>>> and>>> actually> possible flaws and errors pointed
> > computer>>>> and>>> actually> out.> > Most people in comp.lang.c++
> > computer>>>> and>>> actually> are C++ programmers, not
> > computer>>>> and>>> actually> mathematicians with> an expertise in
> > computer>>>> and>>> actually> computer science. You are not going
> > computer>>>> and>>> actually> to get any actual good> feedback and
> > computer>>>> and>>> actually> criticism here. But time and again
> > computer>>>> and>>> actually> you refuse to go to a forum> where
> > computer>>>> and>>> actually> you would.> There are a number of
> > computer>>>> and>>> actually> people in these groups who have
> > computer>>>> and>>> actually> expertise in the relevant computer
> > computer>>>> and>>> actually> science and mathematics. All those
> > computer>>>> and>>> actually> that commented, have discussed the
> > computer>>>> and>>> actually> flaws in Olcott's reasoning. People
> > computer>>>> and>>> actually> have given good feedback and helpful
> > computer>>>> and>>> actually> criticism. All but a few have given
> > computer>>>> and>>> actually> up long ago in the face of Olcott's
> > computer>>>> and>>> actually> insults, arrogance and
> > computer>>>> and>>> actually> pig-headedness. Richard Damon is one
> > computer>>>> and>>> actually> of the few who keeps trying, with
> > computer>>>> and>>> actually> apparently infinite patience.Some
> > computer>>>> and>>> actually> people get themselves stuck in a
> > computer>>>> and>>> actually> particular idea, and can't let go -
> > computer>>>> and>>> actually> they have invested too much time,
> > computer>>>> and>>> actually> effort and pride to be able to accept
> > computer>>>> and>>> actually> that they are wrong. There are those
> > computer>>>> and>>> actually> that are convinced they can trisect
> > computer>>>> and>>> actually> an angle with ruler and compass, or
> > computer>>>> and>>> actually> prove that the cardinality of the
> > computer>>>> and>>> actually> integers and reals is the same, or
> > computer>>>> and>>> actually> that the world is flat - or that the
> > computer>>>> and>>> actually> halting problem is computable. It
> > computer>>>> and>>> actually> doesn't matter what you say to
> > computer>>>> and>>> actually> Olcott, he will always believe he is
> > computer>>>> and>>> actually> right and that everyone else is
> > computer>>>> and>>> actually> incompetent or ignorant. The
> > computer>>>> and>>> actually> alternative would be for him to
> > computer>>>> and>>> actually> accept that he has wasted years -
> > computer>>>> and>>> actually> perhaps decades - with nothing to
> > computer>>>> and>>> actually> show but a dozen lines of meaningless
> > computer>>>> and>>> actually> code. I think we just have to let
> > computer>>>> and>>> actually> him keep his harmless fantasy.> I
> > computer>>>> and>>> actually> think that's because deep down you
> > computer>>>> and>>> actually> *know* that there's something wrong>
> > computer>>>> and>>> actually> with your work, and you just don't
> > computer>>>> and>>> actually> want it to be pointed out.> > You
> > computer>>>> and>>> actually> claiming that your own proof is
> > computer>>>> and>>> actually> correct has about as much
> > computer>>>> and>>> actually> credibility> as you declaring
> > computer>>>> and>>> actually> credibility> yourself the winner of a
> > computer>>>> and>>> actually> credibility> debate.

>
> Richard and Flibble do not understand that when a function is
> called in what is essentially infinite recursion this function
> never returns to it's caller.
>
> Furthermore the calling function cannot possibly terminate normally.

[Strachey 1965] doesn't have any infinite recursion. The HP proofs do
not have any infinite recursion. I have shown it is possible to create
simulation-based halting decider without any infinite recursion. The
only thing that has infinite recursion is your broken solution.

/Flibble

[olcott]

Mr Flibble <fli...@reddwarf.jmc.corp> Wrote in message:r
> On Mon, 11 Jul 2022 21:41:59 -0500olcott <No...@NoWhere.com> wrote:> On 7/11/2022 9:06 PM, Richard Damon wrote:> > On 7/11/22 7:30 PM, olcott wrote: > >> On 7/11/2022 6:23 PM, Richard Damon wrote: > >>> On 7/11/22 2:43 PM, olcott wrote: > >>>> On 7/11/2022 11:09 AM, Mut...@dastardlyhq.com wrote: > >>>>> On Mon, 11 Jul 2022 08:24:38 -0500> >>>>> olcott <No...@NoWhere.com> wrote: > >>>>>> On 7/11/2022 4:41 AM, Mut...@dastardlyhq.com wrote: > >>>>>>> On Mon, 11 Jul 2022 09:20:09 -0000 (UTC)> >>>>>>> Juha Nieminen <nos...@thanks.invalid> wrote: > >>>>>>>> In comp.lang.c++ olcott <No...@nowhere.com> wrote: > >>>>>>>>> After very extensive discussions (23 emails) with a leading > >>>>>>>>> computer> >>>>>>>>> scientist I have a much simpler way to make my point. > >>>>>>>>> >>>>>>>> At least you seem to be willing to engage in *some* kind of > >>>>>>>> conversation> >>>>>>>> with experts on the matter. > >>>>>>>> >>>>>>> Its probably a friend of his. > >>>>>>> >>>>>> No. He is a world class computer scientist that I reached out> >>>>>> to at random. He was unable to validate my work because he did> >>>>>> not know the x86 language. He found no mistakes with my work. > >>>>>> >>>>> If he didn't validate it then he wouldn't find any mistakes> >>>>> would he. I imagine> >>>>> he had more important things to do than get into a discussion> >>>>> with a crank.> >>>>> Probably some urgent coffee to make or paper to shuffle.> >>>>> > >>>>> >>>> On the basis of his feedback I rewrote the first page so that it> >>>> can be understood to be correct with only ordinary understanding> >>>> of the C programming language and software engineering.> >>>>> >>>> The first page of this updated paper makes my point much more > >>>> clearly in that it requires no knowledge of the x86 assembly > >>>> language. The subsequent pages can be skipped.> >>>>> >>>> Simulating halt decider H(P,P) detects that its simulated P is > >>>> essentially calling it in infinite recursion, H aborts its > >>>> simulation of this input then rejects it as non-halting.> >>>>> >>>> typedef void (*ptr)();> >>>> int H(ptr p, ptr i);> >>>>> >>>> void P(ptr x)> >>>> {> >>>> if (H(x, x))> >>>> HERE: goto HERE;> >>>> return;> >>>> }> >>>> int main()> >>>> {> >>>> Output("Input_Halts = ", H(P, 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 > >>>>> >>>>> >>>>> >>>> > >>>> >>> Except that P only calls H in infinite recursion if H doesn't> >>> know enough to stop the recursion, at which point it can't answer > >>> non-halting. > >>> >> I was able to simplify my presentation so that everyone here can > >> easily verify that I have correctly refuted the halting theorem on > >> this pure software engineering basis:> >>> >> understanding that the simulated P essentially calls simulating> >> halt decider H in infinite recursion such that the simulated P> >> cannot possibly terminate normally.> >>> >> *if you are saying that the simulated P can possibly*> >> *terminate normally then your software engineering*> >> *skills are woefully inadequate*> >> > > > > P terminates normally if, and only if, H(P,P) returns 0. > > *The simulated P never returns normally no matter what*> *The simulated P never returns normally no matter what*> *The simulated P never returns normally no matter what*I have shown that a simulation-based decider needn't be recursive innature and indeed the Halting Problem proofs predicated on [Strachey1965] mandate no recursion. You are simply barking up the wrong treeand your decider is worthless and certainly doesn't refute any HPproofs./Flibble

You continue to fail to understand that every halting problem
pathological input to H never terminates normally.

[Richard Damon]

Unless the H that is calls aborts its simulation and answers
non-halting, in which case it does.

And if it doesn't, then the H fails to answer and be a Halt Decider.

You seem to not understand that fundamental nature of programs, that
they actually do what they are programmed to do, but not necessarily
what you want them to do.

You H, since it decides that this input doesn't halt, doesn't correctly
emulate it, and thus gets the wrong answer.

You can't assume that it acts correctly until AFTER you have proved that
it does.

If H(P,P) returns 0, then we know that P(P) Halts (and thus H is wrong),
and for the other problem, if H(D,D) returns 0 because it thinks D(D)
won't answer, D(D) WILL answer and return 1, making H wrong.

[Richard Damon]

So that fact that it doesn't get the right answer says that Halting
Might not be computable.

>
>> I think that's because deep down you *know* that there's something wrong
>> with your work, and you just don't want it to be pointed out.
>>
>
> It took me nine months to transform H into a computable function.

Nope, H isn't a computatable function, it IMPLEMENTS a computable
function, but not the function that the Halting Problem defines, since
we KNOW that P(P) will Halt if H(P,P) returns 0 (saying non-halting), so
if H(P,P) returns 0 the Halting function of P(P) is Halting, and thus H
is not implementing the Halting function since they map the same input
to different answers.

>
>> You claiming that your own proof is correct has about as much credibility
>> as you declaring yourself the winner of a debate.
>
> Any software engineer of ordinary skill can easily verify that the
> simulated P would never terminate normally.
>

No, the can verify that the CORRECTLY simulated P will terminate
normally if H(P,P) returns 0.

Yes, they can verify that *H* can't ever reach that point, but that
means that H either needs to simulate its input FOREVER (and thus fail
to be a decider), or make an error and terminate and give the wrong answer.

[Richard Damon]

Except that it is only ACTUALLY infinite recursion if H never aborts, at
which point H(P,P) never answers and H fails to be a decider.

You can have H(P,P) be BOTH a function that returns the non-halting
answer in finte time to be a decider, and ALSO emulate its input forever
to make that answer correct.

That is just calling the black cat white.

You seem to be unable to understand this FUNDAMENTAL fact of programs,
that pure programs, like what a Halt Decider needs to be, will ALWAYS
give the same results for the same input.

Thus, you H is either:

1) Just wrong
2) Using an Incorrect emulation, or
3) Not actually a pure program, and behaves differently in different
conditions for the same input.

If you want to say the 3 is correct behavior, then please show the first
instructions ACTUALLY Executed / Simulated in the two cases that give
different results. Since the inputs were supposed to be the same, the
inputs to that instruction should be the same.

From your description, it sounds like the divergance occurs at the call
to H, where when actually EXECUTED it processes, decided the input is
non-halting, aborts it simulation and returns 0, but when simulated, it
is just (incorrectly) presumed to show infinite recursion. This shows
that H doesn't correctly simulate its input.

[olcott]

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

It is not verified until it is understood that P and H implement the
classical halting problem "impossible input" template (as shown above)
and refutes this template in that H(P,P) correctly determines that its
input never terminates normally.

*This is the key software engineering that I need validated*
Most anyone here can easily verify that the simulated input to H(P,P)
cannot possibly terminate normally.

The next level of pure software engineering is that H(P,P) correctly
predicts that its simulated input cannot possibly terminate normally. It
may be the case that only the top 5% of software engineers can validate
this point.

typedef void (*ptr)();
int H(ptr p, ptr i);

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

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

Simulating halt decider H detects that its simulated input is
essentially calling H in infinite recursion. H aborts its simulation on
this basis and rejects this input as non-halting.

The execution trace of function P() simulated by function H() shows:
(1) Function H() is called from P().
(2) With the same parameters to H().
(3) With no instructions in P() that could possibly escape this
infinitely recursive simulation.

*That was all of the software engineering that I need validated*

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