I have been following the discussions about Halt deciders with interest.
As a retired software designer and developer, I have a lot of practical
experience, but not much theoretical education, although the theoretical
background is very interesting. I learned a lot. I would like to verify
that I understand it correctly. Could you point out any errors in the
summary below?

1) (Definition of halt) A program X with input Y is said to halt if it
reaches its end condition after a finite number of steps. It does not
halt if it continues to execute infinitely.
(So, X(Y) either halts, or it does not halt.)
(It is irrelevant whether the end condition is reached in the 'normal'
way, or by other means, e.g. an unhandled 'exception'.)

2) (Definition of halt decider) A halt decider H is a program that,
given a program X with input Y decides, after a finite number of steps,
whether X(Y) halts or not.
(H(X,Y) itself must halt after a finite number of steps. It must return
either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
convention, which could also be two other arbitrary values.)

From 1 and 2 it follows:

3) If X(Y) halts, then H must return 1. If H does not return 1 in a
finite number of steps, it might return another interesting result, but
it is not a halt decider. (Not returning 1 includes returning other
values, not halting, or throwing 'exceptions'.)

4) If X(Y) does not halt, then H must return 0. If it does not return 0
in a finite number of steps, it might return another interesting result,
but it is not a halt decider. (Not returning 0 includes returning other
values, not halting, or throwing 'exceptions'.)

Paradoxical program:

5) It is always possible to construct a program P, that uses code with
the same logic as H, in order to do the opposite of what H(P,P) returns.
(P does not necessarily need to use the exact same code as H does,
amongst others it could use a modified copy of H, or a simulation of H.)

From 5 it follows that a general halt decider that works for any X and
Y does not exist:

From 3, 4 and 5 it follows:

6) If P(P) halts, then H should return 1, but if H would do so, P(P)
would not halt.

7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
would halt.

8) If P(P) halts and H does not return 1 after a finite number of steps,
then H is not a halt decider.
(The result could nevertheless be interesting for other purposes.)
(It is irrelevant what causes P(P) to halt.)

9) If P(P) does not halt and H does not return 0 after a finite number
of steps, then H is not a halt decider.
(The result could nevertheless be interesting for other purposes.)

On Monday, October 17, 2022 at 10:30:59 AM UTC+1, Fred. Zwarts wrote:
> I have been following the discussions about Halt deciders with interest.
> As a retired software designer and developer, I have a lot of practical
> experience, but not much theoretical education, although the theoretical
> background is very interesting. I learned a lot. I would like to verify
> that I understand it correctly. Could you point out any errors in the
> summary below?
>
> 1) (Definition of halt) A program X with input Y is said to halt if it
> reaches its end condition after a finite number of steps. It does not
> halt if it continues to execute infinitely.
> (So, X(Y) either halts, or it does not halt.)
> (It is irrelevant whether the end condition is reached in the 'normal'
> way, or by other means, e.g. an unhandled 'exception'.)
>
> 2) (Definition of halt decider) A halt decider H is a program that,
> given a program X with input Y decides, after a finite number of steps,
> whether X(Y) halts or not.
> (H(X,Y) itself must halt after a finite number of steps. It must return
> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> convention, which could also be two other arbitrary values.)
>
> From 1 and 2 it follows:
>
> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> finite number of steps, it might return another interesting result, but
> it is not a halt decider. (Not returning 1 includes returning other
> values, not halting, or throwing 'exceptions'.)
>
> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> in a finite number of steps, it might return another interesting result,
> but it is not a halt decider. (Not returning 0 includes returning other
> values, not halting, or throwing 'exceptions'.)
>
> Paradoxical program:
>
> 5) It is always possible to construct a program P, that uses code with
> the same logic as H, in order to do the opposite of what H(P,P) returns.
> (P does not necessarily need to use the exact same code as H does,
> amongst others it could use a modified copy of H, or a simulation of H.)
>
> From 5 it follows that a general halt decider that works for any X and
> Y does not exist:
>
> From 3, 4 and 5 it follows:
>
> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> would not halt.
>
> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> would halt.
>
> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> then H is not a halt decider.
> (The result could nevertheless be interesting for other purposes.)
> (It is irrelevant what causes P(P) to halt.)
>
> 9) If P(P) does not halt and H does not return 0 after a finite number
> of steps, then H is not a halt decider.
> (The result could nevertheless be interesting for other purposes.)

Yes, that looks exactly it. Olcott has claimed that there is a flaw in the proof, and has since gone on to claim he has a fully working H, but he hasn't convinced anybody here.

On Monday, 17 October 2022 at 17:30:59 UTC+8, Fred. Zwarts wrote:
> I have been following the discussions about Halt deciders with interest.
> As a retired software designer and developer, I have a lot of practical
> experience, but not much theoretical education, although the theoretical
> background is very interesting. I learned a lot. I would like to verify
> that I understand it correctly. Could you point out any errors in the
> summary below?
>
> 1) (Definition of halt) A program X with input Y is said to halt if it
> reaches its end condition after a finite number of steps. It does not
> halt if it continues to execute infinitely.
> (So, X(Y) either halts, or it does not halt.)
> (It is irrelevant whether the end condition is reached in the 'normal'
> way, or by other means, e.g. an unhandled 'exception'.)
Basically, yes. The HP (most formal one) is specified using TM.
A TM halts means it reaches designated final state. This is equivalent to a
program 'returns' (whatever, you define the 'final state').
OTHER conditions are non-halting.

> 2) (Definition of halt decider) A halt decider H is a program that,
> given a program X with input Y decides, after a finite number of steps,
> whether X(Y) halts or not.
> (H(X,Y) itself must halt after a finite number of steps. It must return
> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> convention, which could also be two other arbitrary values.)

I find it not quite simple to define 'halt decider', probably not necessary.
So, I say any program X that tries to test whether a given program (as X's input)
halts or not is a 'halt decider'.

> From 1 and 2 it follows:
>
> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> finite number of steps, it might return another interesting result, but
> it is not a halt decider. (Not returning 1 includes returning other
> values, not halting, or throwing 'exceptions'.)

Yes, according to the definition (a failed halt decider)

> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> in a finite number of steps, it might return another interesting result,
> but it is not a halt decider. (Not returning 0 includes returning other
> values, not halting, or throwing 'exceptions'.)
>

Yes, according to the definition (a failed halt decider)

> Paradoxical program:
>
> 5) It is always possible to construct a program P, that uses code with
> the same logic as H, in order to do the opposite of what H(P,P) returns.
> (P does not necessarily need to use the exact same code as H does,
> amongst others it could use a modified copy of H, or a simulation of H.)
>
> From 5 it follows that a general halt decider that works for any X and
> Y does not exist:
>
> From 3, 4 and 5 it follows:

There are many details, but yes, you are correct.

> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> would not halt.

Correct.

> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> would halt.

Correct.

> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> then H is not a halt decider.
> (The result could nevertheless be interesting for other purposes.)
> (It is irrelevant what causes P(P) to halt.)
>
> 9) If P(P) does not halt and H does not return 0 after a finite number
> of steps, then H is not a halt decider.
> (The result could nevertheless be interesting for other purposes.)

H is not the halt decider the Halting Problem specifies (a failed halt decider).

On 2022-10-17 09:30:56 +0000, Fred. Zwarts said:

> I have been following the discussions about Halt deciders with
> interest. As a retired software designer and developer, I have a lot of
> practical experience, but not much theoretical education, although the
> theoretical background is very interesting. I learned a lot. I would
> like to verify that I understand it correctly. Could you point out any
> errors in the summary below?
>
> 1) (Definition of halt) A program X with input Y is said to halt if it
> reaches its end condition after a finite number of steps. It does not
> halt if it continues to execute infinitely.
> (So, X(Y) either halts, or it does not halt.)
> (It is irrelevant whether the end condition is reached in the 'normal'
> way, or by other means, e.g. an unhandled 'exception'.)

Definitions vary a little among authors. Usually the halting problem and
other computability problems define that "program" is a Turing machine.
The exact definition of "halt" varies but often it means that the execution
has reached a situation where there is no rule specifying what to do next.
With other definitions one must check whether it is possible that the
execution neither halts nor runs forever.

> 2) (Definition of halt decider) A halt decider H is a program that,
> given a program X with input Y decides, after a finite number of steps,
> whether X(Y) halts or not.
> (H(X,Y) itself must halt after a finite number of steps. It must return
> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> convention, which could also be two other arbitrary values.)

The halt decider must be a program in the same sense as the programs it
examines are programs. Usually the requirement is that the required halt
decider is a Turing machine and its input is a description of a Turing
machine.

> From 1 and 2 it follows:
>
> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> finite number of steps, it might return another interesting result, but
> it is not a halt decider. (Not returning 1 includes returning other
> values, not halting, or throwing 'exceptions'.)
>
> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> in a finite number of steps, it might return another interesting
> result, but it is not a halt decider. (Not returning 0 includes
> returning other values, not halting, or throwing 'exceptions'.)

Another way to say the same is that H is not a halt decider
if there is some X and some Y such that
- X(Y) halts and H(X,Y) returns 0
- X(Y) does not halt and H(X,Y) returns 1
- H(X,Y) returns something that is neither 0 nor 1
- H(X,Y) does not return anything

> Paradoxical program:

Also called "pathological program"

> 5) It is always possible to construct a program P, that uses code with
> the same logic as H, in order to do the opposite of what H(P,P) returns.
> (P does not necessarily need to use the exact same code as H does,
> amongst others it could use a modified copy of H, or a simulation of H.)
>
> From 5 it follows that a general halt decider that works for any X and
> Y does not exist:
>
> From 3, 4 and 5 it follows:
>
> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> would not halt.
>
> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> would halt.
>
> 8) If P(P) halts and H does not return 1 after a finite number of
> steps, then H is not a halt decider.
> (The result could nevertheless be interesting for other purposes.)
> (It is irrelevant what causes P(P) to halt.)
>
> 9) If P(P) does not halt and H does not return 0 after a finite number
> of steps, then H is not a halt decider.
> (The result could nevertheless be interesting for other purposes.)

All that is correct.

Mikko

On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
> I have been following the discussions about Halt deciders with interest.
> As a retired software designer and developer, I have a lot of practical
> experience, but not much theoretical education, although the theoretical
> background is very interesting. I learned a lot. I would like to verify
> that I understand it correctly. Could you point out any errors in the
> summary below?
>
> 1) (Definition of halt) A program X with input Y is said to halt if it
> reaches its end condition after a finite number of steps. It does not
> halt if it continues to execute infinitely.
> (So, X(Y) either halts, or it does not halt.)
> (It is irrelevant whether the end condition is reached in the 'normal'
> way, or by other means, e.g. an unhandled 'exception'.)
>
> 2) (Definition of halt decider) A halt decider H is a program that,
> given a program X with input Y decides, after a finite number of steps,
> whether X(Y) halts or not.
> (H(X,Y) itself must halt after a finite number of steps. It must return
> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> convention, which could also be two other arbitrary values.)
>
> From 1 and 2 it follows:
>
> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> finite number of steps, it might return another interesting result, but
> it is not a halt decider. (Not returning 1 includes returning other
> values, not halting, or throwing 'exceptions'.)
>
> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> in a finite number of steps, it might return another interesting result,
> but it is not a halt decider. (Not returning 0 includes returning other
> values, not halting, or throwing 'exceptions'.)
>
> Paradoxical program:
>
> 5) It is always possible to construct a program P, that uses code with
> the same logic as H, in order to do the opposite of what H(P,P) returns.
> (P does not necessarily need to use the exact same code as H does,
> amongst others it could use a modified copy of H, or a simulation of H.)
>
> From 5 it follows that a general halt decider that works for any X and
> Y does not exist:
>
> From 3, 4 and 5 it follows:
>
> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> would not halt.
>
> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> would halt.
>
> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> then H is not a halt decider.
> (The result could nevertheless be interesting for other purposes.)
> (It is irrelevant what causes P(P) to halt.)
>
> 9) If P(P) does not halt and H does not return 0 after a finite number
> of steps, then H is not a halt decider.
> (The result could nevertheless be interesting for other purposes.)

Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:

For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.

Where PO's confusion comes into play is that he thinks that if a potential decider is using simulation to make its decision, then (speaking in C terms) the simulation performed that particular decider residing at a given address is the ultimate authority on halting, as opposed to the direct execution of the algorithm, and that multiple implementations of the decider at that address can be considered to making that decision. The problem with this is that if the program to be checked includes a call to the decider, considering multiple potential implementations of the decider means that the the algorithm being tested also changes for each of those potential decider changes. And because the halting problem is really about algorithms, which loosely speaking are a fixed immutable sequence of exact instructions, changing the algorithm being decided on is strictly not allowed.

This means he is computing some other function, and because he is computing some other function his work has no bearing on the halting problem.

So for fun, let's see what he's actually computing:

The halting function asks the question "does the algorithm X with input Y halt?". The question PO is asking (in C terms) is "does there exist an implementation of the function H that can simulate the function call X(Y) to completion?"

Right away, we can see that these functions are not equivalent as the halting function has two inputs, the algorithm X and its input Y, while PO's function (which I'll refer to as the PO-halting function, or POH) takes 3 inputs, the algorithm X, its input Y, and the address of the function H performing the simulation. This also means that his deciders, which initially appear to take just two inputs, take their own address as an implicit third parameter.

This is apparent if you look at his code for H and H1 which he claims are identical but in fact are not. The former makes use of the address of H while the latter makes use of the address of H1.

This explains why PO claims that H(P,P)==0 is correct and that H1(P,P)==1 is also correct, as each is mapping a distinct subset of the PO-halting function. The former is computing POH(H,P,P) while the latter is computing POH(H1,P,P).

This also explains why he claims that the direct execution of P(P) is "a non-input" to H, since H(X,Y) computes POH(H,X,Y) and the direct execution of P(P) is represented as POH(main,P,P) which is outside the domain of the subset of the PO-halting function that H is computing.

So to sum up, the halting function performs this mapping:

For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

While the PO-Halting function performs this mapping:

For a function X with input Y and a function H which simulates X:
POH(H,X,Y)==1 if and only if there exists an implementation of H that can simulate X(Y) to completion
POH(H,X,Y)==0 if and only if there does not exist an implementation of H that can simulate X(Y) to completion

Where a PO-halt decider computes a subset of this mapping:

Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y)

And since the halting problem is about the halting function and not the PO-halting function, anything regarding the PO-halting function is irrelevant to the halting problem and any proofs related to it.

On 10/17/2022 4:30 AM, Fred. Zwarts wrote:
> I have been following the discussions about Halt deciders with interest.
> As a retired software designer and developer, I have a lot of practical
> experience, but not much theoretical education, although the theoretical
> background is very interesting. I learned a lot. I would like to verify
> that I understand it correctly. Could you point out any errors in the
> summary below?
>
> 1) (Definition of halt) A program X with input Y is said to halt if it
> reaches its end condition after a finite number of steps. It does not
> halt if it continues to execute infinitely.
> (So, X(Y) either halts, or it does not halt.)
> (It is irrelevant whether the end condition is reached in the 'normal'
> way, or by other means, e.g. an unhandled 'exception'.)
>
> 2) (Definition of halt decider) A halt decider H is a program that,
> given a program X with input Y decides, after a finite number of steps,
> whether X(Y) halts or not.
> (H(X,Y) itself must halt after a finite number of steps. It must return
> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> convention, which could also be two other arbitrary values.)

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

An alternative definition for a halt decider approved by MIT Professor
Michael Sipser (author of the best selling book on the theory of
computation)
https://www.amazon.com/Introduction-Theory-Computation-Sipser/dp/8131525295
is shown above and paraphrased below:

Would D correctly simulated by H ever stop running if not aborted?
Is proven on page 3 of this paper to be "no" thus perfectly meeting the
Sipser approved criteria shown above.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 10/17/2022 7:43 AM, Mikko wrote:
> On 2022-10-17 09:30:56 +0000, Fred. Zwarts said:
>
>> I have been following the discussions about Halt deciders with
>> interest. As a retired software designer and developer, I have a lot
>> of practical experience, but not much theoretical education, although
>> the theoretical background is very interesting. I learned a lot. I
>> would like to verify that I understand it correctly. Could you point
>> out any errors in the summary below?
>>
>> 1) (Definition of halt) A program X with input Y is said to halt if it
>> reaches its end condition after a finite number of steps. It does not
>> halt if it continues to execute infinitely.
>> (So, X(Y) either halts, or it does not halt.)
>> (It is irrelevant whether the end condition is reached in the 'normal'
>> way, or by other means, e.g. an unhandled 'exception'.)
>
> Definitions vary a little among authors. Usually the halting problem and
> other computability problems define that "program" is a Turing machine.
> The exact definition of "halt" varies but often it means that the execution
> has reached a situation where there is no rule specifying what to do next.
> With other definitions one must check whether it is possible that the
> execution neither halts nor runs forever.
>
>> 2) (Definition of halt decider) A halt decider H is a program that,
>> given a program X with input Y decides, after a finite number of
>> steps, whether X(Y) halts or not.
>> (H(X,Y) itself must halt after a finite number of steps. It must
>> return either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and
>> 0 are a convention, which could also be two other arbitrary values.)
>
> The halt decider must be a program in the same sense as the programs it
> examines are programs. Usually the requirement is that the required halt
> decider is a Turing machine and its input is a description of a Turing
> machine.
>
>>  From 1 and 2 it follows:
>>
>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
>> finite number of steps, it might return another interesting result,
>> but it is not a halt decider. (Not returning 1 includes returning
>> other values, not halting, or throwing 'exceptions'.)
>>
>> 4) If X(Y) does not halt, then H must return 0. If it does not return
>> 0 in a finite number of steps, it might return another interesting
>> result, but it is not a halt decider. (Not returning 0 includes
>> returning other values, not halting, or throwing 'exceptions'.)
>
> Another way to say the same is that H is not a halt decider
> if there is some X and some Y such that
> - X(Y) halts and H(X,Y) returns 0
> - X(Y) does not halt and H(X,Y) returns 1
> - H(X,Y) returns something that is neither 0 nor 1
> - H(X,Y) does not return anything
>
>> Paradoxical program:
>
> Also called "pathological program"
>
>> 5) It is always possible to construct a program P, that uses code with
>> the same logic as H, in order to do the opposite of what H(P,P) returns.
>> (P does not necessarily need to use the exact same code as H does,
>> amongst others it could use a modified copy of H, or a simulation of H.)
>>
>>  From 5 it follows that a general halt decider that works for any X
>> and Y does not exist:
>>
>>  From 3, 4 and 5 it follows:
>>
>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
>> would not halt.
>>
>> 7) If P(P) does not halt, H should return 0, but if H would do so,
>> P(P) would halt.
>>
>> 8) If P(P) halts and H does not return 1 after a finite number of
>> steps, then H is not a halt decider.
>> (The result could nevertheless be interesting for other purposes.)
>> (It is irrelevant what causes P(P) to halt.)
>>
>> 9) If P(P) does not halt and H does not return 0 after a finite number
>> of steps, then H is not a halt decider.
>> (The result could nevertheless be interesting for other purposes.)
>
> All that is correct.
>
> Mikko
>
>

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

An alternative definition for a halt decider approved by MIT Professor
Michael Sipser (author of the best selling book on the theory of
computation)
https://www.amazon.com/Introduction-Theory-Computation-Sipser/dp/8131525295
is shown above and paraphrased below:

Would D correctly simulated by H ever stop running if not aborted?
Is proven on page 3 of this paper to be "no" thus perfectly meeting the
Sipser approved criteria shown above.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

--
Copyright 2022 Pete Olcott

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

On 10/17/2022 6:55 AM, wij wrote:
> On Monday, 17 October 2022 at 17:30:59 UTC+8, Fred. Zwarts wrote:
>> I have been following the discussions about Halt deciders with interest.
>> As a retired software designer and developer, I have a lot of practical
>> experience, but not much theoretical education, although the theoretical
>> background is very interesting. I learned a lot. I would like to verify
>> that I understand it correctly. Could you point out any errors in the
>> summary below?
>>
>> 1) (Definition of halt) A program X with input Y is said to halt if it
>> reaches its end condition after a finite number of steps. It does not
>> halt if it continues to execute infinitely.
>> (So, X(Y) either halts, or it does not halt.)
>> (It is irrelevant whether the end condition is reached in the 'normal'
>> way, or by other means, e.g. an unhandled 'exception'.)
>
> Basically, yes. The HP (most formal one) is specified using TM.
> A TM halts means it reaches designated final state. This is equivalent to a
> program 'returns' (whatever, you define the 'final state').
> OTHER conditions are non-halting.
>
>> 2) (Definition of halt decider) A halt decider H is a program that,
>> given a program X with input Y decides, after a finite number of steps,
>> whether X(Y) halts or not.
>> (H(X,Y) itself must halt after a finite number of steps. It must return
>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
>> convention, which could also be two other arbitrary values.)
>
> I find it not quite simple to define 'halt decider', probably not necessary.
> So, I say any program X that tries to test whether a given program (as X's input)
> halts or not is a 'halt decider'.
>
>> From 1 and 2 it follows:
>>
>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
>> finite number of steps, it might return another interesting result, but
>> it is not a halt decider. (Not returning 1 includes returning other
>> values, not halting, or throwing 'exceptions'.)
>
> Yes, according to the definition (a failed halt decider)
>
>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
>> in a finite number of steps, it might return another interesting result,
>> but it is not a halt decider. (Not returning 0 includes returning other
>> values, not halting, or throwing 'exceptions'.)
>>
>
> Yes, according to the definition (a failed halt decider)
>
>> Paradoxical program:
>>
>> 5) It is always possible to construct a program P, that uses code with
>> the same logic as H, in order to do the opposite of what H(P,P) returns.
>> (P does not necessarily need to use the exact same code as H does,
>> amongst others it could use a modified copy of H, or a simulation of H.)
>>
>> From 5 it follows that a general halt decider that works for any X and
>> Y does not exist:
>>
>> From 3, 4 and 5 it follows:
>
> There are many details, but yes, you are correct.
>
>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
>> would not halt.
>
> Correct.
>
>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
>> would halt.
>
> Correct.
>
>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
>> then H is not a halt decider.
>> (The result could nevertheless be interesting for other purposes.)
>> (It is irrelevant what causes P(P) to halt.)
>>
>> 9) If P(P) does not halt and H does not return 0 after a finite number
>> of steps, then H is not a halt decider.
>> (The result could nevertheless be interesting for other purposes.)
>
> H is not the halt decider the Halting Problem specifies (a failed halt decider).

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

An alternative definition for a halt decider approved by MIT Professor
Michael Sipser (author of the best selling book on the theory of
computation)
https://www.amazon.com/Introduction-Theory-Computation-Sipser/dp/8131525295
is shown above and paraphrased below:

Would D correctly simulated by H ever stop running if not aborted?
Is proven on page 3 of this paper to be "no" thus perfectly meeting the
Sipser approved criteria shown above.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

This is applied to the Peter Linz Halting Problem proof on page 4 of the
above paper.

--
Copyright 2022 Pete Olcott

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

On 10/17/2022 7:47 AM, Dennis Bush wrote:
> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
>> I have been following the discussions about Halt deciders with interest.
>> As a retired software designer and developer, I have a lot of practical
>> experience, but not much theoretical education, although the theoretical
>> background is very interesting. I learned a lot. I would like to verify
>> that I understand it correctly. Could you point out any errors in the
>> summary below?
>>
>> 1) (Definition of halt) A program X with input Y is said to halt if it
>> reaches its end condition after a finite number of steps. It does not
>> halt if it continues to execute infinitely.
>> (So, X(Y) either halts, or it does not halt.)
>> (It is irrelevant whether the end condition is reached in the 'normal'
>> way, or by other means, e.g. an unhandled 'exception'.)
>>
>> 2) (Definition of halt decider) A halt decider H is a program that,
>> given a program X with input Y decides, after a finite number of steps,
>> whether X(Y) halts or not.
>> (H(X,Y) itself must halt after a finite number of steps. It must return
>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
>> convention, which could also be two other arbitrary values.)
>>
>> From 1 and 2 it follows:
>>
>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
>> finite number of steps, it might return another interesting result, but
>> it is not a halt decider. (Not returning 1 includes returning other
>> values, not halting, or throwing 'exceptions'.)
>>
>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
>> in a finite number of steps, it might return another interesting result,
>> but it is not a halt decider. (Not returning 0 includes returning other
>> values, not halting, or throwing 'exceptions'.)
>>
>> Paradoxical program:
>>
>> 5) It is always possible to construct a program P, that uses code with
>> the same logic as H, in order to do the opposite of what H(P,P) returns.
>> (P does not necessarily need to use the exact same code as H does,
>> amongst others it could use a modified copy of H, or a simulation of H.)
>>
>> From 5 it follows that a general halt decider that works for any X and
>> Y does not exist:
>>
>> From 3, 4 and 5 it follows:
>>
>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
>> would not halt.
>>
>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
>> would halt.
>>
>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
>> then H is not a halt decider.
>> (The result could nevertheless be interesting for other purposes.)
>> (It is irrelevant what causes P(P) to halt.)
>>
>> 9) If P(P) does not halt and H does not return 0 after a finite number
>> of steps, then H is not a halt decider.
>> (The result could nevertheless be interesting for other purposes.)
>
> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
>
> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
> H(X,Y)==1 if and only if X(Y) halts, and
> H(X,Y)==0 if and only if X(Y) does not halt
>
> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
>

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

An alternative definition for a halt decider approved by MIT Professor
Michael Sipser (author of the best selling book on the theory of
computation)
https://www.amazon.com/Introduction-Theory-Computation-Sipser/dp/8131525295
is shown above and paraphrased below:

Would D correctly simulated by H ever stop running if not aborted?
Is proven on page 3 of this paper to be "no" thus perfectly meeting the
Sipser approved criteria shown above.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

This is applied to the Peter Linz Halting Problem proof on page 4 of the
above paper.

--
Copyright 2022 Pete Olcott

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

On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
> On 10/17/2022 7:47 AM, Dennis Bush wrote:
> > On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
> >> I have been following the discussions about Halt deciders with interest.
> >> As a retired software designer and developer, I have a lot of practical
> >> experience, but not much theoretical education, although the theoretical
> >> background is very interesting. I learned a lot. I would like to verify
> >> that I understand it correctly. Could you point out any errors in the
> >> summary below?
> >>
> >> 1) (Definition of halt) A program X with input Y is said to halt if it
> >> reaches its end condition after a finite number of steps. It does not
> >> halt if it continues to execute infinitely.
> >> (So, X(Y) either halts, or it does not halt.)
> >> (It is irrelevant whether the end condition is reached in the 'normal'
> >> way, or by other means, e.g. an unhandled 'exception'.)
> >>
> >> 2) (Definition of halt decider) A halt decider H is a program that,
> >> given a program X with input Y decides, after a finite number of steps,
> >> whether X(Y) halts or not.
> >> (H(X,Y) itself must halt after a finite number of steps. It must return
> >> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> >> convention, which could also be two other arbitrary values.)
> >>
> >> From 1 and 2 it follows:
> >>
> >> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> >> finite number of steps, it might return another interesting result, but
> >> it is not a halt decider. (Not returning 1 includes returning other
> >> values, not halting, or throwing 'exceptions'.)
> >>
> >> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> >> in a finite number of steps, it might return another interesting result,
> >> but it is not a halt decider. (Not returning 0 includes returning other
> >> values, not halting, or throwing 'exceptions'.)
> >>
> >> Paradoxical program:
> >>
> >> 5) It is always possible to construct a program P, that uses code with
> >> the same logic as H, in order to do the opposite of what H(P,P) returns.
> >> (P does not necessarily need to use the exact same code as H does,
> >> amongst others it could use a modified copy of H, or a simulation of H..)
> >>
> >> From 5 it follows that a general halt decider that works for any X and
> >> Y does not exist:
> >>
> >> From 3, 4 and 5 it follows:
> >>
> >> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> >> would not halt.
> >>
> >> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> >> would halt.
> >>
> >> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> >> then H is not a halt decider.
> >> (The result could nevertheless be interesting for other purposes.)
> >> (It is irrelevant what causes P(P) to halt.)
> >>
> >> 9) If P(P) does not halt and H does not return 0 after a finite number
> >> of steps, then H is not a halt decider.
> >> (The result could nevertheless be interesting for other purposes.)
> >
> > Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
> >
> > For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
> > H(X,Y)==1 if and only if X(Y) halts, and
> > H(X,Y)==0 if and only if X(Y) does not halt
> >
> > And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
> >
> *Professor Sipser has agreed to these verbatim words* (and no more)
> If simulating halt decider H correctly simulates its input D until H
> correctly determines that its simulated D would never stop running
> unless aborted then H can abort its simulation of D and correctly report
> that D specifies a non-halting sequence of configurations.

And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.

The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution. This also means that there is only ONE correct simulation, so he took your wording of "its simulation of D" to mean a correct simulation by the conventional meaning, which is EXACTLY matching the behavior of direct execution. He is also assuming that a simulating halt decider meets ALL of the requirements of a halt decider. So what he actually agreed to was:

If H determines that the correct simulation of D does not halt, then H can correctly report non-halting.

In other words, he agreed that a halt decider maps the halting function:

For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

Which the proofs explicitly state.

>
> An alternative definition for a halt decider approved by MIT Professor
> Michael Sipser (author of the best selling book on the theory of
> computation)
> https://www.amazon.com/Introduction-Theory-Computation-Sipser/dp/8131525295
> is shown above and paraphrased below:
>
> Would D correctly simulated by H ever stop running if not aborted?
> Is proven on page 3 of this paper to be "no" thus perfectly meeting the
> Sipser approved criteria shown above.

Which, using your definition of "correct simulation", means D is computing the PO-halting function:

For a function X with input Y and a function H which simulates X:
POH(H,X,Y)==1 if and only if there exists an implementation of H that can simulate X(Y) to completion
POH(H,X,Y)==0 if and only if there does not exist an implementation of H that can simulate X(Y) to completion
Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y)

And because the halting problem proofs make claims about the halting function, claims about the PO-halting function are irrelevant.

>
> *Rebutting the Sipser Halting Problem Proof*
> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>
> This is applied to the Peter Linz Halting Problem proof on page 4 of the
> above paper.

On 10/17/2022 9:49 AM, Dennis Bush wrote:
> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
>>>> I have been following the discussions about Halt deciders with interest.
>>>> As a retired software designer and developer, I have a lot of practical
>>>> experience, but not much theoretical education, although the theoretical
>>>> background is very interesting. I learned a lot. I would like to verify
>>>> that I understand it correctly. Could you point out any errors in the
>>>> summary below?
>>>>
>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
>>>> reaches its end condition after a finite number of steps. It does not
>>>> halt if it continues to execute infinitely.
>>>> (So, X(Y) either halts, or it does not halt.)
>>>> (It is irrelevant whether the end condition is reached in the 'normal'
>>>> way, or by other means, e.g. an unhandled 'exception'.)
>>>>
>>>> 2) (Definition of halt decider) A halt decider H is a program that,
>>>> given a program X with input Y decides, after a finite number of steps,
>>>> whether X(Y) halts or not.
>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
>>>> convention, which could also be two other arbitrary values.)
>>>>
>>>> From 1 and 2 it follows:
>>>>
>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
>>>> finite number of steps, it might return another interesting result, but
>>>> it is not a halt decider. (Not returning 1 includes returning other
>>>> values, not halting, or throwing 'exceptions'.)
>>>>
>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
>>>> in a finite number of steps, it might return another interesting result,
>>>> but it is not a halt decider. (Not returning 0 includes returning other
>>>> values, not halting, or throwing 'exceptions'.)
>>>>
>>>> Paradoxical program:
>>>>
>>>> 5) It is always possible to construct a program P, that uses code with
>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
>>>> (P does not necessarily need to use the exact same code as H does,
>>>> amongst others it could use a modified copy of H, or a simulation of H.)
>>>>
>>>> From 5 it follows that a general halt decider that works for any X and
>>>> Y does not exist:
>>>>
>>>> From 3, 4 and 5 it follows:
>>>>
>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
>>>> would not halt.
>>>>
>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
>>>> would halt.
>>>>
>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
>>>> then H is not a halt decider.
>>>> (The result could nevertheless be interesting for other purposes.)
>>>> (It is irrelevant what causes P(P) to halt.)
>>>>
>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
>>>> of steps, then H is not a halt decider.
>>>> (The result could nevertheless be interesting for other purposes.)
>>>
>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
>>>
>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
>>> H(X,Y)==1 if and only if X(Y) halts, and
>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>
>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
>>>
>> *Professor Sipser has agreed to these verbatim words* (and no more)
>> If simulating halt decider H correctly simulates its input D until H
>> correctly determines that its simulated D would never stop running
>> unless aborted then H can abort its simulation of D and correctly report
>> that D specifies a non-halting sequence of configurations.
>
> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
>
> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
I have proven an exception to this rule:

int Sipser_D(int (*M)())
{ if ( Sipser_H(M, M) )
return 0;
return 1;
}

For the infinite set of H/D pairs:
Every correct simulation of D by H will never reach the final state of D
because D specifies recursive simulation to H.

This is proven on page 3 thus refuting your claim.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

--
Copyright 2022 Pete Olcott

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

On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
> On 10/17/2022 9:49 AM, Dennis Bush wrote:
> > On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
> >> On 10/17/2022 7:47 AM, Dennis Bush wrote:
> >>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
> >>>> I have been following the discussions about Halt deciders with interest.
> >>>> As a retired software designer and developer, I have a lot of practical
> >>>> experience, but not much theoretical education, although the theoretical
> >>>> background is very interesting. I learned a lot. I would like to verify
> >>>> that I understand it correctly. Could you point out any errors in the
> >>>> summary below?
> >>>>
> >>>> 1) (Definition of halt) A program X with input Y is said to halt if it
> >>>> reaches its end condition after a finite number of steps. It does not
> >>>> halt if it continues to execute infinitely.
> >>>> (So, X(Y) either halts, or it does not halt.)
> >>>> (It is irrelevant whether the end condition is reached in the 'normal'
> >>>> way, or by other means, e.g. an unhandled 'exception'.)
> >>>>
> >>>> 2) (Definition of halt decider) A halt decider H is a program that,
> >>>> given a program X with input Y decides, after a finite number of steps,
> >>>> whether X(Y) halts or not.
> >>>> (H(X,Y) itself must halt after a finite number of steps. It must return
> >>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> >>>> convention, which could also be two other arbitrary values.)
> >>>>
> >>>> From 1 and 2 it follows:
> >>>>
> >>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> >>>> finite number of steps, it might return another interesting result, but
> >>>> it is not a halt decider. (Not returning 1 includes returning other
> >>>> values, not halting, or throwing 'exceptions'.)
> >>>>
> >>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> >>>> in a finite number of steps, it might return another interesting result,
> >>>> but it is not a halt decider. (Not returning 0 includes returning other
> >>>> values, not halting, or throwing 'exceptions'.)
> >>>>
> >>>> Paradoxical program:
> >>>>
> >>>> 5) It is always possible to construct a program P, that uses code with
> >>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
> >>>> (P does not necessarily need to use the exact same code as H does,
> >>>> amongst others it could use a modified copy of H, or a simulation of H.)
> >>>>
> >>>> From 5 it follows that a general halt decider that works for any X and
> >>>> Y does not exist:
> >>>>
> >>>> From 3, 4 and 5 it follows:
> >>>>
> >>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> >>>> would not halt.
> >>>>
> >>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> >>>> would halt.
> >>>>
> >>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> >>>> then H is not a halt decider.
> >>>> (The result could nevertheless be interesting for other purposes.)
> >>>> (It is irrelevant what causes P(P) to halt.)
> >>>>
> >>>> 9) If P(P) does not halt and H does not return 0 after a finite number
> >>>> of steps, then H is not a halt decider.
> >>>> (The result could nevertheless be interesting for other purposes.)
> >>>
> >>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
> >>>
> >>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
> >>> H(X,Y)==1 if and only if X(Y) halts, and
> >>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>
> >>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
> >>>
> >> *Professor Sipser has agreed to these verbatim words* (and no more)
> >> If simulating halt decider H correctly simulates its input D until H
> >> correctly determines that its simulated D would never stop running
> >> unless aborted then H can abort its simulation of D and correctly report
> >> that D specifies a non-halting sequence of configurations.
> >
> > And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
> >
> > The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
> I have proven an exception to this rule:

That's not a rule. It's a definition.

>
> int Sipser_D(int (*M)())
> {
> if ( Sipser_H(M, M) )
> return 0;
> return 1;
> }
>
> For the infinite set of H/D pairs:
> Every correct simulation of D by H will never reach the final state of D
> because D specifies recursive simulation to H.

So in other words your Sipser_H is computing the PO-halting function:

For a function X with input Y and a function H which simulates X:
POH(H,X,Y)==1 if and only if there exists an implementation of H that can simulate X(Y) to completion
POH(H,X,Y)==0 if and only if there does not exist an implementation of H that can simulate X(Y) to completion
Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y)

Instead of the halting function:

For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
H(X,Y)==1 if and only if X(Y) halts, and
H(X,Y)==0 if and only if X(Y) does not halt

And since the halting problem proofs are making claims about the halting function, claims about the PO-halting function are irrelevant.

On 10/17/2022 10:16 AM, Dennis Bush wrote:
> On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
>> On 10/17/2022 9:49 AM, Dennis Bush wrote:
>>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
>>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
>>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
>>>>>> I have been following the discussions about Halt deciders with interest.
>>>>>> As a retired software designer and developer, I have a lot of practical
>>>>>> experience, but not much theoretical education, although the theoretical
>>>>>> background is very interesting. I learned a lot. I would like to verify
>>>>>> that I understand it correctly. Could you point out any errors in the
>>>>>> summary below?
>>>>>>
>>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
>>>>>> reaches its end condition after a finite number of steps. It does not
>>>>>> halt if it continues to execute infinitely.
>>>>>> (So, X(Y) either halts, or it does not halt.)
>>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
>>>>>> way, or by other means, e.g. an unhandled 'exception'.)
>>>>>>
>>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
>>>>>> given a program X with input Y decides, after a finite number of steps,
>>>>>> whether X(Y) halts or not.
>>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
>>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
>>>>>> convention, which could also be two other arbitrary values.)
>>>>>>
>>>>>> From 1 and 2 it follows:
>>>>>>
>>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
>>>>>> finite number of steps, it might return another interesting result, but
>>>>>> it is not a halt decider. (Not returning 1 includes returning other
>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>
>>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
>>>>>> in a finite number of steps, it might return another interesting result,
>>>>>> but it is not a halt decider. (Not returning 0 includes returning other
>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>
>>>>>> Paradoxical program:
>>>>>>
>>>>>> 5) It is always possible to construct a program P, that uses code with
>>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
>>>>>> (P does not necessarily need to use the exact same code as H does,
>>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
>>>>>>
>>>>>> From 5 it follows that a general halt decider that works for any X and
>>>>>> Y does not exist:
>>>>>>
>>>>>> From 3, 4 and 5 it follows:
>>>>>>
>>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
>>>>>> would not halt.
>>>>>>
>>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
>>>>>> would halt.
>>>>>>
>>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
>>>>>> then H is not a halt decider.
>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>> (It is irrelevant what causes P(P) to halt.)
>>>>>>
>>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
>>>>>> of steps, then H is not a halt decider.
>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>
>>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
>>>>>
>>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>
>>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
>>>>>
>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
>>>> If simulating halt decider H correctly simulates its input D until H
>>>> correctly determines that its simulated D would never stop running
>>>> unless aborted then H can abort its simulation of D and correctly report
>>>> that D specifies a non-halting sequence of configurations.
>>>
>>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
>>>
>>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
>> I have proven an exception to this rule:
>
> That's not a rule. It's a definition.
>
>
>>
>> int Sipser_D(int (*M)())
>> {
>> if ( Sipser_H(M, M) )
>> return 0;
>> return 1;
>> }
>>
>> For the infinite set of H/D pairs:
>> Every correct simulation of D by H will never reach the final state of D
>> because D specifies recursive simulation to H.
>
> So in other words your Sipser_H is computing the PO-halting function:
>

*The PO-halting function is now Sipser approved*

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

*A paraphrase of a portion of the above paragraph*
Would D correctly simulated by H ever stop running if not aborted?

The answer of "no" is proved on page 3 of this paper.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

Professor Sipser has specifically approved the abstract to this paper.

--
Copyright 2022 Pete Olcott

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

On Monday, October 17, 2022 at 11:31:41 AM UTC-4, olcott wrote:
> On 10/17/2022 10:16 AM, Dennis Bush wrote:
> > On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
> >> On 10/17/2022 9:49 AM, Dennis Bush wrote:
> >>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
> >>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
> >>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
> >>>>>> I have been following the discussions about Halt deciders with interest.
> >>>>>> As a retired software designer and developer, I have a lot of practical
> >>>>>> experience, but not much theoretical education, although the theoretical
> >>>>>> background is very interesting. I learned a lot. I would like to verify
> >>>>>> that I understand it correctly. Could you point out any errors in the
> >>>>>> summary below?
> >>>>>>
> >>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
> >>>>>> reaches its end condition after a finite number of steps. It does not
> >>>>>> halt if it continues to execute infinitely.
> >>>>>> (So, X(Y) either halts, or it does not halt.)
> >>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
> >>>>>> way, or by other means, e.g. an unhandled 'exception'.)
> >>>>>>
> >>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
> >>>>>> given a program X with input Y decides, after a finite number of steps,
> >>>>>> whether X(Y) halts or not.
> >>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
> >>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> >>>>>> convention, which could also be two other arbitrary values.)
> >>>>>>
> >>>>>> From 1 and 2 it follows:
> >>>>>>
> >>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> >>>>>> finite number of steps, it might return another interesting result, but
> >>>>>> it is not a halt decider. (Not returning 1 includes returning other
> >>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>
> >>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> >>>>>> in a finite number of steps, it might return another interesting result,
> >>>>>> but it is not a halt decider. (Not returning 0 includes returning other
> >>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>
> >>>>>> Paradoxical program:
> >>>>>>
> >>>>>> 5) It is always possible to construct a program P, that uses code with
> >>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
> >>>>>> (P does not necessarily need to use the exact same code as H does,
> >>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
> >>>>>>
> >>>>>> From 5 it follows that a general halt decider that works for any X and
> >>>>>> Y does not exist:
> >>>>>>
> >>>>>> From 3, 4 and 5 it follows:
> >>>>>>
> >>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> >>>>>> would not halt.
> >>>>>>
> >>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> >>>>>> would halt.
> >>>>>>
> >>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> >>>>>> then H is not a halt decider.
> >>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>> (It is irrelevant what causes P(P) to halt.)
> >>>>>>
> >>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
> >>>>>> of steps, then H is not a halt decider.
> >>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>
> >>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
> >>>>>
> >>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
> >>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>
> >>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
> >>>>>
> >>>> *Professor Sipser has agreed to these verbatim words* (and no more)
> >>>> If simulating halt decider H correctly simulates its input D until H
> >>>> correctly determines that its simulated D would never stop running
> >>>> unless aborted then H can abort its simulation of D and correctly report
> >>>> that D specifies a non-halting sequence of configurations.
> >>>
> >>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
> >>>
> >>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
> >> I have proven an exception to this rule:
> >
> > That's not a rule. It's a definition.
> >
> >
> >>
> >> int Sipser_D(int (*M)())
> >> {
> >> if ( Sipser_H(M, M) )
> >> return 0;
> >> return 1;
> >> }
> >>
> >> For the infinite set of H/D pairs:
> >> Every correct simulation of D by H will never reach the final state of D
> >> because D specifies recursive simulation to H.
> >
> > So in other words your Sipser_H is computing the PO-halting function:
> >
> *The PO-halting function is now Sipser approved*

No it's not, because he used the actual meaning of the words and not your weasel-worded definitions. Using the real definitions, what he said was:

If H determines that D (or equivalently, the correct simulation of D) does not halt, then H can correctly report non-halting

Besides, the PO-halting function is irrelevant to whether the halting function is a computable function, which is what the proofs are all about.

On 10/17/2022 10:40 AM, Dennis Bush wrote:
> On Monday, October 17, 2022 at 11:31:41 AM UTC-4, olcott wrote:
>> On 10/17/2022 10:16 AM, Dennis Bush wrote:
>>> On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
>>>> On 10/17/2022 9:49 AM, Dennis Bush wrote:
>>>>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
>>>>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
>>>>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
>>>>>>>> I have been following the discussions about Halt deciders with interest.
>>>>>>>> As a retired software designer and developer, I have a lot of practical
>>>>>>>> experience, but not much theoretical education, although the theoretical
>>>>>>>> background is very interesting. I learned a lot. I would like to verify
>>>>>>>> that I understand it correctly. Could you point out any errors in the
>>>>>>>> summary below?
>>>>>>>>
>>>>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
>>>>>>>> reaches its end condition after a finite number of steps. It does not
>>>>>>>> halt if it continues to execute infinitely.
>>>>>>>> (So, X(Y) either halts, or it does not halt.)
>>>>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
>>>>>>>> way, or by other means, e.g. an unhandled 'exception'.)
>>>>>>>>
>>>>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
>>>>>>>> given a program X with input Y decides, after a finite number of steps,
>>>>>>>> whether X(Y) halts or not.
>>>>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
>>>>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
>>>>>>>> convention, which could also be two other arbitrary values.)
>>>>>>>>
>>>>>>>> From 1 and 2 it follows:
>>>>>>>>
>>>>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
>>>>>>>> finite number of steps, it might return another interesting result, but
>>>>>>>> it is not a halt decider. (Not returning 1 includes returning other
>>>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>>>
>>>>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
>>>>>>>> in a finite number of steps, it might return another interesting result,
>>>>>>>> but it is not a halt decider. (Not returning 0 includes returning other
>>>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>>>
>>>>>>>> Paradoxical program:
>>>>>>>>
>>>>>>>> 5) It is always possible to construct a program P, that uses code with
>>>>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
>>>>>>>> (P does not necessarily need to use the exact same code as H does,
>>>>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
>>>>>>>>
>>>>>>>> From 5 it follows that a general halt decider that works for any X and
>>>>>>>> Y does not exist:
>>>>>>>>
>>>>>>>> From 3, 4 and 5 it follows:
>>>>>>>>
>>>>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
>>>>>>>> would not halt.
>>>>>>>>
>>>>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
>>>>>>>> would halt.
>>>>>>>>
>>>>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
>>>>>>>> then H is not a halt decider.
>>>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>>>> (It is irrelevant what causes P(P) to halt.)
>>>>>>>>
>>>>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
>>>>>>>> of steps, then H is not a halt decider.
>>>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>>>
>>>>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
>>>>>>>
>>>>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>
>>>>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
>>>>>>>
>>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
>>>>>> If simulating halt decider H correctly simulates its input D until H
>>>>>> correctly determines that its simulated D would never stop running
>>>>>> unless aborted then H can abort its simulation of D and correctly report
>>>>>> that D specifies a non-halting sequence of configurations.
>>>>>
>>>>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
>>>>>
>>>>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
>>>> I have proven an exception to this rule:
>>>
>>> That's not a rule. It's a definition.
>>>
>>>
>>>>
>>>> int Sipser_D(int (*M)())
>>>> {
>>>> if ( Sipser_H(M, M) )
>>>> return 0;
>>>> return 1;
>>>> }
>>>>
>>>> For the infinite set of H/D pairs:
>>>> Every correct simulation of D by H will never reach the final state of D
>>>> because D specifies recursive simulation to H.
>>>
>>> So in other words your Sipser_H is computing the PO-halting function:
>>>
>> *The PO-halting function is now Sipser approved*
>
> No it's not, because he used the actual meaning of the words and not your weasel-worded definitions. Using the real definitions,

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

*A paraphrase of a portion of the above paragraph*
Would D correctly simulated by H ever stop running if not aborted?

The answer of "no" is proved on page 3 of this paper.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

*Still no rebuttal of page 3 because you know that page 3 is correct*

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On Monday, October 17, 2022 at 11:44:10 AM UTC-4, olcott wrote:
> On 10/17/2022 10:40 AM, Dennis Bush wrote:
> > On Monday, October 17, 2022 at 11:31:41 AM UTC-4, olcott wrote:
> >> On 10/17/2022 10:16 AM, Dennis Bush wrote:
> >>> On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
> >>>> On 10/17/2022 9:49 AM, Dennis Bush wrote:
> >>>>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
> >>>>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
> >>>>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
> >>>>>>>> I have been following the discussions about Halt deciders with interest.
> >>>>>>>> As a retired software designer and developer, I have a lot of practical
> >>>>>>>> experience, but not much theoretical education, although the theoretical
> >>>>>>>> background is very interesting. I learned a lot. I would like to verify
> >>>>>>>> that I understand it correctly. Could you point out any errors in the
> >>>>>>>> summary below?
> >>>>>>>>
> >>>>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
> >>>>>>>> reaches its end condition after a finite number of steps. It does not
> >>>>>>>> halt if it continues to execute infinitely.
> >>>>>>>> (So, X(Y) either halts, or it does not halt.)
> >>>>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
> >>>>>>>> way, or by other means, e.g. an unhandled 'exception'.)
> >>>>>>>>
> >>>>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
> >>>>>>>> given a program X with input Y decides, after a finite number of steps,
> >>>>>>>> whether X(Y) halts or not.
> >>>>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
> >>>>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> >>>>>>>> convention, which could also be two other arbitrary values.)
> >>>>>>>>
> >>>>>>>> From 1 and 2 it follows:
> >>>>>>>>
> >>>>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> >>>>>>>> finite number of steps, it might return another interesting result, but
> >>>>>>>> it is not a halt decider. (Not returning 1 includes returning other
> >>>>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>>>
> >>>>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> >>>>>>>> in a finite number of steps, it might return another interesting result,
> >>>>>>>> but it is not a halt decider. (Not returning 0 includes returning other
> >>>>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>>>
> >>>>>>>> Paradoxical program:
> >>>>>>>>
> >>>>>>>> 5) It is always possible to construct a program P, that uses code with
> >>>>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
> >>>>>>>> (P does not necessarily need to use the exact same code as H does,
> >>>>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
> >>>>>>>>
> >>>>>>>> From 5 it follows that a general halt decider that works for any X and
> >>>>>>>> Y does not exist:
> >>>>>>>>
> >>>>>>>> From 3, 4 and 5 it follows:
> >>>>>>>>
> >>>>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> >>>>>>>> would not halt.
> >>>>>>>>
> >>>>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> >>>>>>>> would halt.
> >>>>>>>>
> >>>>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> >>>>>>>> then H is not a halt decider.
> >>>>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>>>> (It is irrelevant what causes P(P) to halt.)
> >>>>>>>>
> >>>>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
> >>>>>>>> of steps, then H is not a halt decider.
> >>>>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>>>
> >>>>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
> >>>>>>>
> >>>>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
> >>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>
> >>>>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
> >>>>>>>
> >>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
> >>>>>> If simulating halt decider H correctly simulates its input D until H
> >>>>>> correctly determines that its simulated D would never stop running
> >>>>>> unless aborted then H can abort its simulation of D and correctly report
> >>>>>> that D specifies a non-halting sequence of configurations.
> >>>>>
> >>>>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
> >>>>>
> >>>>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
> >>>> I have proven an exception to this rule:
> >>>
> >>> That's not a rule. It's a definition.
> >>>
> >>>
> >>>>
> >>>> int Sipser_D(int (*M)())
> >>>> {
> >>>> if ( Sipser_H(M, M) )
> >>>> return 0;
> >>>> return 1;
> >>>> }
> >>>>
> >>>> For the infinite set of H/D pairs:
> >>>> Every correct simulation of D by H will never reach the final state of D
> >>>> because D specifies recursive simulation to H.
> >>>
> >>> So in other words your Sipser_H is computing the PO-halting function:
> >>>
> >> *The PO-halting function is now Sipser approved*
> >
> > No it's not, because he used the actual meaning of the words and not your weasel-worded definitions. Using the real definitions,
>
> *Professor Sipser has agreed to these verbatim words* (and no more)
> If simulating halt decider H correctly simulates its input D until H
> correctly determines that its simulated D would never stop running
> unless aborted then H can abort its simulation of D and correctly report
> that D specifies a non-halting sequence of configurations.
> *A paraphrase of a portion of the above paragraph*
> Would D correctly simulated by H ever stop running if not aborted?
>
> The answer of "no" is proved on page 3 of this paper.
>
> *Rebutting the Sipser Halting Problem Proof*
> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> *Still no rebuttal of page 3 because you know that page 3 is correct*

You still seem to think that because you have an H that partially computes the PO-halting function that it has anything to do with the halting function. It does not.

So anything that does not address whether the halting function is computable is irrelevant.

On 10/17/2022 10:47 AM, Dennis Bush wrote:
> On Monday, October 17, 2022 at 11:44:10 AM UTC-4, olcott wrote:
>> On 10/17/2022 10:40 AM, Dennis Bush wrote:
>>> On Monday, October 17, 2022 at 11:31:41 AM UTC-4, olcott wrote:
>>>> On 10/17/2022 10:16 AM, Dennis Bush wrote:
>>>>> On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
>>>>>> On 10/17/2022 9:49 AM, Dennis Bush wrote:
>>>>>>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
>>>>>>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
>>>>>>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
>>>>>>>>>> I have been following the discussions about Halt deciders with interest.
>>>>>>>>>> As a retired software designer and developer, I have a lot of practical
>>>>>>>>>> experience, but not much theoretical education, although the theoretical
>>>>>>>>>> background is very interesting. I learned a lot. I would like to verify
>>>>>>>>>> that I understand it correctly. Could you point out any errors in the
>>>>>>>>>> summary below?
>>>>>>>>>>
>>>>>>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
>>>>>>>>>> reaches its end condition after a finite number of steps. It does not
>>>>>>>>>> halt if it continues to execute infinitely.
>>>>>>>>>> (So, X(Y) either halts, or it does not halt.)
>>>>>>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
>>>>>>>>>> way, or by other means, e.g. an unhandled 'exception'.)
>>>>>>>>>>
>>>>>>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
>>>>>>>>>> given a program X with input Y decides, after a finite number of steps,
>>>>>>>>>> whether X(Y) halts or not.
>>>>>>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
>>>>>>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
>>>>>>>>>> convention, which could also be two other arbitrary values.)
>>>>>>>>>>
>>>>>>>>>> From 1 and 2 it follows:
>>>>>>>>>>
>>>>>>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
>>>>>>>>>> finite number of steps, it might return another interesting result, but
>>>>>>>>>> it is not a halt decider. (Not returning 1 includes returning other
>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>>>>>
>>>>>>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
>>>>>>>>>> in a finite number of steps, it might return another interesting result,
>>>>>>>>>> but it is not a halt decider. (Not returning 0 includes returning other
>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>>>>>
>>>>>>>>>> Paradoxical program:
>>>>>>>>>>
>>>>>>>>>> 5) It is always possible to construct a program P, that uses code with
>>>>>>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
>>>>>>>>>> (P does not necessarily need to use the exact same code as H does,
>>>>>>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
>>>>>>>>>>
>>>>>>>>>> From 5 it follows that a general halt decider that works for any X and
>>>>>>>>>> Y does not exist:
>>>>>>>>>>
>>>>>>>>>> From 3, 4 and 5 it follows:
>>>>>>>>>>
>>>>>>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
>>>>>>>>>> would not halt.
>>>>>>>>>>
>>>>>>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
>>>>>>>>>> would halt.
>>>>>>>>>>
>>>>>>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
>>>>>>>>>> then H is not a halt decider.
>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>>>>>> (It is irrelevant what causes P(P) to halt.)
>>>>>>>>>>
>>>>>>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
>>>>>>>>>> of steps, then H is not a halt decider.
>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>>>>>
>>>>>>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
>>>>>>>>>
>>>>>>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>
>>>>>>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
>>>>>>>>>
>>>>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
>>>>>>>> If simulating halt decider H correctly simulates its input D until H
>>>>>>>> correctly determines that its simulated D would never stop running
>>>>>>>> unless aborted then H can abort its simulation of D and correctly report
>>>>>>>> that D specifies a non-halting sequence of configurations.
>>>>>>>
>>>>>>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
>>>>>>>
>>>>>>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
>>>>>> I have proven an exception to this rule:
>>>>>
>>>>> That's not a rule. It's a definition.
>>>>>
>>>>>
>>>>>>
>>>>>> int Sipser_D(int (*M)())
>>>>>> {
>>>>>> if ( Sipser_H(M, M) )
>>>>>> return 0;
>>>>>> return 1;
>>>>>> }
>>>>>>
>>>>>> For the infinite set of H/D pairs:
>>>>>> Every correct simulation of D by H will never reach the final state of D
>>>>>> because D specifies recursive simulation to H.
>>>>>
>>>>> So in other words your Sipser_H is computing the PO-halting function:
>>>>>
>>>> *The PO-halting function is now Sipser approved*
>>>
>>> No it's not, because he used the actual meaning of the words and not your weasel-worded definitions. Using the real definitions,
>>
>> *Professor Sipser has agreed to these verbatim words* (and no more)
>> If simulating halt decider H correctly simulates its input D until H
>> correctly determines that its simulated D would never stop running
>> unless aborted then H can abort its simulation of D and correctly report
>> that D specifies a non-halting sequence of configurations.
>> *A paraphrase of a portion of the above paragraph*
>> Would D correctly simulated by H ever stop running if not aborted?
>>
>> The answer of "no" is proved on page 3 of this paper.
>>
>> *Rebutting the Sipser Halting Problem Proof*
>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>> *Still no rebuttal of page 3 because you know that page 3 is correct*
>
> You still seem to think that because you have an H that partially computes the PO-halting function that it has anything to do with the halting function. It does not.
>
> So anything that does not address whether the halting function is computable is irrelevant.

On 17/10/2022 13:43, Mikko wrote:
{Fred. Zwarts:]
>> Paradoxical program:
> Also called "pathological program"

Just an additional comment. The use of words such as
"paradoxical", "pathological", "impossible", ... conveys to the
unwary reader a notion that these programs are difficult, or
unreasonable, in some way. Not so; they are merely counter-
examples. *If* you claim to have a program "H" that [you claim]
is a "halt decider", *then*, sorry, your claim is incorrect, and
/here/ is a program "P" on which "H" fails [where "here" denotes
the standard "do the opposite" construction much discussed here].
There is [or should be!] no suggestion that there are not other
programs "H1", "H2", ... that analyse "P" correctly; but they in
turn have counter-examples "P1", "P2", ... that they get wrong
[and that perhaps the original "H" gets right].

It doesn't matter what the nature of "H" is; it can
simulate or signal to its heart's content, but there /will/
be programs for which "H" does not make a correct determination.
May be worth noting that Flibbles joke "SHD" is simply another
instance of a program [if he ever bothers to write it] that
correctly sometimes says "halts", sometimes says "doesn't halt"
and sometimes gives up; such programs have been known since the
earliest days of the HP.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Peerson

On Monday, October 17, 2022 at 11:57:18 AM UTC-4, olcott wrote:
> On 10/17/2022 10:47 AM, Dennis Bush wrote:
> > On Monday, October 17, 2022 at 11:44:10 AM UTC-4, olcott wrote:
> >> On 10/17/2022 10:40 AM, Dennis Bush wrote:
> >>> On Monday, October 17, 2022 at 11:31:41 AM UTC-4, olcott wrote:
> >>>> On 10/17/2022 10:16 AM, Dennis Bush wrote:
> >>>>> On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
> >>>>>> On 10/17/2022 9:49 AM, Dennis Bush wrote:
> >>>>>>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
> >>>>>>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
> >>>>>>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
> >>>>>>>>>> I have been following the discussions about Halt deciders with interest.
> >>>>>>>>>> As a retired software designer and developer, I have a lot of practical
> >>>>>>>>>> experience, but not much theoretical education, although the theoretical
> >>>>>>>>>> background is very interesting. I learned a lot. I would like to verify
> >>>>>>>>>> that I understand it correctly. Could you point out any errors in the
> >>>>>>>>>> summary below?
> >>>>>>>>>>
> >>>>>>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
> >>>>>>>>>> reaches its end condition after a finite number of steps. It does not
> >>>>>>>>>> halt if it continues to execute infinitely.
> >>>>>>>>>> (So, X(Y) either halts, or it does not halt.)
> >>>>>>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
> >>>>>>>>>> way, or by other means, e.g. an unhandled 'exception'.)
> >>>>>>>>>>
> >>>>>>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
> >>>>>>>>>> given a program X with input Y decides, after a finite number of steps,
> >>>>>>>>>> whether X(Y) halts or not.
> >>>>>>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
> >>>>>>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> >>>>>>>>>> convention, which could also be two other arbitrary values.)
> >>>>>>>>>>
> >>>>>>>>>> From 1 and 2 it follows:
> >>>>>>>>>>
> >>>>>>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> >>>>>>>>>> finite number of steps, it might return another interesting result, but
> >>>>>>>>>> it is not a halt decider. (Not returning 1 includes returning other
> >>>>>>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>>>>>
> >>>>>>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> >>>>>>>>>> in a finite number of steps, it might return another interesting result,
> >>>>>>>>>> but it is not a halt decider. (Not returning 0 includes returning other
> >>>>>>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>>>>>
> >>>>>>>>>> Paradoxical program:
> >>>>>>>>>>
> >>>>>>>>>> 5) It is always possible to construct a program P, that uses code with
> >>>>>>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
> >>>>>>>>>> (P does not necessarily need to use the exact same code as H does,
> >>>>>>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
> >>>>>>>>>>
> >>>>>>>>>> From 5 it follows that a general halt decider that works for any X and
> >>>>>>>>>> Y does not exist:
> >>>>>>>>>>
> >>>>>>>>>> From 3, 4 and 5 it follows:
> >>>>>>>>>>
> >>>>>>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> >>>>>>>>>> would not halt.
> >>>>>>>>>>
> >>>>>>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> >>>>>>>>>> would halt.
> >>>>>>>>>>
> >>>>>>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> >>>>>>>>>> then H is not a halt decider.
> >>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>>>>>> (It is irrelevant what causes P(P) to halt.)
> >>>>>>>>>>
> >>>>>>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
> >>>>>>>>>> of steps, then H is not a halt decider.
> >>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>>>>>
> >>>>>>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
> >>>>>>>>>
> >>>>>>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
> >>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>
> >>>>>>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
> >>>>>>>>>
> >>>>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
> >>>>>>>> If simulating halt decider H correctly simulates its input D until H
> >>>>>>>> correctly determines that its simulated D would never stop running
> >>>>>>>> unless aborted then H can abort its simulation of D and correctly report
> >>>>>>>> that D specifies a non-halting sequence of configurations.
> >>>>>>>
> >>>>>>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
> >>>>>>>
> >>>>>>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
> >>>>>> I have proven an exception to this rule:
> >>>>>
> >>>>> That's not a rule. It's a definition.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> int Sipser_D(int (*M)())
> >>>>>> {
> >>>>>> if ( Sipser_H(M, M) )
> >>>>>> return 0;
> >>>>>> return 1;
> >>>>>> }
> >>>>>>
> >>>>>> For the infinite set of H/D pairs:
> >>>>>> Every correct simulation of D by H will never reach the final state of D
> >>>>>> because D specifies recursive simulation to H.
> >>>>>
> >>>>> So in other words your Sipser_H is computing the PO-halting function:
> >>>>>
> >>>> *The PO-halting function is now Sipser approved*
> >>>
> >>> No it's not, because he used the actual meaning of the words and not your weasel-worded definitions. Using the real definitions,
> >>
> >> *Professor Sipser has agreed to these verbatim words* (and no more)
> >> If simulating halt decider H correctly simulates its input D until H
> >> correctly determines that its simulated D would never stop running
> >> unless aborted then H can abort its simulation of D and correctly report
> >> that D specifies a non-halting sequence of configurations.
> >> *A paraphrase of a portion of the above paragraph*
> >> Would D correctly simulated by H ever stop running if not aborted?
> >>
> >> The answer of "no" is proved on page 3 of this paper.
> >>
> >> *Rebutting the Sipser Halting Problem Proof*
> >> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >> *Still no rebuttal of page 3 because you know that page 3 is correct*
> >
> > You still seem to think that because you have an H that partially computes the PO-halting function that it has anything to do with the halting function. It does not.
> >
> > So anything that does not address whether the halting function is computable is irrelevant.
> Anyone that is sufficiently technically competent can verify that H does
> correctly determine the halt status of D correctly simulated by H.

On 10/17/2022 11:00 AM, Andy Walker wrote:
> On 17/10/2022 13:43, Mikko wrote:
> {Fred. Zwarts:]
>>> Paradoxical program:
>> Also called "pathological program"
>
>     Just an additional comment.  The use of words such as
> "paradoxical", "pathological", "impossible", ... conveys to the
> unwary reader a notion that these programs are difficult, or
> unreasonable, in some way.  Not so;  they are merely counter-
> examples.  *If* you claim to have a program "H" that [you claim]
> is a "halt decider", *then*, sorry, your claim is incorrect, and
> /here/ is a program "P" on which "H" fails [where "here" denotes
> the standard "do the opposite" construction much discussed here].

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

The above notion of a simulating halt decider defeats this "do the
opposite" construction as proven on page 3:

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 10/17/2022 11:00 AM, Dennis Bush wrote:
> On Monday, October 17, 2022 at 11:57:18 AM UTC-4, olcott wrote:
>> On 10/17/2022 10:47 AM, Dennis Bush wrote:
>>> On Monday, October 17, 2022 at 11:44:10 AM UTC-4, olcott wrote:
>>>> On 10/17/2022 10:40 AM, Dennis Bush wrote:
>>>>> On Monday, October 17, 2022 at 11:31:41 AM UTC-4, olcott wrote:
>>>>>> On 10/17/2022 10:16 AM, Dennis Bush wrote:
>>>>>>> On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
>>>>>>>> On 10/17/2022 9:49 AM, Dennis Bush wrote:
>>>>>>>>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
>>>>>>>>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
>>>>>>>>>>>> I have been following the discussions about Halt deciders with interest.
>>>>>>>>>>>> As a retired software designer and developer, I have a lot of practical
>>>>>>>>>>>> experience, but not much theoretical education, although the theoretical
>>>>>>>>>>>> background is very interesting. I learned a lot. I would like to verify
>>>>>>>>>>>> that I understand it correctly. Could you point out any errors in the
>>>>>>>>>>>> summary below?
>>>>>>>>>>>>
>>>>>>>>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
>>>>>>>>>>>> reaches its end condition after a finite number of steps. It does not
>>>>>>>>>>>> halt if it continues to execute infinitely.
>>>>>>>>>>>> (So, X(Y) either halts, or it does not halt.)
>>>>>>>>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
>>>>>>>>>>>> way, or by other means, e.g. an unhandled 'exception'.)
>>>>>>>>>>>>
>>>>>>>>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
>>>>>>>>>>>> given a program X with input Y decides, after a finite number of steps,
>>>>>>>>>>>> whether X(Y) halts or not.
>>>>>>>>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
>>>>>>>>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
>>>>>>>>>>>> convention, which could also be two other arbitrary values.)
>>>>>>>>>>>>
>>>>>>>>>>>> From 1 and 2 it follows:
>>>>>>>>>>>>
>>>>>>>>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
>>>>>>>>>>>> finite number of steps, it might return another interesting result, but
>>>>>>>>>>>> it is not a halt decider. (Not returning 1 includes returning other
>>>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>>>>>>>
>>>>>>>>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
>>>>>>>>>>>> in a finite number of steps, it might return another interesting result,
>>>>>>>>>>>> but it is not a halt decider. (Not returning 0 includes returning other
>>>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>>>>>>>
>>>>>>>>>>>> Paradoxical program:
>>>>>>>>>>>>
>>>>>>>>>>>> 5) It is always possible to construct a program P, that uses code with
>>>>>>>>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
>>>>>>>>>>>> (P does not necessarily need to use the exact same code as H does,
>>>>>>>>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
>>>>>>>>>>>>
>>>>>>>>>>>> From 5 it follows that a general halt decider that works for any X and
>>>>>>>>>>>> Y does not exist:
>>>>>>>>>>>>
>>>>>>>>>>>> From 3, 4 and 5 it follows:
>>>>>>>>>>>>
>>>>>>>>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
>>>>>>>>>>>> would not halt.
>>>>>>>>>>>>
>>>>>>>>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
>>>>>>>>>>>> would halt.
>>>>>>>>>>>>
>>>>>>>>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
>>>>>>>>>>>> then H is not a halt decider.
>>>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>>>>>>>> (It is irrelevant what causes P(P) to halt.)
>>>>>>>>>>>>
>>>>>>>>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
>>>>>>>>>>>> of steps, then H is not a halt decider.
>>>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>>>>>>>
>>>>>>>>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
>>>>>>>>>>>
>>>>>>>>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>
>>>>>>>>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
>>>>>>>>>>>
>>>>>>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
>>>>>>>>>> If simulating halt decider H correctly simulates its input D until H
>>>>>>>>>> correctly determines that its simulated D would never stop running
>>>>>>>>>> unless aborted then H can abort its simulation of D and correctly report
>>>>>>>>>> that D specifies a non-halting sequence of configurations.
>>>>>>>>>
>>>>>>>>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
>>>>>>>>>
>>>>>>>>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
>>>>>>>> I have proven an exception to this rule:
>>>>>>>
>>>>>>> That's not a rule. It's a definition.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> int Sipser_D(int (*M)())
>>>>>>>> {
>>>>>>>> if ( Sipser_H(M, M) )
>>>>>>>> return 0;
>>>>>>>> return 1;
>>>>>>>> }
>>>>>>>>
>>>>>>>> For the infinite set of H/D pairs:
>>>>>>>> Every correct simulation of D by H will never reach the final state of D
>>>>>>>> because D specifies recursive simulation to H.
>>>>>>>
>>>>>>> So in other words your Sipser_H is computing the PO-halting function:
>>>>>>>
>>>>>> *The PO-halting function is now Sipser approved*
>>>>>
>>>>> No it's not, because he used the actual meaning of the words and not your weasel-worded definitions. Using the real definitions,
>>>>
>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
>>>> If simulating halt decider H correctly simulates its input D until H
>>>> correctly determines that its simulated D would never stop running
>>>> unless aborted then H can abort its simulation of D and correctly report
>>>> that D specifies a non-halting sequence of configurations.
>>>> *A paraphrase of a portion of the above paragraph*
>>>> Would D correctly simulated by H ever stop running if not aborted?
>>>>
>>>> The answer of "no" is proved on page 3 of this paper.
>>>>
>>>> *Rebutting the Sipser Halting Problem Proof*
>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>> *Still no rebuttal of page 3 because you know that page 3 is correct*
>>>
>>> You still seem to think that because you have an H that partially computes the PO-halting function that it has anything to do with the halting function. It does not.
>>>
>>> So anything that does not address whether the halting function is computable is irrelevant.
>> Anyone that is sufficiently technically competent can verify that H does
>> correctly determine the halt status of D correctly simulated by H.
>
> No one is denying that you're able to compute a subset of the PO-halting function. The halting problem proofs are about the halting function.
>
>>
>> This proves that the conventional proofs that rely on D doing the
>> opposite of whatever H decides have been refuted by the notion of a
>> simulating halt decider.
>
> The conventional proofs are making claims about the halting function, not the PO-halting function, therefore claims about the PO-halting function are irrelevant.

On Monday, October 17, 2022 at 12:15:27 PM UTC-4, olcott wrote:
> On 10/17/2022 11:00 AM, Dennis Bush wrote:
> > On Monday, October 17, 2022 at 11:57:18 AM UTC-4, olcott wrote:
> >> On 10/17/2022 10:47 AM, Dennis Bush wrote:
> >>> On Monday, October 17, 2022 at 11:44:10 AM UTC-4, olcott wrote:
> >>>> On 10/17/2022 10:40 AM, Dennis Bush wrote:
> >>>>> On Monday, October 17, 2022 at 11:31:41 AM UTC-4, olcott wrote:
> >>>>>> On 10/17/2022 10:16 AM, Dennis Bush wrote:
> >>>>>>> On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
> >>>>>>>> On 10/17/2022 9:49 AM, Dennis Bush wrote:
> >>>>>>>>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
> >>>>>>>>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
> >>>>>>>>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
> >>>>>>>>>>>> I have been following the discussions about Halt deciders with interest.
> >>>>>>>>>>>> As a retired software designer and developer, I have a lot of practical
> >>>>>>>>>>>> experience, but not much theoretical education, although the theoretical
> >>>>>>>>>>>> background is very interesting. I learned a lot. I would like to verify
> >>>>>>>>>>>> that I understand it correctly. Could you point out any errors in the
> >>>>>>>>>>>> summary below?
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
> >>>>>>>>>>>> reaches its end condition after a finite number of steps. It does not
> >>>>>>>>>>>> halt if it continues to execute infinitely.
> >>>>>>>>>>>> (So, X(Y) either halts, or it does not halt.)
> >>>>>>>>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
> >>>>>>>>>>>> way, or by other means, e.g. an unhandled 'exception'.)
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
> >>>>>>>>>>>> given a program X with input Y decides, after a finite number of steps,
> >>>>>>>>>>>> whether X(Y) halts or not.
> >>>>>>>>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
> >>>>>>>>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> >>>>>>>>>>>> convention, which could also be two other arbitrary values.)
> >>>>>>>>>>>>
> >>>>>>>>>>>> From 1 and 2 it follows:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> >>>>>>>>>>>> finite number of steps, it might return another interesting result, but
> >>>>>>>>>>>> it is not a halt decider. (Not returning 1 includes returning other
> >>>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>>>>>>>
> >>>>>>>>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> >>>>>>>>>>>> in a finite number of steps, it might return another interesting result,
> >>>>>>>>>>>> but it is not a halt decider. (Not returning 0 includes returning other
> >>>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Paradoxical program:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 5) It is always possible to construct a program P, that uses code with
> >>>>>>>>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
> >>>>>>>>>>>> (P does not necessarily need to use the exact same code as H does,
> >>>>>>>>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
> >>>>>>>>>>>>
> >>>>>>>>>>>> From 5 it follows that a general halt decider that works for any X and
> >>>>>>>>>>>> Y does not exist:
> >>>>>>>>>>>>
> >>>>>>>>>>>> From 3, 4 and 5 it follows:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> >>>>>>>>>>>> would not halt.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> >>>>>>>>>>>> would halt.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> >>>>>>>>>>>> then H is not a halt decider.
> >>>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>>>>>>>> (It is irrelevant what causes P(P) to halt.)
> >>>>>>>>>>>>
> >>>>>>>>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
> >>>>>>>>>>>> of steps, then H is not a halt decider.
> >>>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>>>>>>>
> >>>>>>>>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
> >>>>>>>>>>>
> >>>>>>>>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
> >>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>
> >>>>>>>>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
> >>>>>>>>>>>
> >>>>>>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
> >>>>>>>>>> If simulating halt decider H correctly simulates its input D until H
> >>>>>>>>>> correctly determines that its simulated D would never stop running
> >>>>>>>>>> unless aborted then H can abort its simulation of D and correctly report
> >>>>>>>>>> that D specifies a non-halting sequence of configurations.
> >>>>>>>>>
> >>>>>>>>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
> >>>>>>>>>
> >>>>>>>>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
> >>>>>>>> I have proven an exception to this rule:
> >>>>>>>
> >>>>>>> That's not a rule. It's a definition.
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> int Sipser_D(int (*M)())
> >>>>>>>> {
> >>>>>>>> if ( Sipser_H(M, M) )
> >>>>>>>> return 0;
> >>>>>>>> return 1;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> For the infinite set of H/D pairs:
> >>>>>>>> Every correct simulation of D by H will never reach the final state of D
> >>>>>>>> because D specifies recursive simulation to H.
> >>>>>>>
> >>>>>>> So in other words your Sipser_H is computing the PO-halting function:
> >>>>>>>
> >>>>>> *The PO-halting function is now Sipser approved*
> >>>>>
> >>>>> No it's not, because he used the actual meaning of the words and not your weasel-worded definitions. Using the real definitions,
> >>>>
> >>>> *Professor Sipser has agreed to these verbatim words* (and no more)
> >>>> If simulating halt decider H correctly simulates its input D until H
> >>>> correctly determines that its simulated D would never stop running
> >>>> unless aborted then H can abort its simulation of D and correctly report
> >>>> that D specifies a non-halting sequence of configurations.
> >>>> *A paraphrase of a portion of the above paragraph*
> >>>> Would D correctly simulated by H ever stop running if not aborted?
> >>>>
> >>>> The answer of "no" is proved on page 3 of this paper.
> >>>>
> >>>> *Rebutting the Sipser Halting Problem Proof*
> >>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>> *Still no rebuttal of page 3 because you know that page 3 is correct*
> >>>
> >>> You still seem to think that because you have an H that partially computes the PO-halting function that it has anything to do with the halting function. It does not.
> >>>
> >>> So anything that does not address whether the halting function is computable is irrelevant.
> >> Anyone that is sufficiently technically competent can verify that H does
> >> correctly determine the halt status of D correctly simulated by H.
> >
> > No one is denying that you're able to compute a subset of the PO-halting function. The halting problem proofs are about the halting function.
> >
> >>
> >> This proves that the conventional proofs that rely on D doing the
> >> opposite of whatever H decides have been refuted by the notion of a
> >> simulating halt decider.
> >
> > The conventional proofs are making claims about the halting function, not the PO-halting function, therefore claims about the PO-halting function are irrelevant.
>
> [ repeat of previously refuted statement ]
>
> int Sipser_D(int (*M)())
> {
> if ( Sipser_H(M, M) )
> return 0;
> return 1;
> }
> This notion of a simulating halt decider is proven to correctly
> determine the halt status of Sipser_D by Sipser_H.
> *Rebutting the Sipser Halting Problem Proof*
> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

On 10/17/2022 11:25 AM, Dennis Bush wrote:
> On Monday, October 17, 2022 at 12:15:27 PM UTC-4, olcott wrote:
>> On 10/17/2022 11:00 AM, Dennis Bush wrote:
>>> On Monday, October 17, 2022 at 11:57:18 AM UTC-4, olcott wrote:
>>>> On 10/17/2022 10:47 AM, Dennis Bush wrote:
>>>>> On Monday, October 17, 2022 at 11:44:10 AM UTC-4, olcott wrote:
>>>>>> On 10/17/2022 10:40 AM, Dennis Bush wrote:
>>>>>>> On Monday, October 17, 2022 at 11:31:41 AM UTC-4, olcott wrote:
>>>>>>>> On 10/17/2022 10:16 AM, Dennis Bush wrote:
>>>>>>>>> On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
>>>>>>>>>> On 10/17/2022 9:49 AM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
>>>>>>>>>>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
>>>>>>>>>>>>>> I have been following the discussions about Halt deciders with interest.
>>>>>>>>>>>>>> As a retired software designer and developer, I have a lot of practical
>>>>>>>>>>>>>> experience, but not much theoretical education, although the theoretical
>>>>>>>>>>>>>> background is very interesting. I learned a lot. I would like to verify
>>>>>>>>>>>>>> that I understand it correctly. Could you point out any errors in the
>>>>>>>>>>>>>> summary below?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
>>>>>>>>>>>>>> reaches its end condition after a finite number of steps. It does not
>>>>>>>>>>>>>> halt if it continues to execute infinitely.
>>>>>>>>>>>>>> (So, X(Y) either halts, or it does not halt.)
>>>>>>>>>>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
>>>>>>>>>>>>>> way, or by other means, e.g. an unhandled 'exception'.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
>>>>>>>>>>>>>> given a program X with input Y decides, after a finite number of steps,
>>>>>>>>>>>>>> whether X(Y) halts or not.
>>>>>>>>>>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
>>>>>>>>>>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
>>>>>>>>>>>>>> convention, which could also be two other arbitrary values.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From 1 and 2 it follows:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
>>>>>>>>>>>>>> finite number of steps, it might return another interesting result, but
>>>>>>>>>>>>>> it is not a halt decider. (Not returning 1 includes returning other
>>>>>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
>>>>>>>>>>>>>> in a finite number of steps, it might return another interesting result,
>>>>>>>>>>>>>> but it is not a halt decider. (Not returning 0 includes returning other
>>>>>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Paradoxical program:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 5) It is always possible to construct a program P, that uses code with
>>>>>>>>>>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
>>>>>>>>>>>>>> (P does not necessarily need to use the exact same code as H does,
>>>>>>>>>>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From 5 it follows that a general halt decider that works for any X and
>>>>>>>>>>>>>> Y does not exist:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> From 3, 4 and 5 it follows:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
>>>>>>>>>>>>>> would not halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
>>>>>>>>>>>>>> would halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
>>>>>>>>>>>>>> then H is not a halt decider.
>>>>>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>>>>>>>>>> (It is irrelevant what causes P(P) to halt.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
>>>>>>>>>>>>>> of steps, then H is not a halt decider.
>>>>>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
>>>>>>>>>>>>>
>>>>>>>>>>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
>>>>>>>>>>>>>
>>>>>>>>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
>>>>>>>>>>>> If simulating halt decider H correctly simulates its input D until H
>>>>>>>>>>>> correctly determines that its simulated D would never stop running
>>>>>>>>>>>> unless aborted then H can abort its simulation of D and correctly report
>>>>>>>>>>>> that D specifies a non-halting sequence of configurations.
>>>>>>>>>>>
>>>>>>>>>>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
>>>>>>>>>>>
>>>>>>>>>>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
>>>>>>>>>> I have proven an exception to this rule:
>>>>>>>>>
>>>>>>>>> That's not a rule. It's a definition.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> int Sipser_D(int (*M)())
>>>>>>>>>> {
>>>>>>>>>> if ( Sipser_H(M, M) )
>>>>>>>>>> return 0;
>>>>>>>>>> return 1;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> For the infinite set of H/D pairs:
>>>>>>>>>> Every correct simulation of D by H will never reach the final state of D
>>>>>>>>>> because D specifies recursive simulation to H.
>>>>>>>>>
>>>>>>>>> So in other words your Sipser_H is computing the PO-halting function:
>>>>>>>>>
>>>>>>>> *The PO-halting function is now Sipser approved*
>>>>>>>
>>>>>>> No it's not, because he used the actual meaning of the words and not your weasel-worded definitions. Using the real definitions,
>>>>>>
>>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
>>>>>> If simulating halt decider H correctly simulates its input D until H
>>>>>> correctly determines that its simulated D would never stop running
>>>>>> unless aborted then H can abort its simulation of D and correctly report
>>>>>> that D specifies a non-halting sequence of configurations.
>>>>>> *A paraphrase of a portion of the above paragraph*
>>>>>> Would D correctly simulated by H ever stop running if not aborted?
>>>>>>
>>>>>> The answer of "no" is proved on page 3 of this paper.
>>>>>>
>>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>>> *Still no rebuttal of page 3 because you know that page 3 is correct*
>>>>>
>>>>> You still seem to think that because you have an H that partially computes the PO-halting function that it has anything to do with the halting function. It does not.
>>>>>
>>>>> So anything that does not address whether the halting function is computable is irrelevant.
>>>> Anyone that is sufficiently technically competent can verify that H does
>>>> correctly determine the halt status of D correctly simulated by H.
>>>
>>> No one is denying that you're able to compute a subset of the PO-halting function. The halting problem proofs are about the halting function.
>>>
>>>>
>>>> This proves that the conventional proofs that rely on D doing the
>>>> opposite of whatever H decides have been refuted by the notion of a
>>>> simulating halt decider.
>>>
>>> The conventional proofs are making claims about the halting function, not the PO-halting function, therefore claims about the PO-halting function are irrelevant.
>>
>> [ repeat of previously refuted statement ]
>>
>> int Sipser_D(int (*M)())
>> {
>> if ( Sipser_H(M, M) )
>> return 0;
>> return 1;
>> }
>> This notion of a simulating halt decider is proven to correctly
>> determine the halt status of Sipser_D by Sipser_H.
>> *Rebutting the Sipser Halting Problem Proof*
>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>
> In other words, you can compute a subset of the PO-halting function. And since the halting problem proofs make claims about the halting function, claims about the PO-halting function are irrelevant.

On Monday, October 17, 2022 at 12:29:34 PM UTC-4, olcott wrote:
> On 10/17/2022 11:25 AM, Dennis Bush wrote:
> > On Monday, October 17, 2022 at 12:15:27 PM UTC-4, olcott wrote:
> >> On 10/17/2022 11:00 AM, Dennis Bush wrote:
> >>> On Monday, October 17, 2022 at 11:57:18 AM UTC-4, olcott wrote:
> >>>> On 10/17/2022 10:47 AM, Dennis Bush wrote:
> >>>>> On Monday, October 17, 2022 at 11:44:10 AM UTC-4, olcott wrote:
> >>>>>> On 10/17/2022 10:40 AM, Dennis Bush wrote:
> >>>>>>> On Monday, October 17, 2022 at 11:31:41 AM UTC-4, olcott wrote:
> >>>>>>>> On 10/17/2022 10:16 AM, Dennis Bush wrote:
> >>>>>>>>> On Monday, October 17, 2022 at 11:06:45 AM UTC-4, olcott wrote:
> >>>>>>>>>> On 10/17/2022 9:49 AM, Dennis Bush wrote:
> >>>>>>>>>>> On Monday, October 17, 2022 at 10:38:09 AM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 10/17/2022 7:47 AM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Monday, October 17, 2022 at 5:30:59 AM UTC-4, Fred. Zwarts wrote:
> >>>>>>>>>>>>>> I have been following the discussions about Halt deciders with interest.
> >>>>>>>>>>>>>> As a retired software designer and developer, I have a lot of practical
> >>>>>>>>>>>>>> experience, but not much theoretical education, although the theoretical
> >>>>>>>>>>>>>> background is very interesting. I learned a lot. I would like to verify
> >>>>>>>>>>>>>> that I understand it correctly. Could you point out any errors in the
> >>>>>>>>>>>>>> summary below?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 1) (Definition of halt) A program X with input Y is said to halt if it
> >>>>>>>>>>>>>> reaches its end condition after a finite number of steps. It does not
> >>>>>>>>>>>>>> halt if it continues to execute infinitely.
> >>>>>>>>>>>>>> (So, X(Y) either halts, or it does not halt.)
> >>>>>>>>>>>>>> (It is irrelevant whether the end condition is reached in the 'normal'
> >>>>>>>>>>>>>> way, or by other means, e.g. an unhandled 'exception'.)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2) (Definition of halt decider) A halt decider H is a program that,
> >>>>>>>>>>>>>> given a program X with input Y decides, after a finite number of steps,
> >>>>>>>>>>>>>> whether X(Y) halts or not.
> >>>>>>>>>>>>>> (H(X,Y) itself must halt after a finite number of steps. It must return
> >>>>>>>>>>>>>> either 1 if X(Y) halts, or 0 if X(Y) does not halt, where 1 and 0 are a
> >>>>>>>>>>>>>> convention, which could also be two other arbitrary values.)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> From 1 and 2 it follows:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 3) If X(Y) halts, then H must return 1. If H does not return 1 in a
> >>>>>>>>>>>>>> finite number of steps, it might return another interesting result, but
> >>>>>>>>>>>>>> it is not a halt decider. (Not returning 1 includes returning other
> >>>>>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 4) If X(Y) does not halt, then H must return 0. If it does not return 0
> >>>>>>>>>>>>>> in a finite number of steps, it might return another interesting result,
> >>>>>>>>>>>>>> but it is not a halt decider. (Not returning 0 includes returning other
> >>>>>>>>>>>>>> values, not halting, or throwing 'exceptions'.)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Paradoxical program:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 5) It is always possible to construct a program P, that uses code with
> >>>>>>>>>>>>>> the same logic as H, in order to do the opposite of what H(P,P) returns.
> >>>>>>>>>>>>>> (P does not necessarily need to use the exact same code as H does,
> >>>>>>>>>>>>>> amongst others it could use a modified copy of H, or a simulation of H.)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> From 5 it follows that a general halt decider that works for any X and
> >>>>>>>>>>>>>> Y does not exist:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> From 3, 4 and 5 it follows:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 6) If P(P) halts, then H should return 1, but if H would do so, P(P)
> >>>>>>>>>>>>>> would not halt.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 7) If P(P) does not halt, H should return 0, but if H would do so, P(P)
> >>>>>>>>>>>>>> would halt.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 8) If P(P) halts and H does not return 1 after a finite number of steps,
> >>>>>>>>>>>>>> then H is not a halt decider.
> >>>>>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>>>>>>>>>> (It is irrelevant what causes P(P) to halt.)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 9) If P(P) does not halt and H does not return 0 after a finite number
> >>>>>>>>>>>>>> of steps, then H is not a halt decider.
> >>>>>>>>>>>>>> (The result could nevertheless be interesting for other purposes.)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Your understanding is correct. To sum things up, the halting function (using the mathematical notion of a function), performs the following mapping:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For *any* algorithm (i.e. a fixed immutable sequence of instructions) X and input Y:
> >>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> And the halting problem proofs show that this mapping is not computable, i.e. it is impossible for an algorithm to compute this mapping.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
> >>>>>>>>>>>> If simulating halt decider H correctly simulates its input D until H
> >>>>>>>>>>>> correctly determines that its simulated D would never stop running
> >>>>>>>>>>>> unless aborted then H can abort its simulation of D and correctly report
> >>>>>>>>>>>> that D specifies a non-halting sequence of configurations.
> >>>>>>>>>>>
> >>>>>>>>>>> And he agreed to those words based on their commonly known meanings, not your alternate weasel-word meanings.
> >>>>>>>>>>>
> >>>>>>>>>>> The conventional definition of "correctly simulating" means that the simulated behavior EXACTLY matches the behavior of direct execution.
> >>>>>>>>>> I have proven an exception to this rule:
> >>>>>>>>>
> >>>>>>>>> That's not a rule. It's a definition.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> int Sipser_D(int (*M)())
> >>>>>>>>>> {
> >>>>>>>>>> if ( Sipser_H(M, M) )
> >>>>>>>>>> return 0;
> >>>>>>>>>> return 1;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> For the infinite set of H/D pairs:
> >>>>>>>>>> Every correct simulation of D by H will never reach the final state of D
> >>>>>>>>>> because D specifies recursive simulation to H.
> >>>>>>>>>
> >>>>>>>>> So in other words your Sipser_H is computing the PO-halting function:
> >>>>>>>>>
> >>>>>>>> *The PO-halting function is now Sipser approved*
> >>>>>>>
> >>>>>>> No it's not, because he used the actual meaning of the words and not your weasel-worded definitions. Using the real definitions,
> >>>>>>
> >>>>>> *Professor Sipser has agreed to these verbatim words* (and no more)
> >>>>>> If simulating halt decider H correctly simulates its input D until H
> >>>>>> correctly determines that its simulated D would never stop running
> >>>>>> unless aborted then H can abort its simulation of D and correctly report
> >>>>>> that D specifies a non-halting sequence of configurations.
> >>>>>> *A paraphrase of a portion of the above paragraph*
> >>>>>> Would D correctly simulated by H ever stop running if not aborted?
> >>>>>>
> >>>>>> The answer of "no" is proved on page 3 of this paper.
> >>>>>>
> >>>>>> *Rebutting the Sipser Halting Problem Proof*
> >>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>>>> *Still no rebuttal of page 3 because you know that page 3 is correct*
> >>>>>
> >>>>> You still seem to think that because you have an H that partially computes the PO-halting function that it has anything to do with the halting function. It does not.
> >>>>>
> >>>>> So anything that does not address whether the halting function is computable is irrelevant.
> >>>> Anyone that is sufficiently technically competent can verify that H does
> >>>> correctly determine the halt status of D correctly simulated by H.
> >>>
> >>> No one is denying that you're able to compute a subset of the PO-halting function. The halting problem proofs are about the halting function.
> >>>
> >>>>
> >>>> This proves that the conventional proofs that rely on D doing the
> >>>> opposite of whatever H decides have been refuted by the notion of a
> >>>> simulating halt decider.
> >>>
> >>> The conventional proofs are making claims about the halting function, not the PO-halting function, therefore claims about the PO-halting function are irrelevant.
> >>
> >> [ repeat of previously refuted statement ]
> >>
> >> int Sipser_D(int (*M)())
> >> {
> >> if ( Sipser_H(M, M) )
> >> return 0;
> >> return 1;
> >> }
> >> This notion of a simulating halt decider is proven to correctly
> >> determine the halt status of Sipser_D by Sipser_H.
> >> *Rebutting the Sipser Halting Problem Proof*
> >> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >
> > In other words, you can compute a subset of the PO-halting function. And since the halting problem proofs make claims about the halting function, claims about the PO-halting function are irrelevant.
> The halting problem proofs make claims about the halting function on the
> basis that the halt status of Sipser_D cannot be correctly determined by
> Sipser_H.

Demented kook Peter Olcott wrote:
> On 10/17/2022 11:25 AM, Dennis Bush wrote:
....
>> In other words, you can compute a subset of the PO-halting function.
>> And since the halting problem proofs make claims about the halting
>> function, claims about the PO-halting function are irrelevant.
>
> The halting problem proofs make claims about the halting function on the
> basis that the halt status of Sipser_D cannot be correctly determined by
> Sipser_H. The notion of a simulating halt decider removes that basis
> thus causing all of these conventional proofs to fail.
>

So now you're only claiming that you only have a "partial" halt
decider... LOL.

Whatever, this "partial halt-decider" does not simulates properly
its problematic argument (the D built on it) and MOREOVER fail to
properly state if this argument halts or not when executed.

H(D,D) returns 0 (non-halting) while D(D), when actually ran, halts.

None of your attempts to obfuscate the subject can change that.