#include <stdint.h>
typedef void (*ptr)();

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
int P(ptr x)
{ H(x, x);
return 1;
}

int main(void)
{ H(P, P);
}

We can determine the behavior of the input to H(P,P) for an infinite set
of different definitions of H by using categorically exhaustively
complete reasoning. There are only four categories of possible
definitions for H:

(1) H(P,P) simply executes its input: main() calls H(P,P) that calls
P(P) that calls H(P,P)...
(2) H(P,P) simulates its input.
(3) H(P,P) executes its input** and aborts this execution at some point.
**(a debugger could be used).
(4) H(P,P) simulates its input and aborts this simulation at some point.

Case (1) (complete source code is provided above) shows that P never
reaches its last instruction.
Case (2) a correct simulation of the input to H(P,P) must have
equivalent behavior to case (1).
Case (3) and (4) any sub-sequence of (1) and (2) can't have instructions
not included in (1) or (2).
Thus for cases (1)(2)(3)(4) P never reaches its last instruction.

For every H that
simulates or
executes its input and
aborts or
does not abort its input
P never reaches its last instruction.

--
Copyright 2021 Pete Olcott

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

On 11/17/21 10:24 AM, olcott wrote:
> #include <stdint.h>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y);  // direct execution of P(P)
>   return 1;
> }
>
> // Minimal essence of Linz(1990) Ĥ
> // and Strachey(1965) P
> int P(ptr x)
> {
>   H(x, x);
>   return 1;
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
> We can determine the behavior of the input to H(P,P) for an infinite set
> of different definitions of H by using categorically exhaustively
> complete reasoning. There are only four categories of possible
> definitions for H:
>
> (1) H(P,P) simply executes its input: main() calls H(P,P) that calls
> P(P) that calls H(P,P)...
> (2) H(P,P) simulates its input.
> (3) H(P,P) executes its input** and aborts this execution at some point.
>  **(a debugger could be used).
> (4) H(P,P) simulates its input and aborts this simulation at some point.
>
> Case (1) (complete source code is provided above) shows that P never
> reaches its last instruction.

WRONG, case 1 shows that for H1 defined as above, that the corresponding
P1(P1) will be non-halting,, but H1(P1,P1) never gives an answer.

Since P's behavor is affected by the behavior of H, we can NOT extend
that fact to ANY other H.

> Case (2) a correct simulation of the input to H(P,P) must have
> equivalent behavior to case (1).

Since Pure Simulation is by defintion the equivalent of direct
execution, yes, this one will be the same.

Note, This is a SPECIAL case, as ONLY Pure Simulation is the equivalent
of direct exectution.

> Case (3) and (4) any sub-sequence of (1) and (2) can't have instructions
> not included in (1) or (2).

WRONG. H can't see the exectution of any other instruction, but the
actual execution of P can, and does. FAIL.

When H aborts its exection and returns, this means that for HALTING
PROBLEM puroses where we NEED to look at the ACTUAL behavior of P, the
DIRECT execution of P(P) will show that it halts.

For exampple H0(P3,P3) will show H1 calling P3(P3), then P3 calls
H3(P3,P3), which debug steps through another execution layer of P3, sees
that call H3(P3,P2), aborts its simulation of that second layer of P3,
and return the value 0 to that first layer of P3, which will then return
to H1 and thus H1, which DOES correctly execute its input sees that
P3(P3) is halting and H3 got the wrong answer.

We can do similer for H2(P3,P3), H1(P4,P4) and H2(P4,P4).

H1 and H2 being direct execution and pure simulation will properly show
the behavior of their inputs, and show that H3 and H4 are incorrret in
their decisions.

> Thus for cases (1)(2)(3)(4) P never reaches its last instruction.

Nope, H never sees the reaching of the last instruction, which if that
is what you mean, you are correct, but then that is a a SO WHAT, as that
is NOT the definition of Halting.

If you mean the ACTUAL execution, you are incorret.

>
> For every H that
> simulates or
> executes its input and
> aborts or
> does not abort its input
> P never reaches its last instruction.
>

See above. You are LYING by that statement with the implication that it
means something about halting.

If you mean that the processing of H doesn't reach the last instruction,
then you are LYING about that saying anything about Halting.

If you mean the ACTUAL behavior of P, then you LIE about when H does
abort its input.

Either way, you LIE, and you speak your father's tongue.

On 11/17/2021 5:54 PM, Richard Damon wrote:
> On 11/17/21 10:24 AM, olcott wrote:
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> int H(ptr x, ptr y)
>> {
>>    x(y);  // direct execution of P(P)
>>    return 1;
>> }
>>
>> // Minimal essence of Linz(1990) Ĥ
>> // and Strachey(1965) P
>> int P(ptr x)
>> {
>>    H(x, x);
>>    return 1;
>> }
>>
>> int main(void)
>> {
>>    H(P, P);
>> }
>>
>> We can determine the behavior of the input to H(P,P) for an infinite
>> set of different definitions of H by using categorically exhaustively
>> complete reasoning. There are only four categories of possible
>> definitions for H:
>>
>> (1) H(P,P) simply executes its input: main() calls H(P,P) that calls
>> P(P) that calls H(P,P)...
>> (2) H(P,P) simulates its input.
>> (3) H(P,P) executes its input** and aborts this execution at some
>> point.   **(a debugger could be used).
>> (4) H(P,P) simulates its input and aborts this simulation at some point.
>>
>> Case (1) (complete source code is provided above) shows that P never
>> reaches its last instruction.
>
> WRONG, case 1 shows that for H1 defined as above, that the corresponding
> P1(P1) will be non-halting,, but H1(P1,P1) never gives an answer.
>
> Since P's behavor is affected by the behavior of H, we can NOT extend
> that fact to ANY other H.
>
>> Case (2) a correct simulation of the input to H(P,P) must have
>> equivalent behavior to case (1).
>
> Since Pure Simulation is by defintion the equivalent of direct
> execution, yes, this one will be the same.
>
> Note, This is a SPECIAL case, as ONLY Pure Simulation is the equivalent
> of direct exectution.
>
>> Case (3) and (4) any sub-sequence of (1) and (2) can't have
>> instructions not included in (1) or (2).
>
> WRONG. H can't see the exectution of any other instruction, but the
> actual execution of P can, and does. FAIL.
>
> When H aborts its exection and returns, this means that for HALTING
> PROBLEM puroses where we NEED to look at the ACTUAL behavior of P, the
> DIRECT execution of P(P) will show that it halts.
>
> For exampple H0(P3,P3) will show H1 calling P3(P3), then P3 calls
> H3(P3,P3), which debug steps through another execution layer of P3, sees
> that call H3(P3,P2), aborts its simulation of that second layer of P3,
> and return the value 0 to that first layer of P3, which will then return
> to H1 and thus H1, which DOES correctly execute its input sees that
> P3(P3) is halting and H3 got the wrong answer.
>
> We can do similer for H2(P3,P3), H1(P4,P4) and H2(P4,P4).
>
> H1 and H2 being direct execution and pure simulation will properly show
> the behavior of their inputs, and show that H3 and H4 are incorrret in
> their decisions.
>
>
>> Thus for cases (1)(2)(3)(4) P never reaches its last instruction.
>
> Nope, H never sees the reaching of the last instruction, which if that
> is what you mean, you are correct, but then that is a a SO WHAT, as that
> is NOT the definition of Halting.
>
> If you mean the ACTUAL execution, you are incorret.
>
>>
>> For every H that
>> simulates or
>> executes its input and
>> aborts or
>> does not abort its input
>> P never reaches its last instruction.
>>
>
> See above. You are LYING by that statement with the implication that it
> means something about halting.
>
> If you mean that the processing of H doesn't reach the last instruction,
> then you are LYING about that saying anything about Halting.
>
> If you mean the ACTUAL behavior of P, then you LIE about when H does
> abort its input.
>
> Either way, you LIE, and you speak your father's tongue.

computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)

Every sequence of of instructions that never reaches its final
instruction (for whatever reason) never halts.
The second instruction of P is the final instruction of P.

--
Copyright 2021 Pete Olcott

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

On 11/17/21 8:09 PM, olcott wrote:
> On 11/17/2021 5:54 PM, Richard Damon wrote:
>> On 11/17/21 10:24 AM, olcott wrote:
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    x(y);  // direct execution of P(P)
>>>    return 1;
>>> }
>>>
>>> // Minimal essence of Linz(1990) Ĥ
>>> // and Strachey(1965) P
>>> int P(ptr x)
>>> {
>>>    H(x, x);
>>>    return 1;
>>> }
>>>
>>> int main(void)
>>> {
>>>    H(P, P);
>>> }
>>>
>>> We can determine the behavior of the input to H(P,P) for an infinite
>>> set of different definitions of H by using categorically exhaustively
>>> complete reasoning. There are only four categories of possible
>>> definitions for H:
>>>
>>> (1) H(P,P) simply executes its input: main() calls H(P,P) that calls
>>> P(P) that calls H(P,P)...
>>> (2) H(P,P) simulates its input.
>>> (3) H(P,P) executes its input** and aborts this execution at some
>>> point.   **(a debugger could be used).
>>> (4) H(P,P) simulates its input and aborts this simulation at some point.
>>>
>>> Case (1) (complete source code is provided above) shows that P never
>>> reaches its last instruction.
>>
>> WRONG, case 1 shows that for H1 defined as above, that the
>> corresponding P1(P1) will be non-halting,, but H1(P1,P1) never gives
>> an answer.
>>
>> Since P's behavor is affected by the behavior of H, we can NOT extend
>> that fact to ANY other H.
>>
>>> Case (2) a correct simulation of the input to H(P,P) must have
>>> equivalent behavior to case (1).
>>
>> Since Pure Simulation is by defintion the equivalent of direct
>> execution, yes, this one will be the same.
>>
>> Note, This is a SPECIAL case, as ONLY Pure Simulation is the
>> equivalent of direct exectution.
>>
>>> Case (3) and (4) any sub-sequence of (1) and (2) can't have
>>> instructions not included in (1) or (2).
>>
>> WRONG. H can't see the exectution of any other instruction, but the
>> actual execution of P can, and does. FAIL.
>>
>> When H aborts its exection and returns, this means that for HALTING
>> PROBLEM puroses where we NEED to look at the ACTUAL behavior of P, the
>> DIRECT execution of P(P) will show that it halts.
>>
>> For exampple H0(P3,P3) will show H1 calling P3(P3), then P3 calls
>> H3(P3,P3), which debug steps through another execution layer of P3,
>> sees that call H3(P3,P2), aborts its simulation of that second layer
>> of P3, and return the value 0 to that first layer of P3, which will
>> then return to H1 and thus H1, which DOES correctly execute its input
>> sees that P3(P3) is halting and H3 got the wrong answer.
>>
>> We can do similer for H2(P3,P3), H1(P4,P4) and H2(P4,P4).
>>
>> H1 and H2 being direct execution and pure simulation will properly
>> show the behavior of their inputs, and show that H3 and H4 are
>> incorrret in their decisions.
>>
>>
>>> Thus for cases (1)(2)(3)(4) P never reaches its last instruction.
>>
>> Nope, H never sees the reaching of the last instruction, which if that
>> is what you mean, you are correct, but then that is a a SO WHAT, as
>> that is NOT the definition of Halting.
>>
>> If you mean the ACTUAL execution, you are incorret.
>>
>>>
>>> For every H that
>>> simulates or
>>> executes its input and
>>> aborts or
>>> does not abort its input
>>> P never reaches its last instruction.
>>>
>>
>> See above. You are LYING by that statement with the implication that
>> it means something about halting.
>>
>> If you mean that the processing of H doesn't reach the last
>> instruction, then you are LYING about that saying anything about Halting.
>>
>> If you mean the ACTUAL behavior of P, then you LIE about when H does
>> abort its input.
>>
>> Either way, you LIE, and you speak your father's tongue.
>
>
> computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)
>
> Every sequence of of instructions that never reaches its final
> instruction (for whatever reason) never halts.
> The second instruction of P is the final instruction of P.
>

So, do you consider yourself immortal because you haven't died yet? That
makes as much sense as saying something is not-halting because you
stopped it before it got to the point when it would halt.

Halting is as you say, and NON-Halting is NEVER halting, even when run
for an unlimited time. A partial execution that stops before reaching
the halting state doesn't show non-halting, just leaves the machine in a
non-yet-halted. An H that aborts only has a partial execution.

To claim that the COMPUTATION would not halt, you need to DIRECTLY run
or PURE simulate, and show that under THIS condition, it will never halt.

FAIL.

LIAR.

On 11/17/2021 7:38 PM, Richard Damon wrote:
> On 11/17/21 8:09 PM, olcott wrote:
>> On 11/17/2021 5:54 PM, Richard Damon wrote:
>>> On 11/17/21 10:24 AM, olcott wrote:
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>>    x(y);  // direct execution of P(P)
>>>>    return 1;
>>>> }
>>>>
>>>> // Minimal essence of Linz(1990) Ĥ
>>>> // and Strachey(1965) P
>>>> int P(ptr x)
>>>> {
>>>>    H(x, x);
>>>>    return 1;
>>>> }
>>>>
>>>> int main(void)
>>>> {
>>>>    H(P, P);
>>>> }
>>>>
>>>> We can determine the behavior of the input to H(P,P) for an infinite
>>>> set of different definitions of H by using categorically
>>>> exhaustively complete reasoning. There are only four categories of
>>>> possible definitions for H:
>>>>
>>>> (1) H(P,P) simply executes its input: main() calls H(P,P) that calls
>>>> P(P) that calls H(P,P)...
>>>> (2) H(P,P) simulates its input.
>>>> (3) H(P,P) executes its input** and aborts this execution at some
>>>> point.   **(a debugger could be used).
>>>> (4) H(P,P) simulates its input and aborts this simulation at some
>>>> point.
>>>>
>>>> Case (1) (complete source code is provided above) shows that P never
>>>> reaches its last instruction.
>>>
>>> WRONG, case 1 shows that for H1 defined as above, that the
>>> corresponding P1(P1) will be non-halting,, but H1(P1,P1) never gives
>>> an answer.
>>>
>>> Since P's behavor is affected by the behavior of H, we can NOT extend
>>> that fact to ANY other H.
>>>
>>>> Case (2) a correct simulation of the input to H(P,P) must have
>>>> equivalent behavior to case (1).
>>>
>>> Since Pure Simulation is by defintion the equivalent of direct
>>> execution, yes, this one will be the same.
>>>
>>> Note, This is a SPECIAL case, as ONLY Pure Simulation is the
>>> equivalent of direct exectution.
>>>
>>>> Case (3) and (4) any sub-sequence of (1) and (2) can't have
>>>> instructions not included in (1) or (2).
>>>
>>> WRONG. H can't see the exectution of any other instruction, but the
>>> actual execution of P can, and does. FAIL.
>>>
>>> When H aborts its exection and returns, this means that for HALTING
>>> PROBLEM puroses where we NEED to look at the ACTUAL behavior of P,
>>> the DIRECT execution of P(P) will show that it halts.
>>>
>>> For exampple H0(P3,P3) will show H1 calling P3(P3), then P3 calls
>>> H3(P3,P3), which debug steps through another execution layer of P3,
>>> sees that call H3(P3,P2), aborts its simulation of that second layer
>>> of P3, and return the value 0 to that first layer of P3, which will
>>> then return to H1 and thus H1, which DOES correctly execute its input
>>> sees that P3(P3) is halting and H3 got the wrong answer.
>>>
>>> We can do similer for H2(P3,P3), H1(P4,P4) and H2(P4,P4).
>>>
>>> H1 and H2 being direct execution and pure simulation will properly
>>> show the behavior of their inputs, and show that H3 and H4 are
>>> incorrret in their decisions.
>>>
>>>
>>>> Thus for cases (1)(2)(3)(4) P never reaches its last instruction.
>>>
>>> Nope, H never sees the reaching of the last instruction, which if
>>> that is what you mean, you are correct, but then that is a a SO WHAT,
>>> as that is NOT the definition of Halting.
>>>
>>> If you mean the ACTUAL execution, you are incorret.
>>>
>>>>
>>>> For every H that
>>>> simulates or
>>>> executes its input and
>>>> aborts or
>>>> does not abort its input
>>>> P never reaches its last instruction.
>>>>
>>>
>>> See above. You are LYING by that statement with the implication that
>>> it means something about halting.
>>>
>>> If you mean that the processing of H doesn't reach the last
>>> instruction, then you are LYING about that saying anything about
>>> Halting.
>>>
>>> If you mean the ACTUAL behavior of P, then you LIE about when H does
>>> abort its input.
>>>
>>> Either way, you LIE, and you speak your father's tongue.
>>
>>
>> computation that halts
>> a computation is said to halt whenever it enters a final state.
>> (Linz:1990:234)
>>
>> Every sequence of of instructions that never reaches its final
>> instruction (for whatever reason) never halts.
>> The second instruction of P is the final instruction of P.
>>
>
> So, do you consider yourself immortal because you haven't died yet? That
> makes as much sense as saying something is not-halting because you
> stopped it before it got to the point when it would halt.
>
> Halting is as you say, and NON-Halting is NEVER halting, even when run
> for an unlimited time. A partial execution that stops before reaching
> the halting state doesn't show non-halting, just leaves the machine in a
> non-yet-halted. An H that aborts only has a partial execution.
>
> To claim that the COMPUTATION would not halt, you need to DIRECTLY run
> or PURE simulate, and show that under THIS condition, it will never halt.

computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)

>>>> For every H that
>>>> simulates or
>>>> executes its input and
>>>> aborts or
>>>> does not abort its input
>>>> P never reaches its last instruction.

Does the input to H(P,P) halt ? No

--
Copyright 2021 Pete Olcott

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

On 11/17/21 9:13 PM, olcott wrote:
> On 11/17/2021 7:38 PM, Richard Damon wrote:
>> On 11/17/21 8:09 PM, olcott wrote:
>>> On 11/17/2021 5:54 PM, Richard Damon wrote:
>>>> On 11/17/21 10:24 AM, olcott wrote:
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>>
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>>    x(y);  // direct execution of P(P)
>>>>>    return 1;
>>>>> }
>>>>>
>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>> // and Strachey(1965) P
>>>>> int P(ptr x)
>>>>> {
>>>>>    H(x, x);
>>>>>    return 1;
>>>>> }
>>>>>
>>>>> int main(void)
>>>>> {
>>>>>    H(P, P);
>>>>> }
>>>>>
>>>>> We can determine the behavior of the input to H(P,P) for an
>>>>> infinite set of different definitions of H by using categorically
>>>>> exhaustively complete reasoning. There are only four categories of
>>>>> possible definitions for H:
>>>>>
>>>>> (1) H(P,P) simply executes its input: main() calls H(P,P) that
>>>>> calls P(P) that calls H(P,P)...
>>>>> (2) H(P,P) simulates its input.
>>>>> (3) H(P,P) executes its input** and aborts this execution at some
>>>>> point.   **(a debugger could be used).
>>>>> (4) H(P,P) simulates its input and aborts this simulation at some
>>>>> point.
>>>>>
>>>>> Case (1) (complete source code is provided above) shows that P
>>>>> never reaches its last instruction.
>>>>
>>>> WRONG, case 1 shows that for H1 defined as above, that the
>>>> corresponding P1(P1) will be non-halting,, but H1(P1,P1) never gives
>>>> an answer.
>>>>
>>>> Since P's behavor is affected by the behavior of H, we can NOT
>>>> extend that fact to ANY other H.
>>>>
>>>>> Case (2) a correct simulation of the input to H(P,P) must have
>>>>> equivalent behavior to case (1).
>>>>
>>>> Since Pure Simulation is by defintion the equivalent of direct
>>>> execution, yes, this one will be the same.
>>>>
>>>> Note, This is a SPECIAL case, as ONLY Pure Simulation is the
>>>> equivalent of direct exectution.
>>>>
>>>>> Case (3) and (4) any sub-sequence of (1) and (2) can't have
>>>>> instructions not included in (1) or (2).
>>>>
>>>> WRONG. H can't see the exectution of any other instruction, but the
>>>> actual execution of P can, and does. FAIL.
>>>>
>>>> When H aborts its exection and returns, this means that for HALTING
>>>> PROBLEM puroses where we NEED to look at the ACTUAL behavior of P,
>>>> the DIRECT execution of P(P) will show that it halts.
>>>>
>>>> For exampple H0(P3,P3) will show H1 calling P3(P3), then P3 calls
>>>> H3(P3,P3), which debug steps through another execution layer of P3,
>>>> sees that call H3(P3,P2), aborts its simulation of that second layer
>>>> of P3, and return the value 0 to that first layer of P3, which will
>>>> then return to H1 and thus H1, which DOES correctly execute its
>>>> input sees that P3(P3) is halting and H3 got the wrong answer.
>>>>
>>>> We can do similer for H2(P3,P3), H1(P4,P4) and H2(P4,P4).
>>>>
>>>> H1 and H2 being direct execution and pure simulation will properly
>>>> show the behavior of their inputs, and show that H3 and H4 are
>>>> incorrret in their decisions.
>>>>
>>>>
>>>>> Thus for cases (1)(2)(3)(4) P never reaches its last instruction.
>>>>
>>>> Nope, H never sees the reaching of the last instruction, which if
>>>> that is what you mean, you are correct, but then that is a a SO
>>>> WHAT, as that is NOT the definition of Halting.
>>>>
>>>> If you mean the ACTUAL execution, you are incorret.
>>>>
>>>>>
>>>>> For every H that
>>>>> simulates or
>>>>> executes its input and
>>>>> aborts or
>>>>> does not abort its input
>>>>> P never reaches its last instruction.
>>>>>
>>>>
>>>> See above. You are LYING by that statement with the implication that
>>>> it means something about halting.
>>>>
>>>> If you mean that the processing of H doesn't reach the last
>>>> instruction, then you are LYING about that saying anything about
>>>> Halting.
>>>>
>>>> If you mean the ACTUAL behavior of P, then you LIE about when H does
>>>> abort its input.
>>>>
>>>> Either way, you LIE, and you speak your father's tongue.
>>>
>>>
>>> computation that halts
>>> a computation is said to halt whenever it enters a final state.
>>> (Linz:1990:234)
>>>
>>> Every sequence of of instructions that never reaches its final
>>> instruction (for whatever reason) never halts.
>>> The second instruction of P is the final instruction of P.
>>>
>>
>> So, do you consider yourself immortal because you haven't died yet?
>> That makes as much sense as saying something is not-halting because
>> you stopped it before it got to the point when it would halt.
>>
>> Halting is as you say, and NON-Halting is NEVER halting, even when run
>> for an unlimited time. A partial execution that stops before reaching
>> the halting state doesn't show non-halting, just leaves the machine in
>> a non-yet-halted. An H that aborts only has a partial execution.
>>
>> To claim that the COMPUTATION would not halt, you need to DIRECTLY run
>> or PURE simulate, and show that under THIS condition, it will never halt.
>
>
> computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)
>
> >>>> For every H that
> >>>> simulates or
> >>>> executes its input and
> >>>> aborts or
> >>>> does not abort its input
> >>>> P never reaches its last instruction.
>
> Does the input to H(P,P) halt ? No
>
>
>

As you have previous said, this test is to be done by directly
executiing or doing a pure simulation of this input.

WHen THIS is done, then for ANY H that returns 0, that when we do this,
the P(P) based on this H will halt. FAIL.

Your claims contrary are just pure pathological lies, and since it has
been pointed out many times, this is obviously intentional, thus making
you a pathological LIAR.

Yes, you have shown that H will never be able to reach that point, so if
H is a pure simulation or direct execution, then we do have a P that
P(P) will be non-halting, but these Hs will fail to answer and be wrong.

But for EVERY H that does abort its processing to return a 0 because it
mistakenly thinks this is the case, and returns a value of 0, is can be
shown that for THIS P (based on this H) that P(P) will halt almost
immediately after the H(P,P) it called returns this answer.

You make the FALSE assumption, and blatant lie, that all Ps behave the
same, ignoring that Ps behavior depends on H. Your instance on this just
proves you are a LIAR.

NO H returns the right answer, period.

On 11/17/2021 8:23 PM, Richard Damon wrote:
> On 11/17/21 9:13 PM, olcott wrote:
>> On 11/17/2021 7:38 PM, Richard Damon wrote:
>>> On 11/17/21 8:09 PM, olcott wrote:
>>>> On 11/17/2021 5:54 PM, Richard Damon wrote:
>>>>> On 11/17/21 10:24 AM, olcott wrote:
>>>>>> #include <stdint.h>
>>>>>> typedef void (*ptr)();
>>>>>>
>>>>>> int H(ptr x, ptr y)
>>>>>> {
>>>>>>    x(y);  // direct execution of P(P)
>>>>>>    return 1;
>>>>>> }
>>>>>>
>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>> // and Strachey(1965) P
>>>>>> int P(ptr x)
>>>>>> {
>>>>>>    H(x, x);
>>>>>>    return 1;
>>>>>> }
>>>>>>
>>>>>> int main(void)
>>>>>> {
>>>>>>    H(P, P);
>>>>>> }
>>>>>>
>>>>>> We can determine the behavior of the input to H(P,P) for an
>>>>>> infinite set of different definitions of H by using categorically
>>>>>> exhaustively complete reasoning. There are only four categories of
>>>>>> possible definitions for H:
>>>>>>
>>>>>> (1) H(P,P) simply executes its input: main() calls H(P,P) that
>>>>>> calls P(P) that calls H(P,P)...
>>>>>> (2) H(P,P) simulates its input.
>>>>>> (3) H(P,P) executes its input** and aborts this execution at some
>>>>>> point.   **(a debugger could be used).
>>>>>> (4) H(P,P) simulates its input and aborts this simulation at some
>>>>>> point.
>>>>>>
>>>>>> Case (1) (complete source code is provided above) shows that P
>>>>>> never reaches its last instruction.
>>>>>
>>>>> WRONG, case 1 shows that for H1 defined as above, that the
>>>>> corresponding P1(P1) will be non-halting,, but H1(P1,P1) never
>>>>> gives an answer.
>>>>>
>>>>> Since P's behavor is affected by the behavior of H, we can NOT
>>>>> extend that fact to ANY other H.
>>>>>
>>>>>> Case (2) a correct simulation of the input to H(P,P) must have
>>>>>> equivalent behavior to case (1).
>>>>>
>>>>> Since Pure Simulation is by defintion the equivalent of direct
>>>>> execution, yes, this one will be the same.
>>>>>
>>>>> Note, This is a SPECIAL case, as ONLY Pure Simulation is the
>>>>> equivalent of direct exectution.
>>>>>
>>>>>> Case (3) and (4) any sub-sequence of (1) and (2) can't have
>>>>>> instructions not included in (1) or (2).
>>>>>
>>>>> WRONG. H can't see the exectution of any other instruction, but the
>>>>> actual execution of P can, and does. FAIL.
>>>>>
>>>>> When H aborts its exection and returns, this means that for HALTING
>>>>> PROBLEM puroses where we NEED to look at the ACTUAL behavior of P,
>>>>> the DIRECT execution of P(P) will show that it halts.
>>>>>
>>>>> For exampple H0(P3,P3) will show H1 calling P3(P3), then P3 calls
>>>>> H3(P3,P3), which debug steps through another execution layer of P3,
>>>>> sees that call H3(P3,P2), aborts its simulation of that second
>>>>> layer of P3, and return the value 0 to that first layer of P3,
>>>>> which will then return to H1 and thus H1, which DOES correctly
>>>>> execute its input sees that P3(P3) is halting and H3 got the wrong
>>>>> answer.
>>>>>
>>>>> We can do similer for H2(P3,P3), H1(P4,P4) and H2(P4,P4).
>>>>>
>>>>> H1 and H2 being direct execution and pure simulation will properly
>>>>> show the behavior of their inputs, and show that H3 and H4 are
>>>>> incorrret in their decisions.
>>>>>
>>>>>
>>>>>> Thus for cases (1)(2)(3)(4) P never reaches its last instruction.
>>>>>
>>>>> Nope, H never sees the reaching of the last instruction, which if
>>>>> that is what you mean, you are correct, but then that is a a SO
>>>>> WHAT, as that is NOT the definition of Halting.
>>>>>
>>>>> If you mean the ACTUAL execution, you are incorret.
>>>>>
>>>>>>
>>>>>> For every H that
>>>>>> simulates or
>>>>>> executes its input and
>>>>>> aborts or
>>>>>> does not abort its input
>>>>>> P never reaches its last instruction.
>>>>>>
>>>>>
>>>>> See above. You are LYING by that statement with the implication
>>>>> that it means something about halting.
>>>>>
>>>>> If you mean that the processing of H doesn't reach the last
>>>>> instruction, then you are LYING about that saying anything about
>>>>> Halting.
>>>>>
>>>>> If you mean the ACTUAL behavior of P, then you LIE about when H
>>>>> does abort its input.
>>>>>
>>>>> Either way, you LIE, and you speak your father's tongue.
>>>>
>>>>
>>>> computation that halts
>>>> a computation is said to halt whenever it enters a final state.
>>>> (Linz:1990:234)
>>>>
>>>> Every sequence of of instructions that never reaches its final
>>>> instruction (for whatever reason) never halts.
>>>> The second instruction of P is the final instruction of P.
>>>>
>>>
>>> So, do you consider yourself immortal because you haven't died yet?
>>> That makes as much sense as saying something is not-halting because
>>> you stopped it before it got to the point when it would halt.
>>>
>>> Halting is as you say, and NON-Halting is NEVER halting, even when
>>> run for an unlimited time. A partial execution that stops before
>>> reaching the halting state doesn't show non-halting, just leaves the
>>> machine in a non-yet-halted. An H that aborts only has a partial
>>> execution.
>>>
>>> To claim that the COMPUTATION would not halt, you need to DIRECTLY
>>> run or PURE simulate, and show that under THIS condition, it will
>>> never halt.
>>
>>
>> computation that halts
>> a computation is said to halt whenever it enters a final state.
>> (Linz:1990:234)
>>
>>  >>>> For every H that
>>  >>>> simulates or
>>  >>>> executes its input and
>>  >>>> aborts or
>>  >>>> does not abort its input
>>  >>>> P never reaches its last instruction.
>>
>> Does the input to H(P,P) halt ? No
>>
>>
>>
>
> As you have previous said, this test is to be done by directly
> executiing or doing a pure simulation of this input.
>

When we ask the question:
Does the input halt? and the input never reaches the third step of its
three step sequence because it was aborted the answer is still no.

> WHen THIS is done, then for ANY H that returns 0, that when we do this,
> the P(P) based on this H will halt. FAIL.
>
> Your claims contrary are just pure pathological lies, and since it has
> been pointed out many times, this is obviously intentional, thus making
> you a pathological LIAR.
>
> Yes, you have shown that H will never be able to reach that point, so if
> H is a pure simulation or direct execution, then we do have a P that
> P(P) will be non-halting, but these Hs will fail to answer and be wrong.
>
> But for EVERY H that does abort its processing to return a 0 because it
> mistakenly thinks this is the case, and returns a value of 0, is can be
> shown that for THIS P (based on this H) that P(P) will halt almost
> immediately after the H(P,P) it called returns this answer.
>
> You make the FALSE assumption, and blatant lie, that all Ps behave the
> same, ignoring that Ps behavior depends on H. Your instance on this just
> proves you are a LIAR.
>
> NO H returns the right answer, period.

On 11/17/21 9:39 PM, olcott wrote:
>> As you have previous said, this test is to be done by directly
>> executiing or doing a pure simulation of this input.
>>
>
>
> When we ask the question:
> Does the input halt? and the input never reaches the third step of its
> three step sequence because it was aborted the answer is still no.
>
>

No, YOU LIE, and you know it.

When talking about the HALTING PROBLEM, as your subject says, not
halting does NOT mean, aborted before reaching a halting state, but that
when we directly run that input (actually the machine it represents) it
will not halt for every finite number of steps it is run.

P(P), the input to H(P,P) WILL Halt, if H(P,P) returns 0. This is
provable, and has been proven to you.

Your denial of this just shows that you are a Liar and incapable of
understanding the meaning of the words in the field.

You have DOOMED your name to forever be known as an idiot.

You have basically just confirmed by your words that you accept the
proposition that ALL machines can be correctly decided to be not-halting
by just making a decider that immediately aborts its simulation of its
input and says not-halting.

This shows just how 'usefull' you idea is, a worlds where you have
converted the halting problem to a trivial question, because ALL
machines are corretly decided as not-halting isn't good for anything.

You have basically tainted you concept of truth, as any concept of truth
that leads to that sort of conclusion isn't worth looking at.

FAIL.

On 11/17/2021 9:19 PM, Richard Damon wrote:
> On 11/17/21 9:39 PM, olcott wrote:
>>> As you have previous said, this test is to be done by directly
>>> executiing or doing a pure simulation of this input.
>>>
>>
>>
>> When we ask the question:
>> Does the input halt? and the input never reaches the third step of its
>> three step sequence because it was aborted the answer is still no.
>>
>>
>
> No, YOU LIE, and you know it.
>
> When talking about the HALTING PROBLEM, as your subject says, not
> halting does NOT mean, aborted before reaching a halting state, but that
> when we directly run that input (actually the machine it represents) it
> will not halt for every finite number of steps it is run.

computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)

_Infinite_Loop()
[0000173e](01) 55 push ebp
[0000173f](02) 8bec mov ebp,esp
[00001741](02) ebfe jmp 00001741
[00001743](01) 5d pop ebp
[00001744](01) c3 ret
Size in bytes:(0007) [00001744]

If the halt decider aborts the simulation of this input at its first
instruction then this input DID NOT HALT.

The above sequence of instructions only halts when it reaches 00001744.
When the above sequence is (executed or simulated) and (aborted or not
aborted) IT DOES NOT HALT.

>
> P(P), the input to H(P,P) WILL Halt, if H(P,P) returns 0. This is
> provable, and has been proven to you.
>
> Your denial of this just shows that you are a Liar and incapable of
> understanding the meaning of the words in the field.
>
> You have DOOMED your name to forever be known as an idiot.
>
> You have basically just confirmed by your words that you accept the
> proposition that ALL machines can be correctly decided to be not-halting
> by just making a decider that immediately aborts its simulation of its
> input and says not-halting.
>
> This shows just how 'usefull' you idea is, a worlds where you have
> converted the halting problem to a trivial question, because ALL
> machines are corretly decided as not-halting isn't good for anything.
>
> You have basically tainted you concept of truth, as any concept of truth
> that leads to that sort of conclusion isn't worth looking at.
>
> FAIL.

--
Copyright 2021 Pete Olcott

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

On 11/17/21 10:35 PM, olcott wrote:
> On 11/17/2021 9:19 PM, Richard Damon wrote:
>> On 11/17/21 9:39 PM, olcott wrote:
>>>> As you have previous said, this test is to be done by directly
>>>> executiing or doing a pure simulation of this input.
>>>>
>>>
>>>
>>> When we ask the question:
>>> Does the input halt? and the input never reaches the third step of
>>> its three step sequence because it was aborted the answer is still no.
>>>
>>>
>>
>> No, YOU LIE, and you know it.
>>
>> When talking about the HALTING PROBLEM, as your subject says, not
>> halting does NOT mean, aborted before reaching a halting state, but
>> that when we directly run that input (actually the machine it
>> represents) it will not halt for every finite number of steps it is run.
>
> computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)
>
> _Infinite_Loop()
> [0000173e](01)  55              push ebp
> [0000173f](02)  8bec            mov ebp,esp
> [00001741](02)  ebfe            jmp 00001741
> [00001743](01)  5d              pop ebp
> [00001744](01)  c3              ret
> Size in bytes:(0007) [00001744]
>
> If the halt decider aborts the simulation of this input at its first
> instruction then this input DID NOT HALT.

So your logic is that ALL computation can be correctly decided as did
not halt?

Does that REALLY make sense?

FAIL.

>
> The above sequence of instructions only halts when it reaches 00001744.
> When the above sequence is (executed or simulated) and (aborted or not
> aborted) IT DOES NOT HALT.

Your mind seems to be a bowl of mush. Yes, the program Infinite_Loop is
non-halting, but NOT because it didn't reach the end state because it
was aborted but because it would never reach that end state even if it
was NOT aborted.

Rules are Rules and rule breakers are rule breakers.

You are a flat out Liar in that you insist on things that are not true.

FAIL.

>
>>
>> P(P), the input to H(P,P) WILL Halt, if H(P,P) returns 0. This is
>> provable, and has been proven to you.
>>
>> Your denial of this just shows that you are a Liar and incapable of
>> understanding the meaning of the words in the field.
>>
>> You have DOOMED your name to forever be known as an idiot.
>>
>> You have basically just confirmed by your words that you accept the
>> proposition that ALL machines can be correctly decided to be
>> not-halting by just making a decider that immediately aborts its
>> simulation of its input and says not-halting.
>>
>> This shows just how 'usefull' you idea is, a worlds where you have
>> converted the halting problem to a trivial question, because ALL
>> machines are corretly decided as not-halting isn't good for anything.
>>
>> You have basically tainted you concept of truth, as any concept of
>> truth that leads to that sort of conclusion isn't worth looking at.
>>
>> FAIL.
>
>

On 11/18/2021 5:21 AM, Richard Damon wrote:
> On 11/17/21 10:35 PM, olcott wrote:
>> On 11/17/2021 9:19 PM, Richard Damon wrote:
>>> On 11/17/21 9:39 PM, olcott wrote:
>>>>> As you have previous said, this test is to be done by directly
>>>>> executiing or doing a pure simulation of this input.
>>>>>
>>>>
>>>>
>>>> When we ask the question:
>>>> Does the input halt? and the input never reaches the third step of
>>>> its three step sequence because it was aborted the answer is still no.
>>>>
>>>>
>>>
>>> No, YOU LIE, and you know it.
>>>
>>> When talking about the HALTING PROBLEM, as your subject says, not
>>> halting does NOT mean, aborted before reaching a halting state, but
>>> that when we directly run that input (actually the machine it
>>> represents) it will not halt for every finite number of steps it is run.
>>
>> computation that halts
>> a computation is said to halt whenever it enters a final state.
>> (Linz:1990:234)
>>
>> _Infinite_Loop()
>> [0000173e](01)  55              push ebp
>> [0000173f](02)  8bec            mov ebp,esp
>> [00001741](02)  ebfe            jmp 00001741
>> [00001743](01)  5d              pop ebp
>> [00001744](01)  c3              ret
>> Size in bytes:(0007) [00001744]
>>
>> If the halt decider aborts the simulation of this input at its first
>> instruction then this input DID NOT HALT.
>
> So your logic is that ALL computation can be correctly decided as did
> not halt?
>
> Does that REALLY make sense?
>
> FAIL.
>
>>
>> The above sequence of instructions only halts when it reaches 00001744.
>> When the above sequence is (executed or simulated) and (aborted or not
>> aborted) IT DOES NOT HALT.
>
> Your mind seems to be a bowl of mush. Yes, the program Infinite_Loop is
> non-halting, but NOT because it didn't reach the end state because it
> was aborted but because it would never reach that end state even if it
> was NOT aborted.
>
> Rules are Rules and rule breakers are rule breakers.
>
> You are a flat out Liar in that you insist on things that are not true.
>

The way that you stipulate the definition of a halt decider no halt
decider can ever report that its input never halts, unless it remains
stuck in an infinite loop it is not a halt decider and unless it breaks
out of this loop it is not a decider.

> FAIL.
>
>>
>>>
>>> P(P), the input to H(P,P) WILL Halt, if H(P,P) returns 0. This is
>>> provable, and has been proven to you.
>>>
>>> Your denial of this just shows that you are a Liar and incapable of
>>> understanding the meaning of the words in the field.
>>>
>>> You have DOOMED your name to forever be known as an idiot.
>>>
>>> You have basically just confirmed by your words that you accept the
>>> proposition that ALL machines can be correctly decided to be
>>> not-halting by just making a decider that immediately aborts its
>>> simulation of its input and says not-halting.
>>>
>>> This shows just how 'usefull' you idea is, a worlds where you have
>>> converted the halting problem to a trivial question, because ALL
>>> machines are corretly decided as not-halting isn't good for anything.
>>>
>>> You have basically tainted you concept of truth, as any concept of
>>> truth that leads to that sort of conclusion isn't worth looking at.
>>>
>>> FAIL.
>>
>>
>

--
Copyright 2021 Pete Olcott

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

On 11/18/21 10:33 AM, olcott wrote:
> On 11/18/2021 5:21 AM, Richard Damon wrote:
>> On 11/17/21 10:35 PM, olcott wrote:
>>> On 11/17/2021 9:19 PM, Richard Damon wrote:
>>>> On 11/17/21 9:39 PM, olcott wrote:
>>>>>> As you have previous said, this test is to be done by directly
>>>>>> executiing or doing a pure simulation of this input.
>>>>>>
>>>>>
>>>>>
>>>>> When we ask the question:
>>>>> Does the input halt? and the input never reaches the third step of
>>>>> its three step sequence because it was aborted the answer is still no.
>>>>>
>>>>>
>>>>
>>>> No, YOU LIE, and you know it.
>>>>
>>>> When talking about the HALTING PROBLEM, as your subject says, not
>>>> halting does NOT mean, aborted before reaching a halting state, but
>>>> that when we directly run that input (actually the machine it
>>>> represents) it will not halt for every finite number of steps it is
>>>> run.
>>>
>>> computation that halts
>>> a computation is said to halt whenever it enters a final state.
>>> (Linz:1990:234)
>>>
>>> _Infinite_Loop()
>>> [0000173e](01)  55              push ebp
>>> [0000173f](02)  8bec            mov ebp,esp
>>> [00001741](02)  ebfe            jmp 00001741
>>> [00001743](01)  5d              pop ebp
>>> [00001744](01)  c3              ret
>>> Size in bytes:(0007) [00001744]
>>>
>>> If the halt decider aborts the simulation of this input at its first
>>> instruction then this input DID NOT HALT.
>>
>> So your logic is that ALL computation can be correctly decided as did
>> not halt?
>>
>> Does that REALLY make sense?
>>
>> FAIL.
>>
>>>
>>> The above sequence of instructions only halts when it reaches 00001744.
>>> When the above sequence is (executed or simulated) and (aborted or
>>> not aborted) IT DOES NOT HALT.
>>
>> Your mind seems to be a bowl of mush. Yes, the program Infinite_Loop
>> is non-halting, but NOT because it didn't reach the end state because
>> it was aborted but because it would never reach that end state even if
>> it was NOT aborted.
>>
>> Rules are Rules and rule breakers are rule breakers.
>>
>> You are a flat out Liar in that you insist on things that are not true.
>>
>
> The way that you stipulate the definition of a halt decider no halt
> decider can ever report that its input never halts, unless it remains
> stuck in an infinite loop it is not a halt decider and unless it breaks
> out of this loop it is not a decider.

Not at all. For example, H(Infinite_Loop, Infinite_Loop) can validly
return 0 as we can show that if you run Infinite_Loop((nfinite_Loop) it
will never halt.

The key is that H would need to use some VALID logic to determine this,
and can't say it is true JUST because it didn't reach a halting state in
the finite time it simulated it.

The problem is that for an H that Does abort its simulation of P(P) that
is based on it, H did not use VALID logic, as your logic assume that the
identical H inside P would NOT also abort its simulation, and thus it
got the wrong answer, easily proved by just running P(P) as an
independent machine.

Yes, The Halting Problem is HARD, as a universal H really needs to be a
universal theorem solver. A partial H is possible as you can define a
finite set of condition that you can VALIDLY detect to detect SOME
non-halting machines.

>
>> FAIL.
>>
>>>
>>>>
>>>> P(P), the input to H(P,P) WILL Halt, if H(P,P) returns 0. This is
>>>> provable, and has been proven to you.
>>>>
>>>> Your denial of this just shows that you are a Liar and incapable of
>>>> understanding the meaning of the words in the field.
>>>>
>>>> You have DOOMED your name to forever be known as an idiot.
>>>>
>>>> You have basically just confirmed by your words that you accept the
>>>> proposition that ALL machines can be correctly decided to be
>>>> not-halting by just making a decider that immediately aborts its
>>>> simulation of its input and says not-halting.
>>>>
>>>> This shows just how 'usefull' you idea is, a worlds where you have
>>>> converted the halting problem to a trivial question, because ALL
>>>> machines are corretly decided as not-halting isn't good for anything.
>>>>
>>>> You have basically tainted you concept of truth, as any concept of
>>>> truth that leads to that sort of conclusion isn't worth looking at.
>>>>
>>>> FAIL.
>>>
>>>
>>
>
>

olcott wrote:

> #include <stdint.h> typedef void (*ptr)();

sure, but here we have another one worth following:

Conflict Of Interest Covid in Australia [mirrored]
https://www.bitchute.com/video/M6xtOhsyUO1A/

in my opinion these overpaid capitalist *public_servants*, thinking they
are elite, did a big mistake misunderstanding *technology*, with which
already they could subjugate the planet. But the technology is often
incomplete, made "possible", etc before frauds and myriads of errors that
might occur. It looks like that these capitalist_fascist, severely
*uneducated* public_servants, are all going to be fucked up
penetratingly. It's a sin letting these satanists escape.