1 view

Skip to first unread message

Jul 2, 2022, 11:34:42 AMJul 2

to

This much more concise version of my paper focuses on the actual

execution of three fully operational examples.

H0 correctly determines that Infinite_Loop() never halts

H correctly determines that Infinite_Recursion() never halts

H correctly determines that P() never halts

void P(u32 x)

{

if (H(x, x))

HERE: goto HERE;

return;

}

int main()

{

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

}

As shown below the above P and H have the required (halting problem)

pathological relationship to each other:

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

I really need software engineers to verify that H does correctly predict

that its complete and correct x86 emulation of its input would never

reach the "ret" instruction of this input.

*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

execution of three fully operational examples.

H0 correctly determines that Infinite_Loop() never halts

H correctly determines that Infinite_Recursion() never halts

H correctly determines that P() never halts

void P(u32 x)

{

if (H(x, x))

HERE: goto HERE;

return;

}

int main()

{

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

}

As shown below the above P and H have the required (halting problem)

pathological relationship to each other:

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

I really need software engineers to verify that H does correctly predict

that its complete and correct x86 emulation of its input would never

reach the "ret" instruction of this input.

*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

Jul 2, 2022, 12:26:40 PMJul 2

to

{

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)

As can be seen above Olcott's H decides that Px does not halt but it is

obvious that Px should always halt if H is a valid halt decider that

always returns a decision to its caller (Px). Olcott's H does not

return a decision to its caller (Px) and is thus invalid.

/Flibble

Jul 2, 2022, 12:42:56 PMJul 2

to

x86 programming language.

*x86 Instruction Set Reference* https://c9x.me/x86/

void Px(u32 x)

{

H(x, x);

return;

}

int main()

{

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

}

[00001192](01) 55 push ebp

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

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

[00001198](01) 50 push eax

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

[0000119c](01) 51 push ecx

[0000119d](05) e8d0fdffff call 00000f72

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

[000011a5](01) 5d pop ebp

[000011a6](01) c3 ret

Size in bytes:(0021) [000011a6]

_main()

[000011d2](01) 55 push ebp

[000011d3](02) 8bec mov ebp,esp

[000011d5](05) 6892110000 push 00001192

[000011da](05) 6892110000 push 00001192

[000011df](05) e88efdffff call 00000f72

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

[000011e7](01) 50 push eax

[000011e8](05) 68a3040000 push 000004a3

[000011ed](05) e800f3ffff call 000004f2

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

[000011f5](02) 33c0 xor eax,eax

[000011f7](01) 5d pop ebp

[000011f8](01) c3 ret

Size in bytes:(0039) [000011f8]

machine stack stack machine assembly

address address data code language

======== ======== ======== ========= =============

[000011d2][00101f7f][00000000] 55 push ebp

[000011d3][00101f7f][00000000] 8bec mov ebp,esp

[000011d5][00101f7b][00001192] 6892110000 push 00001192

[000011da][00101f77][00001192] 6892110000 push 00001192

[000011df][00101f73][000011e4] e88efdffff call 00000f72

H: Begin Simulation Execution Trace Stored at:11202b

Address_of_H:f72

[00001192][00112017][0011201b] 55 push ebp

[00001193][00112017][0011201b] 8bec mov ebp,esp

[00001195][00112017][0011201b] 8b4508 mov eax,[ebp+08]

[00001198][00112013][00001192] 50 push eax // push Px

[00001199][00112013][00001192] 8b4d08 mov ecx,[ebp+08]

[0000119c][0011200f][00001192] 51 push ecx // push Px

[0000119d][0011200b][000011a2] e8d0fdffff call 00000f72 // call H(Px,Px)

H: Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily

examine its stored execution_trace of Px (see above) to determine:

(a) Px is calling H with the same arguments that H was called with.

(b) No instructions in Px could possibly escape this otherwise

infinitely recursive emulation.

(c) H aborts its emulation of Px before its call to H is emulated.

[000011e4][00101f7f][00000000] 83c408 add esp,+08

[000011e7][00101f7b][00000000] 50 push eax

[000011e8][00101f77][000004a3] 68a3040000 push 000004a3

[000011ed][00101f77][000004a3] e800f3ffff call 000004f2

Input_Halts = 0

[000011f2][00101f7f][00000000] 83c408 add esp,+08

[000011f5][00101f7f][00000000] 33c0 xor eax,eax

[000011f7][00101f83][00000018] 5d pop ebp

[000011f8][00101f87][00000000] c3 ret

Number of Instructions Executed(880) == 13 Pages

Jul 2, 2022, 1:16:06 PMJul 2

to

On 7/2/2022 12:10 PM, Mr Flibble wrote:

> If H wasn't a simulation-based halting decider then Px() would always

> halt; the infinite recursion is a manifestation of your invalid

> simulation-based halting decider. There is no recursion in [Strachey

> 1965].

>

> /Flibble

In other words you are rejecting the concept of a simulating halt

decider even though I conclusively proved that it does correctly

determine the halt status of: (see my new paper)

H0 correctly determines that Infinite_Loop() never halts

H correctly determines that Infinite_Recursion() never halts

H correctly determines that P() never halts

*This is necessarily true thus impossibly false*

Every simulating halt decider that correctly simulates its input until

it correctly determines that this simulated input would never reach its

final state, correctly rejects this input as non-halting.

*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

--

> halt; the infinite recursion is a manifestation of your invalid

> simulation-based halting decider. There is no recursion in [Strachey

> 1965].

>

> /Flibble

In other words you are rejecting the concept of a simulating halt

decider even though I conclusively proved that it does correctly

determine the halt status of: (see my new paper)

H0 correctly determines that Infinite_Loop() never halts

H correctly determines that Infinite_Recursion() never halts

H correctly determines that P() never halts

Every simulating halt decider that correctly simulates its input until

it correctly determines that this simulated input would never reach its

final state, correctly rejects this input as non-halting.

*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

Jul 2, 2022, 1:26:50 PMJul 2

to

On Sat, 2 Jul 2022 12:15:58 -0500

No I am rejecting your simulating halt decider as it gets the answer

wrong for Px() which is not a pathological input. Px() halts.

/Flibble

wrong for Px() which is not a pathological input. Px() halts.

/Flibble

Jul 2, 2022, 1:30:11 PMJul 2

to

correct x86 emulation of its input would never reach the "ret"

instruction of this input because of the pathological relationship
between H and Px.

Jul 2, 2022, 2:28:45 PMJul 2

to

On Sat, 2 Jul 2022 12:30:03 -0500

Wrong. Px() is not a pathological input as defined by the halting

problem and [Strachey 1965] as it does not try to do the opposite of

what H decides.

/Flibble

problem and [Strachey 1965] as it does not try to do the opposite of

what H decides.

/Flibble

Jul 2, 2022, 2:41:22 PMJul 2

to

void P(u32 x)

{

if (H(x, x))

HERE: goto HERE;

return;

}

int main()

{

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

}

As shown below the above P and H have the required (halting problem)

pathological relationship to each other:

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

Jul 2, 2022, 2:44:46 PMJul 2

to

On Sat, 2 Jul 2022 13:41:14 -0500

[snip]

P does but Px does not. I am talking about Px not P.

P does but Px does not. I am talking about Px not P.

Jul 2, 2022, 5:26:53 PMJul 2

to

Jul 2, 2022, 6:05:34 PMJul 2

to

On Sat, 2 Jul 2022 16:26:45 -0500

I see you wish to pointlessly go around in circles. Oh well.

Px() is not a pathological input as defined by the halting

problem and [Strachey 1965] as it does not try to do the opposite of

what H decides.

Px() always halts so your H gets the answer wrong.

/Flibble

Px() is not a pathological input as defined by the halting

problem and [Strachey 1965] as it does not try to do the opposite of

what H decides.

/Flibble

Jul 2, 2022, 6:13:08 PMJul 2

to

again.

*This general principle refutes conventional halting problem proofs*

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.

Jul 3, 2022, 10:27:47 AMJul 3

to

On Sat, 2 Jul 2022 17:13:01 -0500

Your H does not "correctly predict" that Px() does reach its final

state and so should accept the input as halting.

/Flibble

state and so should accept the input as halting.

/Flibble

Jul 3, 2022, 10:58:06 AMJul 3

to

The semantics of the x86 language conclusively proves that the above

code is correct. People that disagree with verified facts are either

incompetent or liars. Since you cannot even understand that the return

statement in Px is unreachable code, (to every simulating halt decider

H) you would be incompetent.

Jul 3, 2022, 11:21:44 AMJul 3

to

On Sun, 3 Jul 2022 09:57:57 -0500

Not EVERY simulating halt decider, only YOURS gets the answer wrong.

Px() halts.

/Flibble

Px() halts.

/Flibble

Jul 3, 2022, 11:30:54 AMJul 3

to

incompetent.

Jul 3, 2022, 11:45:40 AMJul 3

to

On Sun, 3 Jul 2022 10:30:45 -0500

Not at all. If I was to design a simulating halt decider then rather

than aborting the simulation at the point where P()/Px() calls H I

would instead fork the simulation, returning 0 to one branch (the

non-halting branch) and 1 to the other branch (the halting branch) and

then continue to simulate both branches in parallel thereby getting rid

of the "infinite recursion".

/Flibble

than aborting the simulation at the point where P()/Px() calls H I

would instead fork the simulation, returning 0 to one branch (the

non-halting branch) and 1 to the other branch (the halting branch) and

then continue to simulate both branches in parallel thereby getting rid

of the "infinite recursion".

/Flibble

Jul 3, 2022, 11:48:27 AMJul 3

to

in infinite recursion is not allowed to return to its caller.

Jul 3, 2022, 11:51:07 AMJul 3

to

On Sun, 3 Jul 2022 10:48:18 -0500

The infinite recursion is an artifact of how YOU are trying to solve

the problem; there is no infinite recursion in [Strachey 1965] and

associated proofs.

/Flibble

the problem; there is no infinite recursion in [Strachey 1965] and

associated proofs.

/Flibble

Jul 3, 2022, 12:05:30 PMJul 3

to

long as it correctly predicts the behavior of the input.

*This general principle refutes conventional halting problem proofs*

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.

*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

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

Jul 3, 2022, 12:07:03 PMJul 3

to

On Sun, 3 Jul 2022 11:05:21 -0500

Your H does not correctly predict the behavior of Px() as Px() always

halts yet your H incorrectly says it doesn't.

/Flibble

halts yet your H incorrectly says it doesn't.

/Flibble

Jul 4, 2022, 12:57:28 PMJul 4

to

On 7/4/2022 11:36 AM, dklei...@gmail.com wrote:

> On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote:

>> On 7/3/2022 6:10 PM, dklei...@gmail.com wrote:

>>> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote:

>>>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote:

>>>>> called routine that stops when it can predict that the routine

>>>>> will never return is called a halt decider.

>>>>>

>>>>> In words of one syllable - so what?

>>>>

>>>> It refutes conventional halting problem proofs

>>>>

>>> It might if any such halt deciders existed. You need to prove such "halt

>>> deciders" exist.

>>

>> You can't keep ignoring my paper and claiming that I have not proved my

>> point.

> be expected because my standard is mathematical proof and

> you don't even pretend to be doing mathematics.

When we construe the x86 language and its associated semantics as a

formal language with formal semantics then this becomes a formal proof:

From a purely software engineering perspective (anchored in the

semantics of the x86 language) it is proven that H(P,P) correctly

predicts that its correct and complete x86 emulation of its input would

never reach the "ret" instruction (final state) of this input.

> On Sunday, July 3, 2022 at 5:44:32 PM UTC-7, olcott wrote:

>> On 7/3/2022 6:10 PM, dklei...@gmail.com wrote:

>>> On Sunday, July 3, 2022 at 12:51:41 PM UTC-7, olcott wrote:

>>>> On 7/3/2022 2:35 PM, dklei...@gmail.com wrote:

>>>>> On Sunday, July 3, 2022 at 9:05:30 AM UTC-7, olcott wrote:

>>>>>>

>>>>>> *This general principle refutes conventional halting problem proofs*

>>>>>>

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

>>>>>>

>>>>> This "general principle is" a trivial definition: A simulation of a
>>>>>>

>>>>>> *This general principle refutes conventional halting problem proofs*

>>>>>>

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

>>>>>>

>>>>> called routine that stops when it can predict that the routine

>>>>> will never return is called a halt decider.

>>>>>

>>>>> In words of one syllable - so what?

>>>>

>>>> It refutes conventional halting problem proofs

>>>>

>>> It might if any such halt deciders existed. You need to prove such "halt

>>> deciders" exist.

>>

>> You can't keep ignoring my paper and claiming that I have not proved my

>> point.

>> *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 paper is not acceptable as a proof of anything. But that is to
>>

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

>>

> be expected because my standard is mathematical proof and

> you don't even pretend to be doing mathematics.

When we construe the x86 language and its associated semantics as a

formal language with formal semantics then this becomes a formal proof:

From a purely software engineering perspective (anchored in the

semantics of the x86 language) it is proven that H(P,P) correctly

predicts that its correct and complete x86 emulation of its input would

never reach the "ret" instruction (final state) of this input.

Jul 4, 2022, 3:17:38 PMJul 4

to

On 7/4/2022 1:42 PM, dklei...@gmail.com wrote:

> There is a great deal more to a mathematical proof than a formal

> language. I believe that you do not have training in mathematics and you

> do show little sympathy for the concerns of the mathematical

> community. What you call "software engineering" is essentially hostile to

> classical mathematics.

>

> Moreover if you wish us to take you seriously you must do more than

> "construing". You must exhibit the x86 "language" as a formal system

> and show how it is used in a formal proof.

What more is there to the essence of any formal proof besides applying

the formal semantics specified by a formal language as a sequence of

truth preserving steps?

Instead of premises a computation has an initial state.

Instead of a conclusion premises a computation has a final state.

*Curry–Howard correspondence*

In programming language theory and proof theory, the Curry–Howard

correspondence (also known as the Curry–Howard isomorphism or

equivalence, or the proofs-as-programs and propositions- or

formulae-as-types interpretation) is the direct relationship between

computer programs and mathematical proofs.

https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

> language. I believe that you do not have training in mathematics and you

> do show little sympathy for the concerns of the mathematical

> community. What you call "software engineering" is essentially hostile to

> classical mathematics.

>

> Moreover if you wish us to take you seriously you must do more than

> "construing". You must exhibit the x86 "language" as a formal system

> and show how it is used in a formal proof.

What more is there to the essence of any formal proof besides applying

the formal semantics specified by a formal language as a sequence of

truth preserving steps?

Instead of premises a computation has an initial state.

Instead of a conclusion premises a computation has a final state.

*Curry–Howard correspondence*

In programming language theory and proof theory, the Curry–Howard

correspondence (also known as the Curry–Howard isomorphism or

equivalence, or the proofs-as-programs and propositions- or

formulae-as-types interpretation) is the direct relationship between

computer programs and mathematical proofs.

https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

Jul 4, 2022, 3:21:29 PMJul 4

to

Jul 4, 2022, 7:08:12 PMJul 4

to

On 7/4/2022 1:42 PM, dklei...@gmail.com wrote:

> On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote:

> On Monday, July 4, 2022 at 9:57:28 AM UTC-7, olcott wrote:

> There is a great deal more to a mathematical proof than a formal

> language. I believe that you do not have training in mathematics and you

> do show little sympathy for the concerns of the mathematical

> community. What you call "software engineering" is essentially hostile to

> classical mathematics.

>

> Moreover if you wish us to take you seriously you must do more than

> "construing". You must exhibit the x86 "language" as a formal system

> and show how it is used in a formal proof.

It would seem that *Curry–Howard correspondence*
> language. I believe that you do not have training in mathematics and you

> do show little sympathy for the concerns of the mathematical

> community. What you call "software engineering" is essentially hostile to

> classical mathematics.

>

> Moreover if you wish us to take you seriously you must do more than

> "construing". You must exhibit the x86 "language" as a formal system

> and show how it is used in a formal proof.

https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

would allow the x86 language and its semantics to be construed as a

formal system such that the initial state and final state of a

computable function along with all of the state transitions between

could be construed as a formal proof.

Jul 5, 2022, 8:59:19 AMJul 5

to

On 7/5/2022 3:53 AM, Mikko wrote:

> in the proof with the numbers of that sentence or those two sentences from

> which the sentence is derived with truth preserving rules.

>

> Mikko

>

>

The proof is (Curry/Howard Correspondence) between programs and proofs,

thus H has an initial state performs a sequence of state transitions and

ends in a final state rejecting its input as non-halting.

> On 2022-07-04 00:44:23 +0000, olcott said:

>

>> You can't keep ignoring my paper and claiming that I have not proved

>> my point.

>

> In order to make your proof publishable, you should decrate every sentence
>

>> You can't keep ignoring my paper and claiming that I have not proved

>> my point.

>

> in the proof with the numbers of that sentence or those two sentences from

> which the sentence is derived with truth preserving rules.

>

> Mikko

>

>

The proof is (Curry/Howard Correspondence) between programs and proofs,

thus H has an initial state performs a sequence of state transitions and

ends in a final state rejecting its input as non-halting.

Jul 5, 2022, 9:00:49 AMJul 5

to

On 7/5/2022 7:59 AM, olcott wrote:

> On 7/5/2022 3:53 AM, Mikko wrote:

>> On 2022-07-04 00:44:23 +0000, olcott said:

>>

>>> You can't keep ignoring my paper and claiming that I have not proved

>>> my point.

>>

>> In order to make your proof publishable, you should decrate every

>> sentence

>> in the proof with the numbers of that sentence or those two sentences

>> from

>> which the sentence is derived with truth preserving rules.

>>

>> Mikko

>>

>>

>

> The proof is (Curry/Howard Correspondence) between programs and proofs,

> thus H has an initial state performs a sequence of state transitions and

> ends in a final state rejecting its input as non-halting.

>

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

>

>

> On 7/5/2022 3:53 AM, Mikko wrote:

>> On 2022-07-04 00:44:23 +0000, olcott said:

>>

>>> You can't keep ignoring my paper and claiming that I have not proved

>>> my point.

>>

>> In order to make your proof publishable, you should decrate every

>> sentence

>> in the proof with the numbers of that sentence or those two sentences

>> from

>> which the sentence is derived with truth preserving rules.

>>

>> Mikko

>>

>>

>

> The proof is (Curry/Howard Correspondence) between programs and proofs,

> thus H has an initial state performs a sequence of state transitions and

> ends in a final state rejecting its input as non-halting.

>

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

>

>

From a purely software engineering perspective (anchored in the

semantics of the x86 language) it is proven that H(P,P) correctly

predicts that its correct and complete x86 emulation of its input would

never reach the "ret" instruction (final state) of this input.

semantics of the x86 language) it is proven that H(P,P) correctly

predicts that its correct and complete x86 emulation of its input would

never reach the "ret" instruction (final state) of this input.

Jul 5, 2022, 3:31:47 PMJul 5

to

On 7/5/2022 1:50 PM, dklei...@gmail.com wrote:

> I am afraid you don't see mathematical proof like a mathematician

> might. A good and simple example is the theorem that proves all

> Burnside three groups are finite.

>

> But if you do want to use the Curry-Howard correspondence as a

> proof method you must either reference the formal x86 language

> formulation or yourself supply such a formal language description.

>

I already provided this:

x86 Instruction Set Reference

https://c9x.me/x86/

> Your task would be much easier were you to use C as the formal

> language. And much easier to follow.

If we use C as the formal language then we have to translate it into its

corresponding directed graph of control flow ourselves or the computer

will not be able to process it.

I use C/x86 together so the human can examine the C and the machine can

examine the machine code and the human can see the bijection between the

C and the machine code as assembly language generated from the C.

void P(u32 x)

{

if (H(x, x))

HERE: goto HERE;

return;

}

_P()

[00001202](01) 55 push ebp

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

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

[00001208](01) 50 push eax

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

[0000120c](01) 51 push ecx

[0000120d](05) e820feffff call 00001032

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

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

[00001217](02) 7402 jz 0000121b

[00001219](02) ebfe jmp 00001219

[0000121b](01) 5d pop ebp

[0000121c](01) c3 ret

Size in bytes:(0027) [0000121c]

> might. A good and simple example is the theorem that proves all

> Burnside three groups are finite.

>

> But if you do want to use the Curry-Howard correspondence as a

> proof method you must either reference the formal x86 language

> formulation or yourself supply such a formal language description.

>

I already provided this:

x86 Instruction Set Reference

https://c9x.me/x86/

> Your task would be much easier were you to use C as the formal

> language. And much easier to follow.

If we use C as the formal language then we have to translate it into its

corresponding directed graph of control flow ourselves or the computer

will not be able to process it.

I use C/x86 together so the human can examine the C and the machine can

examine the machine code and the human can see the bijection between the

C and the machine code as assembly language generated from the C.

void P(u32 x)

{

if (H(x, x))

HERE: goto HERE;

return;

}

[00001202](01) 55 push ebp

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

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

[00001208](01) 50 push eax

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

[0000120c](01) 51 push ecx

[0000120d](05) e820feffff call 00001032

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

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

[00001217](02) 7402 jz 0000121b

[00001219](02) ebfe jmp 00001219

[0000121b](01) 5d pop ebp

[0000121c](01) c3 ret

Size in bytes:(0027) [0000121c]

Jul 5, 2022, 4:42:34 PMJul 5

to

On 7/5/2022 3:24 PM, André G. Isaak wrote:

> On 2022-07-05 12:50, dklei...@gmail.com wrote:

> he'd be better off using Scheme or Haskell or something like that...

>

> But it wouldn't make a difference. He has not provided an actual proof

> NOR an actual program, so talking about some alleged correspondence

> between two imaginary entities is hardly going to enlighten anyone.

>

> André

>

Welcome back you are one of my competent reviewers.

*My most recent paper provides complete proof of this*

From a purely software engineering perspective (anchored in the

semantics of the x86 language) it is proven that H(P,P) correctly

predicts that its correct and complete x86 emulation of its input would

never reach the "ret" instruction (final state) of this input.

The start state, state transitions inbetween and the final state of a

computation can be construed as a formal proof from premises to conclusion.

> On 2022-07-05 12:50, dklei...@gmail.com wrote:

>> I am afraid you don't see mathematical proof like a mathematician

>> might. A good and simple example is the theorem that proves all

>> Burnside three groups are finite.

>>

>> But if you do want to use the Curry-Howard correspondence as a

>> proof method you must either reference the formal x86 language

>> formulation or yourself supply such a formal language description.

>>

>> might. A good and simple example is the theorem that proves all

>> Burnside three groups are finite.

>>

>> But if you do want to use the Curry-Howard correspondence as a

>> proof method you must either reference the formal x86 language

>> formulation or yourself supply such a formal language description.

>>

>> Your task would be much easier were you to use C as the formal

>> language. And much easier to follow.

>

> If he really wants to use (and if he actually understood) Curry-Howard,
>> language. And much easier to follow.

>

> he'd be better off using Scheme or Haskell or something like that...

>

> But it wouldn't make a difference. He has not provided an actual proof

> NOR an actual program, so talking about some alleged correspondence

> between two imaginary entities is hardly going to enlighten anyone.

>

> André

>

Welcome back you are one of my competent reviewers.

*My most recent paper provides complete proof of this*

From a purely software engineering perspective (anchored in the

semantics of the x86 language) it is proven that H(P,P) correctly

predicts that its correct and complete x86 emulation of its input would

never reach the "ret" instruction (final state) of this input.

*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

*Only to those having the required software engineering prerequisites*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

The start state, state transitions inbetween and the final state of a

computation can be construed as a formal proof from premises to conclusion.

Jul 5, 2022, 7:29:29 PMJul 5

to

but replaces the call to H with parameters P,P with something that acts

differently then the actual call to H(P,P) from "main", so fails to meet

the requirements of Curly-Howard.

Note, your rule (b) is incorrect as you use it, which is a core fault

with your "proof".

Jul 5, 2022, 7:31:26 PMJul 5

to

On 7/5/22 8:59 AM, olcott wrote:

> On 7/5/2022 3:53 AM, Mikko wrote:

>> On 2022-07-04 00:44:23 +0000, olcott said:

>>

>>> You can't keep ignoring my paper and claiming that I have not proved

>>> my point.

>>

>> In order to make your proof publishable, you should decrate every

>> sentence

>> in the proof with the numbers of that sentence or those two sentences

>> from

>> which the sentence is derived with truth preserving rules.

>>

>> Mikko

>>

>>

>

> The proof is (Curry/Howard Correspondence) between programs and proofs,

> thus H has an initial state performs a sequence of state transitions and

> ends in a final state rejecting its input as non-halting.

>

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

>

>

Curry-Hooward would say that P(P) is proved to be Halting (if H(P,P)
> On 7/5/2022 3:53 AM, Mikko wrote:

>> On 2022-07-04 00:44:23 +0000, olcott said:

>>

>>> You can't keep ignoring my paper and claiming that I have not proved

>>> my point.

>>

>> In order to make your proof publishable, you should decrate every

>> sentence

>> in the proof with the numbers of that sentence or those two sentences

>> from

>> which the sentence is derived with truth preserving rules.

>>

>> Mikko

>>

>>

>

> The proof is (Curry/Howard Correspondence) between programs and proofs,

> thus H has an initial state performs a sequence of state transitions and

> ends in a final state rejecting its input as non-halting.

>

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

>

>

returns 0), so H(P,P) returning 0 can't be the correct answer for a

Halting decider.

If you want to try to claim that the input to H(P,P) doesn't represent

P(P), then your P is written incorrectly, so your "proof" is still invalid.

Jul 5, 2022, 8:01:17 PMJul 5

to

On 7/5/2022 6:53 PM, Ben Bacarisse wrote:

> he has no idea what the Curry-Howard correspondence is about. It's

> simply not relevant to "x86 language".

>

> If anyone can be bothered to show that PO knows nothing about this

> subtopic, just ask him: what is the type of the "x86 language" program

> that corresponds to the proof he is claiming.

> cranks.

>

Bullshit Ben and you know better:

The halt decider must have machine code the human users can see this in

C and the assembly language mapping from C to x86 assembly language

allows the human users to see what the halt decider is doing and verify

that it is correct.

> "dklei...@gmail.com" <dklei...@gmail.com> writes:

>

>> But if you do want to use the Curry-Howard correspondence as a

>> proof method you must either reference the formal x86 language

>> formulation or yourself supply such a formal language description.

>

> Goodness, no. He'd have to do a whole lot more than that. It's clear
>

>> But if you do want to use the Curry-Howard correspondence as a

>> proof method you must either reference the formal x86 language

>> formulation or yourself supply such a formal language description.

>

> he has no idea what the Curry-Howard correspondence is about. It's

> simply not relevant to "x86 language".

>

> If anyone can be bothered to show that PO knows nothing about this

> subtopic, just ask him: what is the type of the "x86 language" program

> that corresponds to the proof he is claiming.

>

>> Your task would be much easier were you to use C as the formal

>> language. And much easier to follow.

>

> But that's *why* he's not using anything better. Clarity is anathema to
>> Your task would be much easier were you to use C as the formal

>> language. And much easier to follow.

>

> cranks.

>

Bullshit Ben and you know better:

The halt decider must have machine code the human users can see this in

C and the assembly language mapping from C to x86 assembly language

allows the human users to see what the halt decider is doing and verify

that it is correct.

Jul 5, 2022, 8:50:18 PMJul 5

to

On 7/5/2022 6:53 PM, Ben Bacarisse wrote:

> "dklei...@gmail.com" <dklei...@gmail.com> writes:

>

>> But if you do want to use the Curry-Howard correspondence as a

>> proof method you must either reference the formal x86 language

>> formulation or yourself supply such a formal language description.

>

> Goodness, no. He'd have to do a whole lot more than that. It's clear

> he has no idea what the Curry-Howard correspondence is about. It's

> simply not relevant to "x86 language".

>

> "dklei...@gmail.com" <dklei...@gmail.com> writes:

>

>> But if you do want to use the Curry-Howard correspondence as a

>> proof method you must either reference the formal x86 language

>> formulation or yourself supply such a formal language description.

>

> Goodness, no. He'd have to do a whole lot more than that. It's clear

> he has no idea what the Curry-Howard correspondence is about. It's

> simply not relevant to "x86 language".

>

In programming language theory and proof theory, the Curry–Howard

correspondence (also known as the Curry–Howard isomorphism or

equivalence, or the proofs-as-programs and propositions- or

formulae-as-types interpretation) is the direct relationship between

computer programs and mathematical proofs.

https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

The generic idea that there is an isomorphism between mathematical
correspondence (also known as the Curry–Howard isomorphism or

equivalence, or the proofs-as-programs and propositions- or

formulae-as-types interpretation) is the direct relationship between

computer programs and mathematical proofs.

https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

proofs and computations can be understood in that the initial state of a

computation corresponds to the premises of a formal proof. The state

transitions of a computation correspond to the inference steps of a

formal proof. The final state of a computation correspond to the

conclusion of a formal proof.

Curry/Howard does not do it exactly this way. The x86 language and its

semantics would comprise one example of a formal system of the

Olcott/isomorphism.

> If anyone can be bothered to show that PO knows nothing about this

> subtopic, just ask him: what is the type of the "x86 language" program

> that corresponds to the proof he is claiming.

>

>> Your task would be much easier were you to use C as the formal

>> language. And much easier to follow.

>

> But that's *why* he's not using anything better. Clarity is anathema to

> cranks.

>

Jul 5, 2022, 10:37:23 PMJul 5

to

On 7/5/2022 6:53 PM, Ben Bacarisse wrote:

> "dklei...@gmail.com" <dklei...@gmail.com> writes:

>

>> But if you do want to use the Curry-Howard correspondence as a

>> proof method you must either reference the formal x86 language

>> formulation or yourself supply such a formal language description.

>

> Goodness, no. He'd have to do a whole lot more than that. It's clear

> he has no idea what the Curry-Howard correspondence is about. It's

> simply not relevant to "x86 language".

>

> "dklei...@gmail.com" <dklei...@gmail.com> writes:

>

>> But if you do want to use the Curry-Howard correspondence as a

>> proof method you must either reference the formal x86 language

>> formulation or yourself supply such a formal language description.

>

> Goodness, no. He'd have to do a whole lot more than that. It's clear

> he has no idea what the Curry-Howard correspondence is about. It's

> simply not relevant to "x86 language".

>

> If anyone can be bothered to show that PO knows nothing about this

> subtopic, just ask him: what is the type of the "x86 language" program

> that corresponds to the proof he is claiming.

>

>> Your task would be much easier were you to use C as the formal

>> language. And much easier to follow.

>

> But that's *why* he's not using anything better. Clarity is anathema to

> cranks.

>

> subtopic, just ask him: what is the type of the "x86 language" program

> that corresponds to the proof he is claiming.

>

>> Your task would be much easier were you to use C as the formal

>> language. And much easier to follow.

>

> But that's *why* he's not using anything better. Clarity is anathema to

> cranks.

>

Bullshit Ben and you know better:

The halt decider must have machine code the human users can see this in

C and the assembly language mapping from C to x86 assembly language

allows the human users to see what the halt decider is doing and verify

that it is correct.

The halt decider must have machine code the human users can see this in

C and the assembly language mapping from C to x86 assembly language

allows the human users to see what the halt decider is doing and verify

that it is correct.

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

Jul 6, 2022, 5:13:47 PMJul 6

to

On 7/6/2022 3:58 PM, dklei...@gmail.com wrote:

> On Tuesday, July 5, 2022 at 9:02:28 PM UTC-7, olcott wrote:

>> On 7/5/2022 11:00 PM, dklei...@gmail.com wrote:

>>

>> It is not impossible it is merely 1000-fold more work that is already

>> done by the compiler. Do you know what a directed graph is?

>>

> I know what a directed graph is and I don't see why you mention them.

>

> There is no reason to ever compiler so the compiler is not necessary.

> C is a perfectly good well-defined formal language. And apparently

> you agree your arguments could be expressed in C.

When a C function is translated into machine code it is very easy for a

computer program to examine the control flow of this x86 emulated x86

code while it is running.

This is not at all the case when the halt decider only has static C

source-code. In this case the halt decider would be required to

implement its own C interpreter before it could begin its dynamic analysis.

Another advantage of x86 machine code is there there are no multiple

levels of nested control flow, there is only a single flat address

space. Every control flow is simply a directed path from, one address to

another, forming a single network of all control flow.

> On Tuesday, July 5, 2022 at 9:02:28 PM UTC-7, olcott wrote:

>> On 7/5/2022 11:00 PM, dklei...@gmail.com wrote:

>>> On Tuesday, July 5, 2022 at 5:01:17 PM UTC-7, olcott wrote:

>>>>

>>>> The halt decider must have machine code

>>>>

>>> Why? What is impossible to do in C?
>>>>

>>>> The halt decider must have machine code

>>>>

>>

>> It is not impossible it is merely 1000-fold more work that is already

>> done by the compiler. Do you know what a directed graph is?

>>

> I know what a directed graph is and I don't see why you mention them.

>

> There is no reason to ever compiler so the compiler is not necessary.

> C is a perfectly good well-defined formal language. And apparently

> you agree your arguments could be expressed in C.

When a C function is translated into machine code it is very easy for a

computer program to examine the control flow of this x86 emulated x86

code while it is running.

This is not at all the case when the halt decider only has static C

source-code. In this case the halt decider would be required to

implement its own C interpreter before it could begin its dynamic analysis.

Another advantage of x86 machine code is there there are no multiple

levels of nested control flow, there is only a single flat address

space. Every control flow is simply a directed path from, one address to

another, forming a single network of all control flow.

Jul 7, 2022, 5:08:19 PMJul 7

to

On 7/7/2022 3:54 PM, dklei...@gmail.com wrote:

> On Thursday, July 7, 2022 at 12:39:41 PM UTC-7, olcott wrote:

>> On 7/7/2022 2:19 PM, dklei...@gmail.com wrote:

>>> Have you ever dissambled a complex program? Especially one written in

>>> assembly? Making sense of the control flow is usually the hardest part of

>>> the task. IMO, and that of the computer community in general, is that

>>> higher order languages - such as C - are much easier to read.

>>>

>> *I will repeat this point several times because you keep not getting it*

>>

>> Control flow x86 is much easier for machines than control flow in C

>> Control flow x86 is much easier for machines than control flow in C

>> Control flow x86 is much easier for machines than control flow in C

>> Control flow x86 is much easier for machines than control flow in C

>> Control flow x86 is much easier for machines than control flow in C

>

> It might be easier for the machine. But that's not the point. The goal

> of a proof is to convince human readers that such-and-such is true.

If the human reader is too lazy to understand the x86 language then the

human reader is too lazy to understand what the halt decider is doing.

> So what matters is humans reading formal languages.

>

What are the properties of a formal language that distinguish it from a

natural language? The x86 language has all of these properties.

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

https://en.wikipedia.org/wiki/Semantics_(computer_science)

> This is, rather clearly, subjective. What is easy for me might be hard

> for you. But the audience of proofs - usually mathematicians - clearly

> prefers higher-order languages. C is probably not the best choice of

> formal language but it will do if you must use it.

Readers that insist on making sure that they continue to lack the

mandatory prerequisites to understand my proof will continue to fail to

understand my proof.

*To fully understand this paper a*

*software engineer must be an expert in*

(a) The C programming language.

(b) The x86 programming language.

(c) Exactly how C translates into x86 (how C function calls are

implemented in x86).

(d) The ability to recognize infinite recursion at the x86 assembly

language level.

*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

> On Thursday, July 7, 2022 at 12:39:41 PM UTC-7, olcott wrote:

>> On 7/7/2022 2:19 PM, dklei...@gmail.com wrote:

>>> assembly? Making sense of the control flow is usually the hardest part of

>>> the task. IMO, and that of the computer community in general, is that

>>> higher order languages - such as C - are much easier to read.

>>>

>> *I will repeat this point several times because you keep not getting it*

>>

>> Control flow x86 is much easier for machines than control flow in C

>> Control flow x86 is much easier for machines than control flow in C

>> Control flow x86 is much easier for machines than control flow in C

>> Control flow x86 is much easier for machines than control flow in C

>> Control flow x86 is much easier for machines than control flow in C

>

> It might be easier for the machine. But that's not the point. The goal

> of a proof is to convince human readers that such-and-such is true.

If the human reader is too lazy to understand the x86 language then the

human reader is too lazy to understand what the halt decider is doing.

> So what matters is humans reading formal languages.

>

What are the properties of a formal language that distinguish it from a

natural language? The x86 language has all of these properties.

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

https://en.wikipedia.org/wiki/Semantics_(computer_science)

> This is, rather clearly, subjective. What is easy for me might be hard

> for you. But the audience of proofs - usually mathematicians - clearly

> prefers higher-order languages. C is probably not the best choice of

> formal language but it will do if you must use it.

Readers that insist on making sure that they continue to lack the

mandatory prerequisites to understand my proof will continue to fail to

understand my proof.

*To fully understand this paper a*

*software engineer must be an expert in*

(a) The C programming language.

(b) The x86 programming language.

(c) Exactly how C translates into x86 (how C function calls are

implemented in x86).

(d) The ability to recognize infinite recursion at the x86 assembly

language level.

*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

Jul 7, 2022, 9:34:32 PMJul 7

to

On 7/7/2022 7:36 PM, dklei...@gmail.com wrote:

> necessary? Reading C is much easier than reading x86.

Then we have disagreements that are entirely based on interpreting the

vagueness differently.

typedef void (*ptr)();

// rec routine P

// §L :if T[P] go to L

// Return §

void Strachey_P()

{

L: if (T(Strachey_P)) goto L;

return;

}

int main()

{

Output("Input_Halts = ", T(Strachey_P));

}

When I say that simulating halt decider T correctly determines that its

input never reaches its "return" statement on the basis that T can see

Strachey_P calling itself with its same parameters there are not enough

details provided to correctly understand that I am necessarily correct.

*When we look at the x86 level we have 100% of all of these details*

>>

>>> So what matters is humans reading formal languages.

>>>

>> What are the properties of a formal language that distinguish it from a

>> natural language?

>>

> Formal language is very different than natural language. But the

> difference that matters is that formal languages are precisely defined -

> in both syntax and semantics. The higher-order computer languages

> are designed (precisely) to feel more like natural language to the user.

The x86 language is this same way.

> On Thursday, July 7, 2022 at 2:08:19 PM UTC-7, olcott wrote:

>> On 7/7/2022 3:54 PM, dklei...@gmail.com wrote:

>>> On Thursday, July 7, 2022 at 12:39:41 PM UTC-7, olcott wrote:

>>>> On 7/7/2022 2:19 PM, dklei...@gmail.com wrote:

>>

>>>>> Have you ever dissambled a complex program? Especially one written in

>>>>> assembly? Making sense of the control flow is usually the hardest part of

>>>>> the task. IMO, and that of the computer community in general, is that

>>>>> higher order languages - such as C - are much easier to read.

>>>>>

> . . .
>> On 7/7/2022 3:54 PM, dklei...@gmail.com wrote:

>>> On Thursday, July 7, 2022 at 12:39:41 PM UTC-7, olcott wrote:

>>>> On 7/7/2022 2:19 PM, dklei...@gmail.com wrote:

>>

>>>>> Have you ever dissambled a complex program? Especially one written in

>>>>> assembly? Making sense of the control flow is usually the hardest part of

>>>>> the task. IMO, and that of the computer community in general, is that

>>>>> higher order languages - such as C - are much easier to read.

>>>>>

>>>> Control flow x86 is much easier for machines than control flow in C

>>>

>>> It might be easier for the machine. But that's not the point. The goal

>>> of a proof is to convince human readers that such-and-such is true.

>>

>> If the human reader is too lazy to understand the x86 language then the

>> human reader is too lazy to understand what the halt decider is doing.

>

> Why ask them to do something orders of magnitude harder than
>>>

>>> It might be easier for the machine. But that's not the point. The goal

>>> of a proof is to convince human readers that such-and-such is true.

>>

>> If the human reader is too lazy to understand the x86 language then the

>> human reader is too lazy to understand what the halt decider is doing.

>

> necessary? Reading C is much easier than reading x86.

Then we have disagreements that are entirely based on interpreting the

vagueness differently.

typedef void (*ptr)();

// rec routine P

// §L :if T[P] go to L

// Return §

void Strachey_P()

{

L: if (T(Strachey_P)) goto L;

return;

}

int main()

{

Output("Input_Halts = ", T(Strachey_P));

}

When I say that simulating halt decider T correctly determines that its

input never reaches its "return" statement on the basis that T can see

Strachey_P calling itself with its same parameters there are not enough

details provided to correctly understand that I am necessarily correct.

*When we look at the x86 level we have 100% of all of these details*

>>

>>> So what matters is humans reading formal languages.

>>>

>> What are the properties of a formal language that distinguish it from a

>> natural language?

>>

> difference that matters is that formal languages are precisely defined -

> in both syntax and semantics. The higher-order computer languages

> are designed (precisely) to feel more like natural language to the user.

The x86 language is this same way.

Jul 8, 2022, 12:48:17 AMJul 8

to

On 7/7/2022 11:35 PM, dklei...@gmail.com wrote:

> if (T(&Strachey_P)) return 1;

> else return 0; }

>

> int main() {

> if (T(&Strachey_P)) Output("Halts");

> else Output ("Does not halt");}

>

> Without the definition of T this is just boiler plate.

Yours is incorrect:

typedef void (*ptr)();

// rec routine P

// §L :if T[P] go to L

// Return §

void Strachey_P()

{

L: if (T(Strachey_P)) goto L;

return;

}

int main()

{

Output("Input_Halts = ", T(Strachey_P));

}

> On Thursday, July 7, 2022 at 6:34:32 PM UTC-7, olcott wrote:

>> On 7/7/2022 7:36 PM, dklei...@gmail.com wrote:

>>> On Thursday, July 7, 2022 at 2:08:19 PM UTC-7, olcott wrote:

>>>> On 7/7/2022 3:54 PM, dklei...@gmail.com wrote:

>>>>> On Thursday, July 7, 2022 at 12:39:41 PM UTC-7, olcott wrote:

>>>>>> On 7/7/2022 2:19 PM, dklei...@gmail.com wrote:

>>>>

>>>>>>> Have you ever dissambled a complex program? Especially one written in

>>>>>>> assembly? Making sense of the control flow is usually the hardest part of

>>>>>>> the task. IMO, and that of the computer community in general, is that

>>>>>>> higher order languages - such as C - are much easier to read.

>>>>>>>

>>> . . .

>>>>>> Control flow x86 is much easier for machines than control flow in C

>>>>>

>>>>> It might be easier for the machine. But that's not the point. The goal

>>>>> of a proof is to convince human readers that such-and-such is true.

>>>>

>>>> If the human reader is too lazy to understand the x86 language then the

>>>> human reader is too lazy to understand what the halt decider is doing.

>>>

>>> Why ask them to do something orders of magnitude harder than

>>> necessary? Reading C is much easier than reading x86.

>> Then we have disagreements that are entirely based on interpreting the

>> vagueness differently.

>>

> int Strachey_P(void) {
>> On 7/7/2022 7:36 PM, dklei...@gmail.com wrote:

>>> On Thursday, July 7, 2022 at 2:08:19 PM UTC-7, olcott wrote:

>>>> On 7/7/2022 3:54 PM, dklei...@gmail.com wrote:

>>>>> On Thursday, July 7, 2022 at 12:39:41 PM UTC-7, olcott wrote:

>>>>>> On 7/7/2022 2:19 PM, dklei...@gmail.com wrote:

>>>>

>>>>>>> Have you ever dissambled a complex program? Especially one written in

>>>>>>> assembly? Making sense of the control flow is usually the hardest part of

>>>>>>> the task. IMO, and that of the computer community in general, is that

>>>>>>> higher order languages - such as C - are much easier to read.

>>>>>>>

>>> . . .

>>>>>> Control flow x86 is much easier for machines than control flow in C

>>>>>

>>>>> It might be easier for the machine. But that's not the point. The goal

>>>>> of a proof is to convince human readers that such-and-such is true.

>>>>

>>>> If the human reader is too lazy to understand the x86 language then the

>>>> human reader is too lazy to understand what the halt decider is doing.

>>>

>>> Why ask them to do something orders of magnitude harder than

>>> necessary? Reading C is much easier than reading x86.

>> Then we have disagreements that are entirely based on interpreting the

>> vagueness differently.

>>

> if (T(&Strachey_P)) return 1;

> else return 0; }

>

> int main() {

> if (T(&Strachey_P)) Output("Halts");

> else Output ("Does not halt");}

>

> Without the definition of T this is just boiler plate.

Yours is incorrect:

typedef void (*ptr)();

// rec routine P

// §L :if T[P] go to L

// Return §

void Strachey_P()

{

L: if (T(Strachey_P)) goto L;

return;

}

int main()

{

Output("Input_Halts = ", T(Strachey_P));

}

Jul 9, 2022, 2:40:46 PMJul 9

to

On 7/9/2022 12:22 PM, dklei...@gmail.com wrote:

> On Saturday, July 9, 2022 at 6:16:37 AM UTC-7, olcott wrote:

>> On 7/8/2022 5:48 PM, olcott wrote:

>>> On 7/8/2022 1:09 AM, dklei...@gmail.com wrote:

>>>

>>> typedef void (*ptr)();

>>>

>>> int Strachey_P2(void) {

>>> if (T(&Strachey_P2)) return 1;

>>> else OutputString("Does not halt\n");

>>> }

>>>

>>> _Strachey_P2()

>>> [0000134e](01) 55 push ebp

>>> [0000134f](02) 8bec mov ebp,esp

>>> [00001351](05) 684e130000 push 0000134e

>>> [00001356](05) e893fbffff call 00000eee

>>> [0000135b](03) 83c404 add esp,+04

>>> [0000135e](02) 85c0 test eax,eax

>>> [00001360](02) 7409 jz 0000136b

>>> [00001362](05) b801000000 mov eax,00000001

>>> [00001367](02) eb04 jmp 0000136d

>>> [00001369](02) eb02 jmp 0000136d

>>> [0000136b](02) 33c0 xor eax,eax

>>> [0000136d](01) 5d pop ebp

>>> [0000136e](01) c3 ret

>>> Size in bytes:(0033) [0000136e]

>>>

>>> _main()

>>> [0000137e](01) 55 push ebp

>>> [0000137f](02) 8bec mov ebp,esp

>>> [00001381](05) 684e130000 push 0000134e

>>> [00001386](05) e863fbffff call 00000eee

>>> [0000138b](03) 83c404 add esp,+04

>>> [0000138e](02) 85c0 test eax,eax

>>> [00001390](02) 740f jz 000013a1

>>> [00001392](05) 6817050000 push 00000517

>>> [00001397](05) e8c2f1ffff call 0000055e

>>> [0000139c](03) 83c404 add esp,+04

>>> [0000139f](02) eb0d jmp 000013ae

>>> [000013a1](05) 681f050000 push 0000051f

>>> [000013a6](05) e8b3f1ffff call 0000055e

>>> [000013ab](03) 83c404 add esp,+04

>>> [000013ae](02) 33c0 xor eax,eax

>>> [000013b0](01) 5d pop ebp

>>> [000013b1](01) c3 ret

>>> Size in bytes:(0052) [000013b1]

>>> [0000137f][001022be][00000000] 8bec mov ebp,esp

>>> [00001381][001022ba][0000134e] 684e130000 push 0000134e

>>> [00001386][001022b6][0000138b] e863fbffff call 00000eee

>>>

>>> T: Begin Simulation Execution Trace Stored at:11236a

>>> Address_of_T:eee

>>> [0000134e][0011235a][0011235e] 55 push ebp

>>> [0000134f][0011235a][0011235e] 8bec mov ebp,esp

>>> [00001351][00112356][0000134e] 684e130000 push 0000134e

>>> [00001356][00112352][0000135b] e893fbffff call 00000eee

>>> T: Infinitely Recursive Simulation Detected Simulation Stopped

>>>

>>> [0000138b][001022be][00000000] 83c404 add esp,+04

>>> [0000138e][001022be][00000000] 85c0 test eax,eax

>>> [00001390][001022be][00000000] 740f jz 000013a1

>>> [000013a1][001022ba][0000051f] 681f050000 push 0000051f

>>> [000013a6][001022ba][0000051f] e8b3f1ffff call 0000055e

>>> Does not halt

>>> [000013ab][001022be][00000000] 83c404 add esp,+04

>>> [000013ae][001022be][00000000] 33c0 xor eax,eax

>>> [000013b0][001022c2][00000018] 5d pop ebp

>>> [000013b1][001022c6][00000000] c3 ret

>>> Number of Instructions Executed(539) == 8 Pages

>

> As nearly as I can tell this is all what I called boilerplate. Essentially

> no substantial content.

>

> If you have a computer program that shows what you claim show

> your complete code and we can check its validity. No programmer

> is competent to pass a definitive judgement baout his own work.

The above execution trace of simulating halt decider T(Strachey_P2)

proves that T correctly predicts that its correct and complete x86

emulation of its input would never reach the "ret" instruction of this

input. This allows T to correctly reject Strachey_P2 as non-halting.

Anyone having these required prerequisites can verify the above

paragraph without seeing the source-code.

To fully understand this paper a software engineer must be an expert in:

verify the above paragraph even after seeing the source-code because

they will not be able to understand what the halt decider is doing

unless they know the x86 language quite well.

The code requires more refactoring before it is clean enough for

publication.

I updated the original x86 emulator so that

(1) It compiles under Windows as well as Linux. 16390 source-code lines.

(2) One of its original functions can disassemble or simulate its input

depending on a boolean flag.

(3) The COFF output of the the Microsoft C compiler can be directly

executed. (contained in Read_COFF_Object.h). 924 source-code lines.

The x86utm operation system is in x86utm.cpp

2038 source-code lines.

The various halt deciders and their sample input is in Halt7.c

638 source-code lines.

> On Saturday, July 9, 2022 at 6:16:37 AM UTC-7, olcott wrote:

>> On 7/8/2022 5:48 PM, olcott wrote:

>>> On 7/8/2022 1:09 AM, dklei...@gmail.com wrote:

>>>> On Thursday, July 7, 2022 at 9:48:17 PM UTC-7, olcott wrote:

>>>>> On 7/7/2022 11:35 PM, dklei...@gmail.com wrote:

>>>>>

>>>>>> int Strachey_P(void) {

>>>>>> if (T(&Strachey_P)) return 1;

>>>>>> else return 0; }

>>>>>>

>>>>>> int main() {

>>>>>> if (T(&Strachey_P)) Output("Halts");

>>>>>> else Output ("Does not halt");}

>>>>>>

>>>>>> Without the definition of T this is just boiler plate.

>>>>>

>>>>> Yours is incorrect:

>>>>

>>>> How? I assume C89.
>>>>> On 7/7/2022 11:35 PM, dklei...@gmail.com wrote:

>>>>>

>>>>>> int Strachey_P(void) {

>>>>>> if (T(&Strachey_P)) return 1;

>>>>>> else return 0; }

>>>>>>

>>>>>> int main() {

>>>>>> if (T(&Strachey_P)) Output("Halts");

>>>>>> else Output ("Does not halt");}

>>>>>>

>>>>>> Without the definition of T this is just boiler plate.

>>>>>

>>>>> Yours is incorrect:

>>>>

>>>

>>> typedef void (*ptr)();

>>>

>>> int Strachey_P2(void) {

>>> if (T(&Strachey_P2)) return 1;

>>> else return 0; }

>>>

>>> int main()

>>> {

>>> if (T(Strachey_P2)) OutputString("Halts\n");
>>>

>>> int main()

>>> {

>>> else OutputString("Does not halt\n");

>>> }

>>>

>>> _Strachey_P2()

>>> [0000134e](01) 55 push ebp

>>> [0000134f](02) 8bec mov ebp,esp

>>> [00001351](05) 684e130000 push 0000134e

>>> [00001356](05) e893fbffff call 00000eee

>>> [0000135b](03) 83c404 add esp,+04

>>> [0000135e](02) 85c0 test eax,eax

>>> [00001360](02) 7409 jz 0000136b

>>> [00001362](05) b801000000 mov eax,00000001

>>> [00001367](02) eb04 jmp 0000136d

>>> [00001369](02) eb02 jmp 0000136d

>>> [0000136b](02) 33c0 xor eax,eax

>>> [0000136d](01) 5d pop ebp

>>> [0000136e](01) c3 ret

>>> Size in bytes:(0033) [0000136e]

>>>

>>> _main()

>>> [0000137e](01) 55 push ebp

>>> [0000137f](02) 8bec mov ebp,esp

>>> [00001381](05) 684e130000 push 0000134e

>>> [00001386](05) e863fbffff call 00000eee

>>> [0000138b](03) 83c404 add esp,+04

>>> [0000138e](02) 85c0 test eax,eax

>>> [00001390](02) 740f jz 000013a1

>>> [00001392](05) 6817050000 push 00000517

>>> [00001397](05) e8c2f1ffff call 0000055e

>>> [0000139c](03) 83c404 add esp,+04

>>> [0000139f](02) eb0d jmp 000013ae

>>> [000013a1](05) 681f050000 push 0000051f

>>> [000013a6](05) e8b3f1ffff call 0000055e

>>> [000013ab](03) 83c404 add esp,+04

>>> [000013ae](02) 33c0 xor eax,eax

>>> [000013b0](01) 5d pop ebp

>>> [000013b1](01) c3 ret

>>> Size in bytes:(0052) [000013b1]

>>>

>>> machine stack stack machine assembly

>>> address address data code language

>>> ======== ======== ======== ========= =============

>>> [0000137e][001022be][00000000] 55 push ebp
>>> machine stack stack machine assembly

>>> address address data code language

>>> ======== ======== ======== ========= =============

>>> [0000137f][001022be][00000000] 8bec mov ebp,esp

>>> [00001381][001022ba][0000134e] 684e130000 push 0000134e

>>> [00001386][001022b6][0000138b] e863fbffff call 00000eee

>>>

>>> T: Begin Simulation Execution Trace Stored at:11236a

>>> Address_of_T:eee

>>> [0000134e][0011235a][0011235e] 55 push ebp

>>> [0000134f][0011235a][0011235e] 8bec mov ebp,esp

>>> [00001351][00112356][0000134e] 684e130000 push 0000134e

>>> [00001356][00112352][0000135b] e893fbffff call 00000eee

>>> T: Infinitely Recursive Simulation Detected Simulation Stopped

>>>

>>> [0000138b][001022be][00000000] 83c404 add esp,+04

>>> [0000138e][001022be][00000000] 85c0 test eax,eax

>>> [00001390][001022be][00000000] 740f jz 000013a1

>>> [000013a1][001022ba][0000051f] 681f050000 push 0000051f

>>> [000013a6][001022ba][0000051f] e8b3f1ffff call 0000055e

>>> Does not halt

>>> [000013ab][001022be][00000000] 83c404 add esp,+04

>>> [000013ae][001022be][00000000] 33c0 xor eax,eax

>>> [000013b0][001022c2][00000018] 5d pop ebp

>>> [000013b1][001022c6][00000000] c3 ret

>>> Number of Instructions Executed(539) == 8 Pages

>

> As nearly as I can tell this is all what I called boilerplate. Essentially

> no substantial content.

>

> If you have a computer program that shows what you claim show

> your complete code and we can check its validity. No programmer

> is competent to pass a definitive judgement baout his own work.

The above execution trace of simulating halt decider T(Strachey_P2)

proves that T correctly predicts that its correct and complete x86

emulation of its input would never reach the "ret" instruction of this

input. This allows T to correctly reject Strachey_P2 as non-halting.

Anyone having these required prerequisites can verify the above

paragraph without seeing the source-code.

To fully understand this paper a software engineer must be an expert in:

(a) The C programming language.

(b) The x86 programming language.

(c) Exactly how C translates into x86 (how C function calls are

implemented in x86).

(d) The ability to recognize infinite recursion at the x86 assembly

language level.

Anyone not having these required prerequisites will not be able to
(b) The x86 programming language.

(c) Exactly how C translates into x86 (how C function calls are

implemented in x86).

(d) The ability to recognize infinite recursion at the x86 assembly

language level.

verify the above paragraph even after seeing the source-code because

they will not be able to understand what the halt decider is doing

unless they know the x86 language quite well.

The code requires more refactoring before it is clean enough for

publication.

I updated the original x86 emulator so that

(1) It compiles under Windows as well as Linux. 16390 source-code lines.

(2) One of its original functions can disassemble or simulate its input

depending on a boolean flag.

(3) The COFF output of the the Microsoft C compiler can be directly

executed. (contained in Read_COFF_Object.h). 924 source-code lines.

The x86utm operation system is in x86utm.cpp

2038 source-code lines.

The various halt deciders and their sample input is in Halt7.c

638 source-code lines.

Jul 9, 2022, 3:06:25 PMJul 9

to

T(x) is shown to either be incorrect in the case of x = Strachey_P2 or

that T isn't actually the claimed pure function.

The likely error is that it does the incorrect assuption that when

Strachey_P2 calls T(&Strachey_P2) that it assumes that this T will not

aborts its own emultion of its input, when it is shown that T will.

Thus, either T is incorrect about the behavior of this T, or T actually

does have different behavior when deciding on this input, and thus is

proved not to be an actual computation aka a Pure Function.

Note, your claim that T(&Strachey_P2) not reflecting the behavior of

Strachey_P2() just shows that something is defined incorrectly, since

that is how YOU have defined Strachey_P2 to ask exactly that question.

Simple inspection sees that this is true, as if we use the knowledge

that T(&Strachey_P2) returns 0 as claimed, and that T is a pure function

so ALWAYS behaves the same for the same input, then Strachey_P2 must

call T(Strachey_P2), get that 0 return, at which point it will return 1.

The ONLY way for Strachey_P2 to be non-halting is if T is non-halting

(easily provable since Strachey_P2 has NO instructions that don't

progress farther except for inside T) and thus for T to say Strachey_P2

is non-halting is to say that in some condition T is non-halting and

thus fails to meet its requirements.

Jul 13, 2022, 3:37:13 PMJul 13

to

On 7/13/2022 1:03 PM, Paul N wrote:

> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:

>> On 7/13/2022 10:02 AM, Paul N wrote:

>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.

>>>

>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:

>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*

>>>>

>>>> I rewrote this question so that a software engineer of ordinary skill

>>>> can easily verify that the simulated P does call H in what is

>>>> essentially infinite recursion. **This simplification is the result of

>>>> an extensive review (23 emails) by a leading computer scientist over the

>>>> weekend.**

>>>

>>>> Does H(P,P) correctly determine the halt status of the halting problem's

>>>> pathological input?

>>>

>>>> The following H and P have the above specified pathological relationship

>>>> to each other.

>>>>

>>>> typedef void (*ptr)();

>>>> int H(ptr p, ptr i);

>>>>

>>>> void P(ptr x)

>>>> }

>>>>

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

>>>

>>> Thus it is an incorrect assessment, as we'll see below.

>>>

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

>>>

>>> Again, emphasis on "actual behaviour".

>>>

>>>> *Then (by logical necessity) this is understood to implement that*

>>>> normally, correctly rejects this input as non-halting.

>>>

>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.

>>>

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

>>>

>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.

>>>

>>>> This proves that H(P,P) correctly predicts that its correctly simulated

>>>> input would never terminate normally.

>>>

>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.

>> Welcome back.

>>

>> When H(P,P) correctly simulates its input this is the ultimate measure

>> of the actual behavior specified by this input.

>

> No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.

>

It is an easily verified fact that H(P,P) correctly simulates its input

to everyone having sufficient knowledge of the x86 assembly language

which currently seems to be hardy no one besides me. Back in the 1986

when I began my career about 10% of all programmers had familiarity

with the x86 language. This is the language that MSDOS and versions

of MS Windows prior to Windows NT were written in. Windows NT switched

to mostly C/C++.

The 23 emails that I had with a leading computer scientist made that

very clear. Because of this I re-framed my explanation so that any

expert C programmer that totally understands infinite recursion would be

able to see that infinitely nested simulation is essentially the same

thing.

The next important point that requires one to have top software

engineering skills that allowed me to transform H into a pure thus

computable function: Infinitely nested simulation can be detected the

first time that the simulated input calls the simulator with its same

arguments. Infinite recursion requires seeing two such calls in a row.

This change allowed me to discard the need for static local memory and

do everything in local memory.

>> A security guard at the front door is only required to validate people

>> coming in the front door the actual behavior of the actual input to H(P,P).

>>

>> This same security guard is not required to validate people coming in

>> the back door the direct execution of P(P). Unless a computation is

>> specified as an actual input to H it is not in the domain of the

>> computable function that H implements.

>

> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.

No this a very long standing misconception. H is required to determine

whether or not its correct simulation of its input would ever reach the

normal termination of this input.

Since no one ever bothered to think through the application of a

simulating halt decider to the HP's impossible inputs they always stated

the requirements incorrectly never realizing their mistake.

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.

In the H/P concrete example it is easily proven that the actual behavior

of the actual input to H(P,P) is not the behavior of the directly

executed P(P). The best proof of this is the x86 execution trace of each

that precisely corresponds to what the x86 source code of P specifies.

From this is is obvious that the correctly simulated P cannot possibly

terminate normally and the executed P(P) halts.

Those lacking knowledge of the x86 language can understand that this

first halt deciding principle is necessarily correct:

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

And this second halt deciding principle follows from the first one by

logical necessity.

*Then (by logical necessity) this implements that principle*

normally, correctly rejects this input as non-halting.

>

> If a program M would halt given input X, then H(M, X) is required to be non-zero.

> If a program M would not halt given input X, then H(M, X) is required to be zero.

>

This is a misconception that can only be true if the halt decider is

required to report on something besides the actual behavior of its

actual input.

The ultimate measure of the actual behavior of the actual input is the

provable correct simulation of this input by the simulating halt decider.

To assume that this behavior must be the same as the directly executed

P(P) after it has been conclusively proven to not be that same as an

established fact is at least a little nutty.

That people unequivocally state that I must be wrong entirely on the

basis that they lack sufficient understanding of the x86 language to

understand my proof is a worst case example of the ad ignorantiam logic

error.

> If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.

>

> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.

>

> When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.

>

>>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:

>>>

>>> A) H(P, P) returns 0 and P(P) terminates.

>>> B) H(P, P) returns non-zero and P(P) terminates.

>>> C) H(P, P) returns 0 and P(P) does not terminate.

>>> D) H(P, P) returns non-zero and P(P) does not terminate.

>>>

>>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.

>

>> A1) H(P, P) returns 0 because it correctly determines that the input

>> that it correctly simulates would never terminate normally.

>

> No, that is not a correct answer. You have said numerous times that P(P) terminates.

>

>> A2) Directly executed P(P) halts because of (A)

> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:

>> On 7/13/2022 10:02 AM, Paul N wrote:

>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.

>>>

>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:

>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*

>>>>

>>>> I rewrote this question so that a software engineer of ordinary skill

>>>> can easily verify that the simulated P does call H in what is

>>>> essentially infinite recursion. **This simplification is the result of

>>>> an extensive review (23 emails) by a leading computer scientist over the

>>>> weekend.**

>>>

>>>> Does H(P,P) correctly determine the halt status of the halting problem's

>>>> pathological input?

>>>

>>>> The following H and P have the above specified pathological relationship

>>>> to each other.

>>>>

>>>> typedef void (*ptr)();

>>>> int H(ptr p, ptr i);

>>>>

>>>> void P(ptr x)

>>>> {

>>>> if (H(x, x))

>>>> HERE: goto HERE;

>>>> return;
>>>> if (H(x, x))

>>>> HERE: goto HERE;

>>>> }

>>>>

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

>>>

>>> Thus it is an incorrect assessment, as we'll see below.

>>>

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

>>>

>>> Again, emphasis on "actual behaviour".

>>>

>>>> *Then (by logical necessity) this is understood to implement that*

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

>>>

>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.

>>>

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

>>>

>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.

>>>

>>>> This proves that H(P,P) correctly predicts that its correctly simulated

>>>> input would never terminate normally.

>>>

>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.

>> Welcome back.

>>

>> When H(P,P) correctly simulates its input this is the ultimate measure

>> of the actual behavior specified by this input.

>

> No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.

>

It is an easily verified fact that H(P,P) correctly simulates its input

to everyone having sufficient knowledge of the x86 assembly language

which currently seems to be hardy no one besides me. Back in the 1986

when I began my career about 10% of all programmers had familiarity

with the x86 language. This is the language that MSDOS and versions

of MS Windows prior to Windows NT were written in. Windows NT switched

to mostly C/C++.

The 23 emails that I had with a leading computer scientist made that

very clear. Because of this I re-framed my explanation so that any

expert C programmer that totally understands infinite recursion would be

able to see that infinitely nested simulation is essentially the same

thing.

The next important point that requires one to have top software

engineering skills that allowed me to transform H into a pure thus

computable function: Infinitely nested simulation can be detected the

first time that the simulated input calls the simulator with its same

arguments. Infinite recursion requires seeing two such calls in a row.

This change allowed me to discard the need for static local memory and

do everything in local memory.

>> A security guard at the front door is only required to validate people

>> coming in the front door the actual behavior of the actual input to H(P,P).

>>

>> This same security guard is not required to validate people coming in

>> the back door the direct execution of P(P). Unless a computation is

>> specified as an actual input to H it is not in the domain of the

>> computable function that H implements.

>

> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.

No this a very long standing misconception. H is required to determine

whether or not its correct simulation of its input would ever reach the

normal termination of this input.

Since no one ever bothered to think through the application of a

simulating halt decider to the HP's impossible inputs they always stated

the requirements incorrectly never realizing their mistake.

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.

In the H/P concrete example it is easily proven that the actual behavior

of the actual input to H(P,P) is not the behavior of the directly

executed P(P). The best proof of this is the x86 execution trace of each

that precisely corresponds to what the x86 source code of P specifies.

From this is is obvious that the correctly simulated P cannot possibly

terminate normally and the executed P(P) halts.

Those lacking knowledge of the x86 language can understand that this

first halt deciding principle is necessarily correct:

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

And this second halt deciding principle follows from the first one by

logical necessity.

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

>

> If a program M would halt given input X, then H(M, X) is required to be non-zero.

> If a program M would not halt given input X, then H(M, X) is required to be zero.

>

This is a misconception that can only be true if the halt decider is

required to report on something besides the actual behavior of its

actual input.

The ultimate measure of the actual behavior of the actual input is the

provable correct simulation of this input by the simulating halt decider.

To assume that this behavior must be the same as the directly executed

P(P) after it has been conclusively proven to not be that same as an

established fact is at least a little nutty.

That people unequivocally state that I must be wrong entirely on the

basis that they lack sufficient understanding of the x86 language to

understand my proof is a worst case example of the ad ignorantiam logic

error.

> If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.

>

> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.

>

> When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.

>

>>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:

>>>

>>> A) H(P, P) returns 0 and P(P) terminates.

>>> B) H(P, P) returns non-zero and P(P) terminates.

>>> C) H(P, P) returns 0 and P(P) does not terminate.

>>> D) H(P, P) returns non-zero and P(P) does not terminate.

>>>

>>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.

>

>> A1) H(P, P) returns 0 because it correctly determines that the input

>> that it correctly simulates would never terminate normally.

>

> No, that is not a correct answer. You have said numerous times that P(P) terminates.

>

>> A2) Directly executed P(P) halts because of (A)

Jul 13, 2022, 4:51:25 PMJul 13

to

On 7/13/2022 3:47 PM, wij wrote:

> Halting problem https://en.wikipedia.org/wiki/Halting_problem

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

>

> The property that an arbitrary program P will finish running or not is determined by

> running P as an independent program

Because that would require that a halt decider must sometimes make its

halt status decision on a basis other than the actual behavior of its

actual input that long standing misconception has been refuted.

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

>

> The property that an arbitrary program P will finish running or not is determined by

> running P as an independent program

Because that would require that a halt decider must sometimes make its

halt status decision on a basis other than the actual behavior of its

actual input that long standing misconception has been refuted.

Jul 13, 2022, 7:29:37 PMJul 13

to

since BUY DEFINITION H(P,P) must be being asked about the behavior of

P(P) since that is the question that P is supposed to be asking H.

Since H's simulation of its input doesn't match the behavior of the

actual machine it is supposed to be simulating, it is incorrect.

THAT IS PURELY FROM THE DEFINTION OF CORRECT.

>

> The 23 emails that I had with a leading computer scientist made that

> very clear. Because of this I re-framed my explanation so that any

> expert C programmer that totally understands infinite recursion would be

> able to see that infinitely nested simulation is essentially the same

> thing.

be a machine that did a pure simulation of its input until it actually

proved that its input doesn't halt, then yes, by that definition P(P)

will be non-halting, but also by that definiton H(P,P) can NEVER abort

its simulation of the input, becuase it can NEVER actually prove the

input to be non-halting, because if it ever thinks it has and returns 0,

then the input becomes halting.

If you made that claim while at the same time your H ACTUALLY did the

aborting, then you LIED, and his "support" is invalid.

>

> The next important point that requires one to have top software

> engineering skills that allowed me to transform H into a pure thus

> computable function: Infinitely nested simulation can be detected the

> first time that the simulated input calls the simulator with its same

> arguments. Infinite recursion requires seeing two such calls in a row.

> This change allowed me to discard the need for static local memory and

> do everything in local memory.

>

fact that the simulator is NOT "just" a pure simulator, but is

conditional on the behavior of the simulation, and WILL (per your claim)

abort this simulation and return 0.

>>> A security guard at the front door is only required to validate people

>>> coming in the front door the actual behavior of the actual input to

>>> H(P,P).

>>>

>>> This same security guard is not required to validate people coming in

>>> the back door the direct execution of P(P). Unless a computation is

>>> specified as an actual input to H it is not in the domain of the

>>> computable function that H implements.

>>

>> H takes two arguments. The first is a program to be considered and the

>> second is the input that could be supplied to that program. H is

>> required to decide, correctly, whether the program would halt given

>> that input, ie whether M(X) would halt.

>

> No this a very long standing misconception. H is required to determine

> whether or not its correct simulation of its input would ever reach the

> normal termination of this input.

behaivor of the program and input that its input represents. The Halting

Problem NEVER mentions simulation of its inputs.

You just are showing you don't understand the basics of the proof you

are talking about.

>

> Since no one ever bothered to think through the application of a

> simulating halt decider to the HP's impossible inputs they always stated

> the requirements incorrectly never realizing their mistake.

Decider, must follow exactly the same definiton.

YOU FAIL.

>

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

on the behavior it can determine, but MUST compute the mapping of the

DEFINED FUNCTION to be correct. Halting is DEFINED based on the

>

> In the H/P concrete example it is easily proven that the actual behavior

> of the actual input to H(P,P) is not the behavior of the directly

> executed P(P). The best proof of this is the x86 execution trace of each

> that precisely corresponds to what the x86 source code of P specifies.

Then H or P are not defined correctly.
> In the H/P concrete example it is easily proven that the actual behavior

> of the actual input to H(P,P) is not the behavior of the directly

> executed P(P). The best proof of this is the x86 execution trace of each

> that precisely corresponds to what the x86 source code of P specifies.

P is DEFINED to ask H about itself with its input, if H(P,P) doesn't

represent that question, then YOU did something wrong in translating it

to your notation.

> From this is is obvious that the correctly simulated P cannot possibly

> terminate normally and the executed P(P) halts.

returns 0, and will not halt otherwise.

Yes, you can prove that H can never simulate its input to that point to

prove that P(P) is halting, but once H aborts its simulation, it has

ceased to be a source of truth for the behavior of the input, since the

actual behavior of the machine it represents continues, and the CORRECT

simulation will show that it halts.

>

> Those lacking knowledge of the x86 language can understand that this

> first halt deciding principle is necessarily correct:

>

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

P(P) and P(P) Halts if H(P,P) returns 0, so H(P,P) returning 0 is not

correct.

The ONLY way for your H(P,P) to not represent P(P) would be for H to say

that because you have defined your "input P" to only be the byte of

assembly of P itsef, that H rejects the input as invalid as not being a

complete program, which just shows that P was defined incorrectly.

>

> And this second halt deciding principle follows from the first one by

> logical necessity.

>

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

>

this simulate input would never terminate, then H(P,P) will never

return, as such an H will never actually reach (in finite time) a state

that it can prove in non-halting, because ANY such state in the

simulation that it might think would be non-halting, if programmed into

H as a non-halting pattern, makes P(P) halting, and thus isn't a correct

pattern.

>>

>> If a program M would halt given input X, then H(M, X) is required to

>> be non-zero.

>> If a program M would not halt given input X, then H(M, X) is required

>> to be zero.

>>

>

> This is a misconception that can only be true if the halt decider is

> required to report on something besides the actual behavior of its

> actual input.

>

> The ultimate measure of the actual behavior of the actual input is the

> provable correct simulation of this input by the simulating halt decider.

CORRECTLY prove that the input never halts, which means that the same

input when given to a different simulator that actually never does

abort, will never halt.

>

> To assume that this behavior must be the same as the directly executed

> P(P) after it has been conclusively proven to not be that same as an

> established fact is at least a little nutty.

on false premises so is unsound.

>

> That people unequivocally state that I must be wrong entirely on the

> basis that they lack sufficient understanding of the x86 language to

> understand my proof is a worst case example of the ad ignorantiam logic

> error.

ACTUAL Halting problem, which ONLY references the behavior of the actual

machine.

All you are doing is proving you don't understand the first thing about

requirments.

Jul 13, 2022, 8:10:56 PMJul 13

to

On 7/13/2022 4:11 PM, wij wrote:

> Because we often encountered a problem to know whether a 'independent' running

> program P will halt or not, therefore, this is an interested problem.

> We don't have such a problem asking H(P,P), the P 'simulated' by H halt or not.

reader and report on the behavior of a computation that only exists in

the minds of the readers and its not the same computation that is

specified by its inputs.

That is goofy and nutty and crazy.

> program P will halt or not, therefore, this is an interested problem.

> We don't have such a problem asking H(P,P), the P 'simulated' by H halt or not.

>

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.

Everyone's rebuttal to this is that the halt decider must be a mind
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.

reader and report on the behavior of a computation that only exists in

the minds of the readers and its not the same computation that is

specified by its inputs.

That is goofy and nutty and crazy.

Jul 13, 2022, 9:29:20 PMJul 13

to

or P is defined incorrectly.

ALL the information needed to compute that IS in the input, so it is "in

bounds" to ask H to decide on it.

The fact that the answer isn't computable (which is what the Halting

Theorem is actually saying) means that it is actually impossible for H

to compute such a thing.

It isn't requireing H to be a mind reader, it is just asking it to do in

finite time something that turns out can't be always done in finite time.

Being a "Mind Reader" doesn't help. If the computation structure allows

"Mind Reading", the P still can use H and its mind reading power to make

H wrong or non-answering. It is just logically IMPOSSIBLE for H to give

a right answer, which proves that an H that gives a right answer just

doesn't exist

Only if the decider is built with a "more powerful" computation system,

which can do some computation that the thing it is deciding on can't do,

does this proof fail, but we know of no computation system that is "More

Powerful" (by this definition) then a Turing Machine. Other structures

may be orders more efficient, but can't actually compute something that

a Turing can't do.

Jul 15, 2022, 12:26:49 PMJul 15

to

On 7/15/2022 11:17 AM, Paul N wrote:

> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:

>> On 7/15/2022 7:34 AM, Paul N wrote:

>>> On Thursday, July 14, 2022 at 8:56:21 PM UTC+1, olcott wrote:

>>>> On 7/14/2022 6:42 AM, Paul N wrote:

>>>>>>> No, the actual behaviour is the actual behaviour! If H correctly simulates this behaviour then it too will also be the same, but you have said numerous times that it does not correctly simulate the behaviour.

>>>> The latest rewrite of my paper (initially written as a reply to you) can

>>>> be fully understood at the C level with no need to have any access to

>>>> the source-code of H. I will publish all the the source-code very soon,

>>>> yet not until after my work has been validated.

>>>>

>>>> The source-code is correct and complete yet must be refactored to clean

>>>> it up before publication.

>>>> This is also much more clearly shown in the rewrite of my paper that I

>>>> did a few minutes ago. It can now be seen at the C level that the

>>>> simulation of the input to H(P,P) is correct.

>>>>

>>>> It was very easy to see that the simulation of the input to H(P,P) is

>>>> correct by simply matching the execution trace of the simulated P to its

>>>> x86 source code. I annotated the x86 source-code to make this much

>>>> easier for C programmers. I explain line-by-line exactly how the x86

>>>> code corresponds to its C source.

>>>> This would be disrespecting his privacy. The point is that I now have an

>>>> excellent measure that I have improved my words so much that my work is

>>>> not simply rejected out-of-hand without review even by leading computer

>>>> scientists.

>>>> correct measure of the behavior of this program.

>>>>

>>>> If we accept that the behavior of the executed P(P) is the behavior that

>>>> H must report on then we are saying that H must report on the behavior

>>>> that is not the actual behavior of its actual input.

>>>> In the latest revision to my paper it is much more obvious that that

>>>> actual behavior of the actual input is not the same as the behavior of

>>>> the directly executed P(P).

>>>

>>> Did your expert in any way agree that the "actual behaviour" is different from the behaviour when P(P) is directly executed? Have you found anyone at all who agrees with you on this point?

>> At the time my proof was only written in x86 assembly language and he

>> had no knowledge of x86 assembly language Now it can be understood in C.

>>>

>>>> If H is required to report on the behavior of the direct execution of

>>>> P(P) this forces H to report on something besides the actual behavior of

>>>> its actual input.

>>>

>>> Do you accept that if H were required to report on the behaviour of the direct execution of P(P) then it would not be possible to write such an H?

>> That would require H to be a mind reader and report on something other

>> than the actual behavior of its actual input.

>

> There's no mind involved. If P is a computer program then P(P) is perfectly well defined. Either H can work out what it will do, or it can't.

It is like you ask your wife to go to the store and buy "a dozen eggs"

fully expecting her to understand that what you mean by "a dozen eggs"

is {a half gallon of grape juice}. When she gets back with the eggs you

ask her where is the grape juice?

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.

It is common knowledge that a correct simulation of a program is a

correct measure of the behavior of this program.

If we accept that the behavior of the executed P(P) is the behavior that

H must report on then we are saying that H must report on the behavior

that is not the actual behavior of its actual input.

>

>> I spent about three hours in my reply to you, how much time did you

>> spend three minutes?

>>>

>>>> rewritten a few minutes ago to be much easier to understand:

> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:

>> On 7/15/2022 7:34 AM, Paul N wrote:

>>> On Thursday, July 14, 2022 at 8:56:21 PM UTC+1, olcott wrote:

>>>> On 7/14/2022 6:42 AM, Paul N wrote:

>>>>> On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, olcott wrote:

>>>>>> On 7/13/2022 1:03 PM, Paul N wrote:

>>>>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:

>>>>>>>> On 7/13/2022 10:02 AM, Paul N wrote:

>>>>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.

>>>

>>> I see you have now started a new thread on this very subject in both comp.lang.c and comp.lang.c++. You clearly are very rude.
>>>>>> On 7/13/2022 1:03 PM, Paul N wrote:

>>>>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:

>>>>>>>> On 7/13/2022 10:02 AM, Paul N wrote:

>>>>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.

>>>

>>>>>>>

>>>>>> It is an easily verified fact that H(P,P) correctly simulates its input

>>>>>> to everyone having sufficient knowledge of the x86 assembly language

>>>>>> which currently seems to be hardy no one besides me. Back in the 1986

>>>>>> when I began my career about 10% of all programmers had familiarity

>>>>>> with the x86 language. This is the language that MSDOS and versions

>>>>>> of MS Windows prior to Windows NT were written in. Windows NT switched

>>>>>> to mostly C/C++.

>>>>>

>>>>> No it is not. Firstly, you have never posted the code to H so of course we can't verify it.
>>>>>> It is an easily verified fact that H(P,P) correctly simulates its input

>>>>>> to everyone having sufficient knowledge of the x86 assembly language

>>>>>> which currently seems to be hardy no one besides me. Back in the 1986

>>>>>> when I began my career about 10% of all programmers had familiarity

>>>>>> with the x86 language. This is the language that MSDOS and versions

>>>>>> of MS Windows prior to Windows NT were written in. Windows NT switched

>>>>>> to mostly C/C++.

>>>>>

>>>> The latest rewrite of my paper (initially written as a reply to you) can

>>>> be fully understood at the C level with no need to have any access to

>>>> the source-code of H. I will publish all the the source-code very soon,

>>>> yet not until after my work has been validated.

>>>>

>>>> The source-code is correct and complete yet must be refactored to clean

>>>> it up before publication.

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

>>>>> Furthermore, you yourself claim that the simulation gives different results from the actual code (you even describe this as "provably" on occasion) so you yourself do not believe that H(P,P) correctly simulates its input.
>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

>>>> This is also much more clearly shown in the rewrite of my paper that I

>>>> did a few minutes ago. It can now be seen at the C level that the

>>>> simulation of the input to H(P,P) is correct.

>>>>

>>>> It was very easy to see that the simulation of the input to H(P,P) is

>>>> correct by simply matching the execution trace of the simulated P to its

>>>> x86 source code. I annotated the x86 source-code to make this much

>>>> easier for C programmers. I explain line-by-line exactly how the x86

>>>> code corresponds to its C source.

>>>>>

>>>>>> The 23 emails that I had with a leading computer scientist made that

>>>>>> very clear. Because of this I re-framed my explanation so that any

>>>>>> expert C programmer that totally understands infinite recursion would be

>>>>>> able to see that infinitely nested simulation is essentially the same

>>>>>> thing.

>>>>>

>>>>> It might move the conversation on if you showed us what the computer scientist said - most helpfully if you quoted verbatim, but you could paraphrase if you're worried about confidentiality or the like. I take it there was more to it than them saying why you were wrong, and you saying that they didn't understand?
>>>>>> The 23 emails that I had with a leading computer scientist made that

>>>>>> very clear. Because of this I re-framed my explanation so that any

>>>>>> expert C programmer that totally understands infinite recursion would be

>>>>>> able to see that infinitely nested simulation is essentially the same

>>>>>> thing.

>>>>>

>>>> This would be disrespecting his privacy. The point is that I now have an

>>>> excellent measure that I have improved my words so much that my work is

>>>> not simply rejected out-of-hand without review even by leading computer

>>>> scientists.

>>>>>> The next important point that requires one to have top software

>>>>>> engineering skills that allowed me to transform H into a pure thus

>>>>>> computable function: Infinitely nested simulation can be detected the

>>>>>> first time that the simulated input calls the simulator with its same

>>>>>> arguments. Infinite recursion requires seeing two such calls in a row.

>>>>>> This change allowed me to discard the need for static local memory and

>>>>>> do everything in local memory.

>>>>>>>> A security guard at the front door is only required to validate people

>>>>>>>> coming in the front door the actual behavior of the actual input to H(P,P).

>>>>>>>>

>>>>>>>> This same security guard is not required to validate people coming in

>>>>>>>> the back door the direct execution of P(P). Unless a computation is

>>>>>>>> specified as an actual input to H it is not in the domain of the

>>>>>>>> computable function that H implements.

>>>>>>>

>>>>>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.

>>>>>

>>>>>> No this a very long standing misconception. H is required to determine

>>>>>> whether or not its correct simulation of its input would ever reach the

>>>>>> normal termination of this input.

>>>>>

>>>>> No, what I have said is right. You are the one bringing in ideas about simulation.
>>>>>> engineering skills that allowed me to transform H into a pure thus

>>>>>> computable function: Infinitely nested simulation can be detected the

>>>>>> first time that the simulated input calls the simulator with its same

>>>>>> arguments. Infinite recursion requires seeing two such calls in a row.

>>>>>> This change allowed me to discard the need for static local memory and

>>>>>> do everything in local memory.

>>>>>>>> A security guard at the front door is only required to validate people

>>>>>>>> coming in the front door the actual behavior of the actual input to H(P,P).

>>>>>>>>

>>>>>>>> This same security guard is not required to validate people coming in

>>>>>>>> the back door the direct execution of P(P). Unless a computation is

>>>>>>>> specified as an actual input to H it is not in the domain of the

>>>>>>>> computable function that H implements.

>>>>>>>

>>>>>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.

>>>>>

>>>>>> No this a very long standing misconception. H is required to determine

>>>>>> whether or not its correct simulation of its input would ever reach the

>>>>>> normal termination of this input.

>>>>>

>>>>>

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

>>>> It is common knowledge that a correct simulation of a program is a
>>>> 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.

>>>> correct measure of the behavior of this program.

>>>>

>>>> If we accept that the behavior of the executed P(P) is the behavior that

>>>> H must report on then we are saying that H must report on the behavior

>>>> that is not the actual behavior of its actual input.

>>>>>> Since no one ever bothered to think through the application of a

>>>>>> simulating halt decider to the HP's impossible inputs they always stated

>>>>>> the requirements incorrectly never realizing their mistake.

>>>>>

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

>>>>>

>>>>> Yes.
>>>>>> simulating halt decider to the HP's impossible inputs they always stated

>>>>>> the requirements incorrectly never realizing their mistake.

>>>>>

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

>>>>>

>>>>>

>>>>>> In the H/P concrete example it is easily proven that the actual behavior

>>>>>> of the actual input to H(P,P) is not the behavior of the directly

>>>>>> executed P(P). The best proof of this is the x86 execution trace of each

>>>>>> that precisely corresponds to what the x86 source code of P specifies.

>>>>>

>>>>> You've included the word "actual" twice in that sentence and yet you still seem to think that the actual behaviour is not what really happens. How many "actual"s do you need?
>>>>>> In the H/P concrete example it is easily proven that the actual behavior

>>>>>> of the actual input to H(P,P) is not the behavior of the directly

>>>>>> executed P(P). The best proof of this is the x86 execution trace of each

>>>>>> that precisely corresponds to what the x86 source code of P specifies.

>>>>>

>>>>>

>>>>>> From this is is obvious that the correctly simulated P cannot possibly

>>>>>> terminate normally and the executed P(P) halts.

>>>>>

>>>>> If P(P) halts then a correct simulation of it will also halt.
>>>>>> From this is is obvious that the correctly simulated P cannot possibly

>>>>>> terminate normally and the executed P(P) halts.

>>>>>

>>>> In the latest revision to my paper it is much more obvious that that

>>>> actual behavior of the actual input is not the same as the behavior of

>>>> the directly executed P(P).

>>>

>>> Did your expert in any way agree that the "actual behaviour" is different from the behaviour when P(P) is directly executed? Have you found anyone at all who agrees with you on this point?

>> At the time my proof was only written in x86 assembly language and he

>> had no knowledge of x86 assembly language Now it can be understood in C.

>>>

>>>> If H is required to report on the behavior of the direct execution of

>>>> P(P) this forces H to report on something besides the actual behavior of

>>>> its actual input.

>>>

>>> Do you accept that if H were required to report on the behaviour of the direct execution of P(P) then it would not be possible to write such an H?

>> That would require H to be a mind reader and report on something other

>> than the actual behavior of its actual input.

>

> There's no mind involved. If P is a computer program then P(P) is perfectly well defined. Either H can work out what it will do, or it can't.

It is like you ask your wife to go to the store and buy "a dozen eggs"

fully expecting her to understand that what you mean by "a dozen eggs"

is {a half gallon of grape juice}. When she gets back with the eggs you

ask her where is the grape juice?

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.

correct measure of the behavior of this program.

If we accept that the behavior of the executed P(P) is the behavior that

H must report on then we are saying that H must report on the behavior

that is not the actual behavior of its actual input.

>

>> I spent about three hours in my reply to you, how much time did you

>> spend three minutes?

>>>

>>>> rewritten a few minutes ago to be much easier to understand:

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

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

Jul 16, 2022, 8:18:34 PMJul 16

to

On 7/16/2022 10:54 AM, Mike Terry wrote:

> On 16/07/2022 12:23, Paul N wrote:

>> You haven't said in what way a "mind" is involved in the direct

>> execution of P(P).

>>

>> about the actual behaviour of P(P) I mean what actually happens when

>> P(P) is executed. That's what the words "actual" and "behaviour" mean.

>>

>> You are using the words "actual behavior" to mean something else which

>> is clearly different. It seems to relate to some sort of simulator,

>> which you simultaneously claim to be correct while acknowledging it

>> produces different results from executing P(P) directly.

>>

>> Can you tell us if that "actual behavior" does actually happen in any

>> circumstances, or is it (despite the name) just a theoretical thing?

>> your own simulator is incorrect.

>

> PO's simulation is correct at the individual instruction level. His H

> steps the simulation forward a number of steps, and each of those steps

> exactly matches the P(P) calculation steps. At some point before the

> final P RET instruction, his H decides to stop stepping (for whatever

> reason), so H's simulation is *incomplete*.

>

This review was very helpful thanks.

> That is the only sense in which P(P) and "the simulated input to H(P,P)"

> differ - H simply stops simulating before P(P) terminates.

*If you carefully examine this you will see that the simulated P cannot*

*possibly ever terminate normally by reaching its "return" instruction*

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)

(3) With no instructions in P preceding its invocation of H(P,P) that

could escape repeated simulations.

The above shows that the simulated P cannot possibly (reachs it “return”

instruction and) terminate normally. H(P,P) simulates its input then P

calls H(P,P) to simulate itself again. When H sees that this otherwise

infinitely nested simulation would never end it aborts its simulation of

P and rejects P as non-halting.

> On 16/07/2022 12:23, Paul N wrote:

>> execution of P(P).

>>

>>> It is like you ask your wife to go to the store and buy "a dozen eggs"

>>> fully expecting her to understand that what you mean by "a dozen eggs"

>>> is {a half gallon of grape juice}. When she gets back with the eggs you

>>> ask her where is the grape juice?

>>

>> No, you are the one who is twisting the meaning of words. When I talk
>>> fully expecting her to understand that what you mean by "a dozen eggs"

>>> is {a half gallon of grape juice}. When she gets back with the eggs you

>>> ask her where is the grape juice?

>>

>> about the actual behaviour of P(P) I mean what actually happens when

>> P(P) is executed. That's what the words "actual" and "behaviour" mean.

>>

>> You are using the words "actual behavior" to mean something else which

>> is clearly different. It seems to relate to some sort of simulator,

>> which you simultaneously claim to be correct while acknowledging it

>> produces different results from executing P(P) directly.

>>

>> Can you tell us if that "actual behavior" does actually happen in any

>> circumstances, or is it (despite the name) just a theoretical thing?

>>

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

>>

>> Yes, where the actual behaviour is the behaviour that actually happens.
>>> 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.

>>

>>

>>> It is common knowledge that a correct simulation of a program is a

>>> correct measure of the behavior of this program.

>>

>> Yes, if the simulation is correct. You've insisted numerous times that
>>> It is common knowledge that a correct simulation of a program is a

>>> correct measure of the behavior of this program.

>>

>> your own simulator is incorrect.

>

> PO's simulation is correct at the individual instruction level. His H

> steps the simulation forward a number of steps, and each of those steps

> exactly matches the P(P) calculation steps. At some point before the

> final P RET instruction, his H decides to stop stepping (for whatever

> reason), so H's simulation is *incomplete*.

>

This review was very helpful thanks.

> That is the only sense in which P(P) and "the simulated input to H(P,P)"

> differ - H simply stops simulating before P(P) terminates.

*If you carefully examine this you will see that the simulated P cannot*

*possibly ever terminate normally by reaching its "return" instruction*

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 it can see that:
return;

}

int main()

{

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

}

(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) that

could escape repeated simulations.

The above shows that the simulated P cannot possibly (reachs it “return”

instruction and) terminate normally. H(P,P) simulates its input then P

calls H(P,P) to simulate itself again. When H sees that this otherwise

infinitely nested simulation would never end it aborts its simulation of

P and rejects P as non-halting.

Jul 16, 2022, 8:38:56 PMJul 16

to

machine and not a simulation.

Note, if H doesn't abort, it fails to be a decider.

If H does abort, it didn't completely and correctly simulate its input,

and a complete and correct simulation of the input WILL Halt.

We only care about the H that you actually are using, so if it aborts,

we need to look at the P that calls that same H that aborts, and since

that H doesn't complete its simulation, we need to test with the actual

machine or another simulator that actually does the complete and correct

simulation, and that one will show that P(P) halts if H(P,P) returns 0.

You basically are showing you don't understand basic requirements.

>

> 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 it 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) that

> could escape repeated simulations.

Jul 16, 2022, 9:19:39 PMJul 16

to

Jul 17, 2022, 1:00:40 PMJul 17

to

On 7/16/2022 2:28 PM, Mike Terry wrote:

> On 16/07/2022 17:40, Richard Damon wrote:

>> But "incomplete" is incorrect if your logic assumes that the

>> simulation not reaching the final state PROVES non-halting.

>

> I don't believe PO thinks that, irrespective of how badly he explains

> things. I think he believes that the simulation would never halt

> *because his never-halting-abort test matched*, NOT simply as a

> consequence of aborting. E.g. he seems to understand that a simulator

> that steps 10 steps then stops regardless, does not imply that the

> simulated computation does not halt.

>

> Although... he doesn't properly understand what halting means,

Halting means terminating normally by reaching the last "return"

instruction of the C function the last "ret" instruction of the x86

translation of this "C" function or the final state of a Turing machine.

*computation that halts* … the Turing machine will halt whenever it

enters a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.

Lexington/Toronto: D. C. Heath and Company.

> On 16/07/2022 17:40, Richard Damon wrote:

>> But "incomplete" is incorrect if your logic assumes that the

>> simulation not reaching the final state PROVES non-halting.

>

> I don't believe PO thinks that, irrespective of how badly he explains

> things. I think he believes that the simulation would never halt

> *because his never-halting-abort test matched*, NOT simply as a

> consequence of aborting. E.g. he seems to understand that a simulator

> that steps 10 steps then stops regardless, does not imply that the

> simulated computation does not halt.

>

> Although... he doesn't properly understand what halting means,

Halting means terminating normally by reaching the last "return"

instruction of the C function the last "ret" instruction of the x86

translation of this "C" function or the final state of a Turing machine.

*computation that halts* … the Turing machine will halt whenever it

enters a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.

Lexington/Toronto: D. C. Heath and Company.

Jul 17, 2022, 1:06:36 PMJul 17

to

On 7/17/22 1:00 PM, olcott wrote:

> On 7/16/2022 2:28 PM, Mike Terry wrote:

>> On 16/07/2022 17:40, Richard Damon wrote:

>>> But "incomplete" is incorrect if your logic assumes that the

>>> simulation not reaching the final state PROVES non-halting.

>>

>> I don't believe PO thinks that, irrespective of how badly he explains

>> things. I think he believes that the simulation would never halt

>> *because his never-halting-abort test matched*, NOT simply as a

>> consequence of aborting. E.g. he seems to understand that a simulator

>> that steps 10 steps then stops regardless, does not imply that the

>> simulated computation does not halt.

>>

>> Although... he doesn't properly understand what halting means,

>

> Halting means terminating normally by reaching the last "return"

> instruction of the C function the last "ret" instruction of the x86

> translation of this "C" function or the final state of a Turing machine.

>

> *computation that halts* … the Turing machine will halt whenever it

> enters a final state. (Linz:1990:234)

>

> Linz, Peter 1990. An Introduction to Formal Languages and Automata.

> Lexington/Toronto: D. C. Heath and Company.

>

>

Then why isn't the fact that P(P) will reach that when H(P,P) returns 0
> On 7/16/2022 2:28 PM, Mike Terry wrote:

>> On 16/07/2022 17:40, Richard Damon wrote:

>>> But "incomplete" is incorrect if your logic assumes that the

>>> simulation not reaching the final state PROVES non-halting.

>>

>> I don't believe PO thinks that, irrespective of how badly he explains

>> things. I think he believes that the simulation would never halt

>> *because his never-halting-abort test matched*, NOT simply as a

>> consequence of aborting. E.g. he seems to understand that a simulator

>> that steps 10 steps then stops regardless, does not imply that the

>> simulated computation does not halt.

>>

>> Although... he doesn't properly understand what halting means,

>

> Halting means terminating normally by reaching the last "return"

> instruction of the C function the last "ret" instruction of the x86

> translation of this "C" function or the final state of a Turing machine.

>

> *computation that halts* … the Turing machine will halt whenever it

> enters a final state. (Linz:1990:234)

>

> Linz, Peter 1990. An Introduction to Formal Languages and Automata.

> Lexington/Toronto: D. C. Heath and Company.

>

>

and indication that H(P,P) returning 0 is wrong?

Remember, P calls H(P,P) to specifically ask it about P(P), so if that

means something else, you have not defined your machines correctly, and

are thus also WRONG.

A *Correct* simulation is a simulation that matches the behavior of the

thing it is simulating, so a simulation that shows that P(P) doesn't

halt can't be correct.

We also only talk about the program that IS THERE, not other

hypothetical programs, like the H that doesn't do the abort, as that

isn't the program we are looking at.

Reply all

Reply to author

Forward

0 new messages