0 views

Skip to first unread message

Jun 17, 2022, 3:39:57 PM6/17/22

to

comp.theory:

[Solution to one instance of the Halting Problem]

On 3/14/2017 9:05 AM, peteolcott wrote:

Essence of the culmination five years of full time work on the Halting

Problem when I first discovered (see above) that a simulating halt

decider could correctly determine the halt status of the "impossible"

input:

When a simulating halt decider rejects all inputs as non-halting

whenever it correctly detects that its correct and complete simulation

of its input would never reach the final state of this input that all

[these] inputs (including pathological inputs) are decided correctly.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--

Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;

Genius hits a target no one else can see."

Arthur Schopenhauer

[Solution to one instance of the Halting Problem]

On 3/14/2017 9:05 AM, peteolcott wrote:

Essence of the culmination five years of full time work on the Halting

Problem when I first discovered (see above) that a simulating halt

decider could correctly determine the halt status of the "impossible"

input:

When a simulating halt decider rejects all inputs as non-halting

whenever it correctly detects that its correct and complete simulation

of its input would never reach the final state of this input that all

[these] inputs (including pathological inputs) are decided correctly.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--

Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;

Genius hits a target no one else can see."

Arthur Schopenhauer

Jun 17, 2022, 3:41:12 PM6/17/22

to

On Fri, 17 Jun 2022 14:39:49 -0500

olcott <No...@NoWhere.com> wrote:

> comp.theory:

> [Solution to one instance of the Halting Problem]

> On 3/14/2017 9:05 AM, peteolcott wrote:

>

> Essence of the culmination five years of full time work on the

> Halting Problem when I first discovered (see above) that a simulating

> halt decider could correctly determine the halt status of the

> "impossible" input:

>

> When a simulating halt decider rejects all inputs as non-halting

> whenever it correctly detects that its correct and complete

> simulation of its input would never reach the final state of this

> input that all [these] inputs (including pathological inputs) are

> decided correctly.

void Px(u32 x)
olcott <No...@NoWhere.com> wrote:

> comp.theory:

> [Solution to one instance of the Halting Problem]

> On 3/14/2017 9:05 AM, peteolcott wrote:

>

> Essence of the culmination five years of full time work on the

> Halting Problem when I first discovered (see above) that a simulating

> halt decider could correctly determine the halt status of the

> "impossible" input:

>

> When a simulating halt decider rejects all inputs as non-halting

> whenever it correctly detects that its correct and complete

> simulation of its input would never reach the final state of this

> input that all [these] inputs (including pathological inputs) are

> decided correctly.

{

H(x, x);

return;

}

int main()

{

Output("Input_Halts = ", H((u32)Px, (u32)Px));

}

...[000013e8][00102357][00000000] 83c408 add esp,+08

...[000013eb][00102353][00000000] 50 push eax

...[000013ec][0010234f][00000427] 6827040000 push 00000427

---[000013f1][0010234f][00000427] e880f0ffff call 00000476

Input_Halts = 0

...[000013f6][00102357][00000000] 83c408 add esp,+08

...[000013f9][00102357][00000000] 33c0 xor eax,eax

...[000013fb][0010235b][00100000] 5d pop ebp

...[000013fc][0010235f][00000004] c3 ret

Number of Instructions Executed(16120)

It gets the answer wrong, i.e. input has not been decided correctly.

QED.

/Flibble

Jun 17, 2022, 8:50:44 PM6/17/22

to

On 6/17/22 3:39 PM, olcott wrote:

> comp.theory:

> [Solution to one instance of the Halting Problem]

> On 3/14/2017 9:05 AM, peteolcott wrote:

>

> Essence of the culmination five years of full time work on the Halting

> Problem when I first discovered (see above) that a simulating halt

> decider could correctly determine the halt status of the "impossible"

> input:

>

> When a simulating halt decider rejects all inputs as non-halting

> whenever it correctly detects that its correct and complete simulation

> of its input would never reach the final state of this input that all

> [these] inputs (including pathological inputs) are decided correctly.

>

>

>

>

>

> Halting problem undecidability and infinitely nested simulation (V5)

>

> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

>

>

So, which H are you claiming is correct? You are describing two
> comp.theory:

> [Solution to one instance of the Halting Problem]

> On 3/14/2017 9:05 AM, peteolcott wrote:

>

> Essence of the culmination five years of full time work on the Halting

> Problem when I first discovered (see above) that a simulating halt

> decider could correctly determine the halt status of the "impossible"

> input:

>

> When a simulating halt decider rejects all inputs as non-halting

> whenever it correctly detects that its correct and complete simulation

> of its input would never reach the final state of this input that all

> [these] inputs (including pathological inputs) are decided correctly.

>

>

>

>

>

> Halting problem undecidability and infinitely nested simulation (V5)

>

> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

>

>

different machines.

Is H the one that correctly emulates its input, and thus runs forever

emulation the input of H(P,P) for the P built on this H, and thus fails

to answer, or

Is H the one that does abort its emulation (and thus NOT do a corret

emulation) and return 0, and when we look at an ACTUAL correct emulation

that will behave just like P(P), for the P built on THAT H, we see that

P(P) does return, and thus H(P,P) returning 0 is incorrect.

If you want to claim that the behavior are different, what is the first

instruction accurately emulated from the input of H(P,P) that differs in

results from the direct execution of P(P).

Until you provide that evidence, your "impossible" claim needs to just

be considered a lie.

Jun 20, 2022, 2:42:04 PM6/20/22

to

On 6/20/2022 9:27 AM, Paul N wrote:

Ideally I want to get published in JACM the same way that Edsger

Dijkstra was published.

https://dl.acm.org/doi/10.1145/362929.362947

Letters to the editor: go to statement considered harmful

Author: Edsger W. Dijkstra

Communications of the ACM Volume 11 Issue 3 March 1968 pp 147–148

https://doi.org/10.1145/362929.362947

> On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:

>> comp.theory:

>> [Solution to one instance of the Halting Problem]

>> On 3/14/2017 9:05 AM, peteolcott wrote:

>>

>> Essence of the culmination five years of full time work on the Halting

>> Problem when I first discovered (see above) that a simulating halt

>> decider could correctly determine the halt status of the "impossible"

>> input:

>

> Stepping back a bit from the detail of this, may I ask where you intend going with this? Suppose for example that you posted something that did make Flibble, Richard and the others realise that they were mistaken and admit it. Would you regard the admiration of half a dozen people, one calling himself "Mr Flibble", as a worthwhile reward for five years of full-time work? Or do you intend going further, eg getting the results published elsewhere?
>> comp.theory:

>> [Solution to one instance of the Halting Problem]

>> On 3/14/2017 9:05 AM, peteolcott wrote:

>>

>> Essence of the culmination five years of full time work on the Halting

>> Problem when I first discovered (see above) that a simulating halt

>> decider could correctly determine the halt status of the "impossible"

>> input:

>

Ideally I want to get published in JACM the same way that Edsger

Dijkstra was published.

https://dl.acm.org/doi/10.1145/362929.362947

Letters to the editor: go to statement considered harmful

Author: Edsger W. Dijkstra

Communications of the ACM Volume 11 Issue 3 March 1968 pp 147–148

https://doi.org/10.1145/362929.362947

Jun 20, 2022, 2:52:27 PM6/20/22

to

On 6/20/2022 1:38 PM, Ben Bacarisse wrote:

>

> BTW, if it was you that gave him the "review" he wanted in

> comp.lang.c++, you were lead stray by his trace. It does not show

> what he claims it shows.

>

> He's now being very clear about the trick he's trying to pull. There's

> nothing "in P" that can stop the apparent infinite recursion, but that's

> just sophistry. H is as much part of the computation as any other and H

> should, stop the recursion when it returns 0 to P. But he gets around

> that by "aborting" (by which I think he means a non-local transfer of

> control) so execution never reaches P's ret instruction. His claim that

> H is a pure function is just bogus.

>

#include <stdint.h>

typedef void (*ptr)();

void P(ptr x)

{

if (H(x, x))

HERE: goto HERE;

return;

}

int main()

{

Output("Input_Halts = ", H(P, P));

}

_P()

[00001352](01) 55 push ebp

[00001353](02) 8bec mov ebp,esp

[00001355](03) 8b4508 mov eax,[ebp+08]

[00001358](01) 50 push eax // push P

[00001359](03) 8b4d08 mov ecx,[ebp+08]

[0000135c](01) 51 push ecx // push P

[0000135d](05) e840feffff call 000011a2 // call H

[00001362](03) 83c408 add esp,+08

[00001365](02) 85c0 test eax,eax

[00001367](02) 7402 jz 0000136b

[00001369](02) ebfe jmp 00001369

[0000136b](01) 5d pop ebp

[0000136c](01) c3 ret

Size in bytes:(0027) [0000136c]

Every sufficiently competent software engineer can easily verify that

the complete and correct x86 emulation of the input to H(P,P) by H would

never reach the "ret" instruction of P.

>> Or do you intend going further, eg

>> getting the results published elsewhere?

>

> If he ever does publish, it will be in one of those predatory journals

> that change fees.

>>> comp.theory:

>>> [Solution to one instance of the Halting Problem]

>>> On 3/14/2017 9:05 AM, peteolcott wrote:

>>>

>>> Essence of the culmination five years of full time work on the Halting

>>> Problem when I first discovered (see above) that a simulating halt

>>> decider could correctly determine the halt status of the "impossible"

>>> input:

>>

>>> [Solution to one instance of the Halting Problem]

>>> On 3/14/2017 9:05 AM, peteolcott wrote:

>>>

>>> Essence of the culmination five years of full time work on the Halting

>>> Problem when I first discovered (see above) that a simulating halt

>>> decider could correctly determine the halt status of the "impossible"

>>> input:

>>

>> Stepping back a bit from the detail of this, may I ask where you

>> intend going with this? Suppose for example that you posted something

>> that did make Flibble, Richard and the others realise that they were

>> mistaken and admit it. Would you regard the admiration of half a dozen

>> people, one calling himself "Mr Flibble", as a worthwhile reward for

>> five years of full-time work?

>

> Five? He first "solved" the halting problem 18 years ago!
>> intend going with this? Suppose for example that you posted something

>> that did make Flibble, Richard and the others realise that they were

>> mistaken and admit it. Would you regard the admiration of half a dozen

>> people, one calling himself "Mr Flibble", as a worthwhile reward for

>> five years of full-time work?

>

>

> BTW, if it was you that gave him the "review" he wanted in

> comp.lang.c++, you were lead stray by his trace. It does not show

> what he claims it shows.

>

> He's now being very clear about the trick he's trying to pull. There's

> nothing "in P" that can stop the apparent infinite recursion, but that's

> just sophistry. H is as much part of the computation as any other and H

> should, stop the recursion when it returns 0 to P. But he gets around

> that by "aborting" (by which I think he means a non-local transfer of

> control) so execution never reaches P's ret instruction. His claim that

> H is a pure function is just bogus.

>

#include <stdint.h>

typedef void (*ptr)();

void P(ptr x)

{

if (H(x, x))

HERE: goto HERE;

return;

}

int main()

{

Output("Input_Halts = ", H(P, P));

}

_P()

[00001352](01) 55 push ebp

[00001353](02) 8bec mov ebp,esp

[00001355](03) 8b4508 mov eax,[ebp+08]

[00001358](01) 50 push eax // push P

[00001359](03) 8b4d08 mov ecx,[ebp+08]

[0000135c](01) 51 push ecx // push P

[0000135d](05) e840feffff call 000011a2 // call H

[00001362](03) 83c408 add esp,+08

[00001365](02) 85c0 test eax,eax

[00001367](02) 7402 jz 0000136b

[00001369](02) ebfe jmp 00001369

[0000136b](01) 5d pop ebp

[0000136c](01) c3 ret

Size in bytes:(0027) [0000136c]

Every sufficiently competent software engineer can easily verify that

the complete and correct x86 emulation of the input to H(P,P) by H would

never reach the "ret" instruction of P.

>> Or do you intend going further, eg

>> getting the results published elsewhere?

>

> that change fees.

Jun 20, 2022, 3:02:10 PM6/20/22

to

void Px(u32 x)

{

H(x, x);

return;
{

H(x, x);

}

int main()

{

Jun 20, 2022, 6:49:38 PM6/20/22

to

correct x86 emulation of the input, this is a contradiction of terms.

BY DEFINITION, a "complete" x86 emulation doesn't stop until it reches

ah Halting state, this if the input is non-halting, the complete

emulation doesn't stop, so H can not as the same algorithm do both a

complete x86 emulation and return the value 0.

You are just showing your ignorance of what you are talking about.

Jun 21, 2022, 9:55:05 PM6/21/22

to

On 6/20/2022 1:38 PM, Ben Bacarisse wrote:

> Paul N <gw7...@aol.com> writes:

>

>> On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:

> Paul N <gw7...@aol.com> writes:

>

>> On Friday, June 17, 2022 at 8:39:57 PM UTC+1, olcott wrote:

>>> comp.theory:

>>> [Solution to one instance of the Halting Problem]

>>> On 3/14/2017 9:05 AM, peteolcott wrote:

>>>

>>> Essence of the culmination five years of full time work on the Halting

>>> Problem when I first discovered (see above) that a simulating halt

>>> decider could correctly determine the halt status of the "impossible"

>>> input:

>>

>>> [Solution to one instance of the Halting Problem]

>>> On 3/14/2017 9:05 AM, peteolcott wrote:

>>>

>>> Essence of the culmination five years of full time work on the Halting

>>> Problem when I first discovered (see above) that a simulating halt

>>> decider could correctly determine the halt status of the "impossible"

>>> input:

>>

>> Stepping back a bit from the detail of this, may I ask where you

>> intend going with this? Suppose for example that you posted something

>> that did make Flibble, Richard and the others realise that they were

>> mistaken and admit it. Would you regard the admiration of half a dozen

>> people, one calling himself "Mr Flibble", as a worthwhile reward for

>> five years of full-time work?

>

> Five? He first "solved" the halting problem 18 years ago!

>

> BTW, if it was you that gave him the "review" he wanted in

> comp.lang.c++, you were lead stray by his trace. It does not show

> what he claims it shows.

>

> He's now being very clear about the trick he's trying to pull. There's

> nothing "in P" that can stop the apparent infinite recursion, but that's

> just sophistry. H is as much part of the computation as any other and H

> should, stop the recursion when it returns 0 to P. But he gets around

> that by "aborting" (by which I think he means a non-local transfer of

> control) so execution never reaches P's ret instruction. His claim that

> H is a pure function is just bogus.

>

>> intend going with this? Suppose for example that you posted something

>> that did make Flibble, Richard and the others realise that they were

>> mistaken and admit it. Would you regard the admiration of half a dozen

>> people, one calling himself "Mr Flibble", as a worthwhile reward for

>> five years of full-time work?

>

> Five? He first "solved" the halting problem 18 years ago!

>

> BTW, if it was you that gave him the "review" he wanted in

> comp.lang.c++, you were lead stray by his trace. It does not show

> what he claims it shows.

>

> He's now being very clear about the trick he's trying to pull. There's

> nothing "in P" that can stop the apparent infinite recursion, but that's

> just sophistry. H is as much part of the computation as any other and H

> should, stop the recursion when it returns 0 to P. But he gets around

> that by "aborting" (by which I think he means a non-local transfer of

> control) so execution never reaches P's ret instruction. His claim that

> H is a pure function is just bogus.

>

Every sufficiently competent software engineer can easily verify that

the complete and correct x86 emulation of the input to H(P,P) by H would

never reach the "ret" instruction of P because both H and P would remain
the complete and correct x86 emulation of the input to H(P,P) by H would

stuck in infinitely recursive emulation.

If H can determine that this is the case in a finite number of steps

then H could reject its input on this basis.

If you can't form a correct rebuttal in terms of the actual software

engineering of the *exact words specified above* then that would prove

that you are insufficiently technically competent on this point.

If you incorrectly paraphrase what I said and form a rebuttal to this

incorrect paraphrase then sufficiently technically competent software

engineers would know that you are trying to get away with the strawman

deception.

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

>> Or do you intend going further, eg

>> getting the results published elsewhere?

>

> If he ever does publish, it will be in one of those predatory journals

> that change fees.

>

Jun 21, 2022, 10:35:34 PM6/21/22

to

actually DOES a complete and correct emulation of its input, it can't

stop that emulation to answer 0, now can it?

>

> If H can determine that this is the case in a finite number of steps

> then H could reject its input on this basis.

impossibe for H in emulating the input to H(P,P) for the P built on that H.

You CLAIM a lot, but seem to be weak on proof.

>

> If you can't form a correct rebuttal in terms of the actual software

> engineering of the *exact words specified above* then that would prove

> that you are insufficiently technically competent on this point.

>

your end.

> If you incorrectly paraphrase what I said and form a rebuttal to this

> incorrect paraphrase then sufficiently technically competent software

> engineers would know that you are trying to get away with the strawman

> deception.

comment on them.

Your H that both does a complete and correct emulation and also aborts

its emulation because it "proved" somethint that isn't true is an

impossibility on several levels.

>

> 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

>

>

than just repeat your disproved statements.

The Journal editors won't take that sort of answer, if they even think

it is worth asking for the clariifcation before trashing your "paper".

Jun 21, 2022, 10:50:10 PM6/21/22

to

>>

>> If H can determine that this is the case in a finite number of steps

>> then H could reject its input on this basis.

>

> Thats your claim, but not proven. In fact, it has been proven to be

> impossibe for H in emulating the input to H(P,P) for the P built on that H.

>

> You CLAIM a lot, but seem to be weak on proof.

sufficiently competent software engineers.

A software engineer must be an expert in: the C programming language,

the x86 programming language, exactly how C translates into x86 and the

ability to recognize infinite recursion at the x86 assembly language

level. No knowledge of the halting problem is required.

All of the recent rebuttals try to bluff their way past this requirement

to hide the fact that they lack this sufficient technical competence.

Sufficiently competent software engineers will agree.

On 6/21/2022 9:38 PM, olcott wrote: [Technically competent Software

engineers can verify this halting problem proof refutation]

Jun 21, 2022, 11:20:35 PM6/21/22

to

statement is more impossible than the liar's paradox.

You CLAIM that H does BOTH a complete and correct emulation of its input

and also aborts its input to return its rejects.

That is just like saying your "CAT" barks, because what you call your

cat is actualy a dog.

H can NOT do the infinte job of being a complete and correct emulator

and also return an answer in finite time.

Until you explain how you figure you do that, you are just revealing

that you are totally ignorant of the basics of the field.

>

> A software engineer must be an expert in: the C programming language,

> the x86 programming language, exactly how C translates into x86 and the

> ability to recognize infinite recursion at the x86 assembly language

> level. No knowledge of the halting problem is required.

problem.

I will note, one of your problems seems to be you don't understand the

difference between a C function and a C program, and that a C funciton,

under some interpretations, isn't the same as a function in computation

theory, as in computation theory, a function includes every thing it uses.

>

> All of the recent rebuttals try to bluff their way past this requirement

> to hide the fact that they lack this sufficient technical competence.

> Sufficiently competent software engineers will agree.

>

> On 6/21/2022 9:38 PM, olcott wrote: [Technically competent Software

> engineers can verify this halting problem proof refutation]

>

>

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu