Halting problem proofs refuted on the basis of software engineering

[olcott]

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

[Mr Flibble]

void Px(u32 x)
{
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

[olcott]

Your false assumptions are directly contradicted by the semantics of the
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));
}

_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

[olcott]

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

--

[Mr Flibble]

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

[olcott]

I just proved that H(Px,Px) does correctly predict that its complete and

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

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

[Mr Flibble]

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

[olcott]

Your lack of comprehension does not actually count as any rebuttal at all.

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

[Mr Flibble]

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

[snip]

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

[olcott]

[Mr Flibble]

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

[olcott]

I found that my reply did not make it to all the groups so I posted it
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.

[Mr Flibble]

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

[olcott]

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

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.

[Mr Flibble]

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

Not EVERY simulating halt decider, only YOURS gets the answer wrong.
Px() halts.

/Flibble

[olcott]

unreachable code, (to *every simulating halt* decider H) you would be
incompetent.

[Mr Flibble]

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

[olcott]

Yet that is *not* what the actual code specifies. Every function called
in infinite recursion is not allowed to return to its caller.

[Mr Flibble]

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

[olcott]

The halting problem expressly allows every algorithm in the universe as
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

[Mr Flibble]

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

[olcott]

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:

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

[olcott]

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

[olcott]

Instead of a conclusion a computation has a final state.

[olcott]

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:

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

[olcott]

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.

[olcott]

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

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.

[olcott]

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]

[olcott]

On 7/5/2022 3:24 PM, André G. Isaak wrote:
> 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.
>>

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

The start state, state transitions inbetween and the final state of a
computation can be construed as a formal proof from premises to conclusion.

[Richard Damon]

Except that H doesn't actually look at the input as an actual program,
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".

[Richard Damon]

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

[olcott]

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

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.

[olcott]

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

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

[olcott]

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

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

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.

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

[olcott]

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:

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

[olcott]

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

[olcott]

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.

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.

[olcott]

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

> 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) {
> 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));
}

[olcott]

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:

>>>> 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.
>>>
>>> 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");
>>> 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
>>> [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
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.

[Richard Damon]

No, your system is broken.

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.

[olcott]

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)

>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;

>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> Simulating halt decider H detects that its simulated input is
>>>> essentially calling H in infinite recursion. H aborts its simulation on
>>>> this basis and rejects this input as non-halting.
>>>
>>> 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)

[olcott]

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.

[Richard Damon]

No, it is easily verified tha H doesn't correctly simulate its input,
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.

You are very good at hiding the truth. If you said that H was DEFINED to
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.
>

Nope, show the proof of that claim. Remember, the proof MUST include the
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.

Nope. If H is to be a Halt Decider, it must map the inputs, to the
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.

Nope, "Simulating Halt Deciders", if they are to be considered a Halt
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.

A Decider CAN ONLY compute a mapping to an accept or reject state based
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.

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.

WRONG. it is obvious that a CORRECTLY simulated P will halt if H(P,P)
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.

Right, and the ACTUAL BEHAVIOR of the input to H(P,P) is the behavior of
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.
>

Yes, if it DOES simulate correctly until it can correctly predict that
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.

And again H(P,P) MUST represent P(P) or your P is defined incorrectly.

>
> The ultimate measure of the actual behavior of the actual input is the
> provable correct simulation of this input by the simulating halt decider.

ONLY if the simulator never stops its simulation until it can actually
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.

Nope, you haven't actually established this fact. You "proof" is based
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.

Nope, YOU ARE WRONG on the basis that H give the wrong answer to the
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.

[olcott]

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.

>

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

[Richard Damon]

And the ACTUAL behavior of the input to H(P,P) is the behavior of P(P)
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.

[olcott]

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:

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

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

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

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

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

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

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

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

[olcott]

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

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

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

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

[Richard Damon]

Which just doesn't matter as Halting is defined based on the actual
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.

(3) is just WRONG. FAIL. PROOF YOU ARE AN IDIOT.

[olcott]

Then the whole idea of a UTM would be totally bogus.

[olcott]

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.

[Richard Damon]

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