Concise refutation of halting problem proofs V10 [ all rebuttals are categorically denied ]

[olcott]

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

int H(ptr x, ptr y)
{
x(y);
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P (see below)
void P(ptr x)
{
H(x, x);
}

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

It is obvious that the direct execution of the above code never halts
because it is infinitely recursive. It is equally obvious that when H
performs a correct pure simulation of its input (instead of directly
executing it) that its input never halts.

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]

Because there is nothing that H can possibly do to cause or enable P to
reach its final state at 1a72 we correctly conclude that the input to
H(P,P) never halts.

For every possible H in the universe that is invoked at machine address
00001a7e the specific byte sequence of the machine code for P as input
to H(P,P) never halts. Thus all rebuttals in the universe are
categorically denied.


Halting problem undecidability and infinitely nested simulation (V2)
https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

[Richard Damon]

Wrong. IF H does abort and return 0 then the ACTUAL running of P will
reach that address, and the actual running of P is what matters.

All you have shown is that it is impossible for H to PROVE that P will
be halting, not that P isn't Halting.

>
> For every possible H in the universe that is invoked at machine address
> 00001a7e the specific byte sequence of the machine code for P as input
> to H(P,P) never halts. Thus all rebuttals in the universe are
> categorically denied.
>

Except that you are proving the wrong thing. You have only proved that H
can not Prove that P is Halting, not that P itself in non-halting.

It is a fundamental fact that for EVERY H that aborts its 'simulation'
of P and returns 0, that the actual computation P(P) will halt. (And
thus the H was wrong)

It is also true that for EVERY H that does NOT abort its 'simulation' of
P, that H will never be able to return an answer, so that H fails to be
a decider.

Your attempt to deny that just shows that you are a pathological liar,
and don't have a grasp on what is actually truth,

Yes, you have shown that the simulation in H never reaches that final
state, so as has been pointed out, you HAVE proved that H can never
prove that P is halting by seeing that happening, but not able to prove
that fact, and the fact not actually being true are two very different
things.

I think that fundamentally the problem is that you are basing your whole
arguement on the LIE that you are even working on the Halting Problem,
as to make that claim, you needed to first accept the ground rules of
the problem and the logic system it is built on.

You just don't understand what the meaning of Truth actually is.

[olcott]

I have shown that P always specifies infinite recursion whether or not
this infinite recursion is aborted, therefore H(P,P)==0 is always correct.

All rebuttals must take this form:
Find an invocation of H(P,P) at machine address 00001a7e such that the
simulation or execution of (the exact byte sequence of) P reaches its
final address of 00001a72.

If no rebuttals exist this conclusively proves that H(P,P)==0 for every
H in the unverse.

[Richard Damon]

No, you haven't.

You logic makes the unsound step of FIRST assuming that H never aborts
its operation, and THEN has H do an abort.

If you DO have a valid proof that P(P) is non-halting when H(P,P) return
0 then you have just proved you logic system to be inconsistent as it
can also be proved the if H(P,P) returns 0, that P(P) halts.

A system that can prove a statement and its complement is inconsestent,
and logically worthless.

>
> All rebuttals must take this form:
> Find an invocation of H(P,P) at machine address 00001a7e such that the
> simulation or execution of (the exact byte sequence of) P reaches its
> final address of 00001a72.
>
> If no rebuttals exist this conclusively proves that H(P,P)==0 for every
> H in the unverse.
>

WRONG CRITERIA.

Just proves you are looking at POOP.

The REAL halting problems asks what P(P) actually does.

If H(P,P) returns 0 in finite time, then P(P) will halt in finite time.

Do you disagree with that statement?

If not, then you have to admit either that you aren't actually working
on the Halting Problem, or that you H is incorrect when it returns 0.

[olcott]

I proven beyond all possible doubt that the real P is infinitely
recursive in my latest example where H directly executes its input

x(y) is new syntax to me too.
Ben provided it and it uses function pointer syntax.
When H(P,P) is called x(y) means P(P);

>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>> x(y);
>>>> return 1;
>>>> }

[Richard Damon]

Yes, *IF* H just directly executes its input, then P(P) will be
non-Halting, but H(P,P) never returns 0, so it is not a counter example.

This statement ONLY applies to H's that behave that way. Any H that does
return 0 for H(P,P) has a P that P(P) will be Halting.

You can't have H be one thing in one part of the proof, and something
else in another.

If we call the H that doesn't abort to be Hn, and the P based on it to
be Pn to make things clear, then yes, a DIFFERENT H that does abort its
simulation, call it Ha, can correct decide by Ha(Pn,Pn) returning 0 that
Pn(Pn) is non-halting, but that doesn't meet the requirements to be a
counter example, to be a counter example, you need to find some H, Hx
that gets right the P based on in Px correctly.

We Know that Pn(Pn) is non-halting, but Hn(Pn,Pn) never returns.
We Know that Pa(Pa) is Halitng, but Ha(Pa,Pa) returns 0 (Non-Halting)

You do get the following cases right, but they aren't the needed cases:

Hn(Pa,Pa) will return 1, which is right since Pa(Pa) is Halting.
Ha(Pn,Pn) will return 0, which is right since Pn(Pn) is Non-Halting.


FAIL.

[olcott]

The ultimate measure of the halt status of an input is its behavior when
directly executed.

> but H(P,P) never returns 0, so it is not a counter example.
>

The fact that for every possible H that can possibly exist at at machine
address 00001a7e the simulation or execution of (the exact byte sequence
of) P never reaches its final address of 00001a72 conclusively proves

that the input to H(P,P) never halts.

The input to H(P,P) never halts therefore when H returns 0 it is always
correct.

> This statement ONLY applies to H's that behave that way. Any H that does
> return 0 for H(P,P) has a P that P(P) will be Halting.
>
> You can't have H be one thing in one part of the proof, and something
> else in another.
>
> If we call the H that doesn't abort to be Hn, and the P based on it to
> be Pn to make things clear, then yes, a DIFFERENT H that does abort its
> simulation, call it Ha, can correct decide by Ha(Pn,Pn) returning 0 that
> Pn(Pn) is non-halting, but that doesn't meet the requirements to be a
> counter example, to be a counter example, you need to find some H, Hx
> that gets right the P based on in Px correctly.
>
> We Know that Pn(Pn) is non-halting, but Hn(Pn,Pn) never returns.
> We Know that Pa(Pa) is Halitng, but Ha(Pa,Pa) returns 0 (Non-Halting)
>
> You do get the following cases right, but they aren't the needed cases:
>
> Hn(Pa,Pa) will return 1, which is right since Pa(Pa) is Halting.
> Ha(Pn,Pn) will return 0, which is right since Pn(Pn) is Non-Halting.
>
>
> FAIL.
>
>>
>> x(y) is new syntax to me too.
>> Ben provided it and it uses function pointer syntax.
>> When H(P,P) is called x(y) means P(P);
>>
>>  >>>> #include <stdint.h>
>>  >>>> typedef void (*ptr)();
>>  >>>>
>>  >>>> int H(ptr x, ptr y)
>>  >>>> {
>>  >>>>    x(y);
>>  >>>>    return 1;
>>  >>>> }
>>
>>
>

[Richard Damon]

No, you have a fundamental error in your logic,

FIRST, as has been explained before, but you just ignorantly ignore,
'inputs' do not have behavior, and as such do not halt or be
non-halting. Halting is a property of COMPUTATIONS, not inputs. Thus
your statement is proved conclusively FALSE because it makes an error in
category (Maybe you don't understand these terms, but repeatedly
ignoring them doesn't help your cause).

The closest possible statement to the one you make is that the machine
represented by the input never Halts, but this has been proved
conclusive false for any H where H(P,P) returns 0.

Yes, if H(P,P) only does an uncoditional execution/simulation, then P(P)
is non-halting, but then H(P,P) never returns 0 so your statement isn't
satisfied.

If H(P,P) actually DOES return 0, then you statement is false as P(P)
will halt. It is then shown that the logic you used to show that it
would never halt was unsound as it was built on the premise that H(P,P)
would do an unconditional execution of its input, when in fact it doesn't.

You are just PROVING your lack of knowledge about the problem by
repeating this same error time after time.

You seem to have this mistaken belief that the partial simulation in H
somehow matters to the problem. You have shown some ramblings about why
you THINK it should, but that ignores that fact that the actual
definitions says it doesn't. Do you have ANY actual references to
someone with standing indicating that the simulation within H has ANY
bearing on what the actual correct answer should be. (Not just
references about how in SOME cases you can deduce the correct answer
from the simulation, but something saying that if an ABORTED simulation
didn't reach a halting state, that shows that the machine is non-halting).

FAIL.

[olcott]

Because the simulated or executed input to every H(P,P) invoked at
machine address 00001a7e with the byte sequence of the machine code of P
as its input never reaches the final address of P at 00001a72 it is
always correct for this H(P,P) to return 0.

All rebuttals must take this form:
Find an invocation of H(P,P) at machine address 00001a7e such that the
simulation or execution of (the exact byte sequence of) P reaches its
final address of 00001a72.

Now that I have finally made my claim 100% perfectly precise when any
fake "rebuttal" side steps this claim with the strawman error (dishonest
dodge) it is very easy to tell.

[Richard Damon]

Whch just proves that H can not prove Halting. It does NOT prove
non-halting, except for the case when H NEVER aborts, and it that case
it never gives the answer.

FAIL.

>
> All rebuttals must take this form:
> Find an invocation of H(P,P) at machine address 00001a7e such that the
> simulation or execution of (the exact byte sequence of) P reaches its
> final address of 00001a72.

No, they don't because that isn't the critera that Halting is based on.

You have basically just proved that you don't have the basic
understanding of the logical principles to engage in meaningful
discusion on this topic.

>
> Now that I have finally made my claim 100% perfectly precise when any
> fake "rebuttal" side steps this claim with the strawman error (dishonest
> dodge) it is very easy to tell.
>

FALSE. You just proved that you like to LIE about what you are doing.

FAIL.

[olcott]

It proves no such thing.

If the input to (the precisely specified) H(P,P) never halts then it
always correct for H to report that the input to this H(P,P) never halts.

[Richard Damon]

WRONG. FIRST: ERROR OF CATEGORY. INPUTS DON'T HAVE A HALTING PROPERTY,
only machines do.

Only reasonable interpretations of this statement is either:
1) The behavior of Computation (Machine + Input) that this input
represents,
2) The behavior of a UTM/pure simulation of this input (NOT a simulation
that aborts its simulation).

With That:

If your precisely specified H(P,P) is one that returns 0 from the call
to H(P,P) then it can easily be shown that P(P) for that H will halt.

Yes, H doesn't see that halting because it aborts its simulation before
it gets there, but the machine that the input represents does.

Yes, P(P) is non-halting if H(P,P) doesn't return, but then H didn't
give the needed answer so this case is not a counter example either.


FAIL.

[olcott]

If the correctly simulated or directly executed input to (the precisely

specified) H(P,P) never halts then it always correct for H to report
that the input to this H(P,P) never halts.

If X is a Y then it is always correct to say X is a Y.

> Only reasonable interpretations of this statement is either:
> 1) The behavior of Computation (Machine + Input) that this input
> represents,
> 2) The behavior of a UTM/pure simulation of this input (NOT a simulation
> that aborts its simulation).
>
> With That:
>
> If your precisely specified H(P,P) is one that returns 0 from the call
> to H(P,P) then it can easily be shown that P(P) for that H will halt.
>
> Yes, H doesn't see that halting because it aborts its simulation before
> it gets there, but the machine that the input represents does.
>
> Yes, P(P) is non-halting if H(P,P) doesn't return, but then H didn't
> give the needed answer so this case is not a counter example either.
>
>
> FAIL.
>

[André G. Isaak]

On 2021-11-12 15:53, olcott wrote:

> The ultimate measure of the halt status of an input is its behavior when
> directly executed.

The input itself doesn't have a halt status. The machine it represents
does. And the ultimate measure of the halt status of that machine is
whether that machine halts when directly executed.

P(P) halts when directly exectuted.

Therefore H(P, P) == 0 is the wrong answer.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

[olcott]

On 11/12/2021 7:47 PM, André G. Isaak wrote:
> On 2021-11-12 15:53, olcott wrote:
>
>> The ultimate measure of the halt status of an input is its behavior
>> when directly executed.
>
> The input itself doesn't have a halt status.

In this case it does. Ben simplified my syntax.

#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

void P(ptr x)
{
H(x, x);
}

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

> The machine it represents
> does. And the ultimate measure of the halt status of that machine is
> whether that machine halts when directly executed.
>
> P(P) halts when directly exectuted.
>
> Therefore H(P, P) == 0 is the wrong answer.
>
> André
>


--

[Richard Damon]

Except that, BY DEFINITION, if H has aborted its simulation/direct
execution of its input, then it has NOT correctly simulated it.

Thus, the only machines that meet your premise, are machines that will
never abort the simulation/execution of P, and it has been shown that
these machine will never return the, in THIS case, correct value of 0.

ERGO, you proof fails.

You can not show a precisely specified H that actually does CORRECTLY
SIMULATE its input which it claims to be non-halting, and also return a
value. This is because BY DEFINITION, it takes infinite time to
correctly simulate a non-halting computation, and you can't do both
return an answer in finite time and still spend an infinite time to do
the correct simulation.

Your proposition is only true if H is a member of the empty set.

FAIL.

[Richard Damon]

On 11/12/21 8:59 PM, olcott wrote:
> On 11/12/2021 7:47 PM, André G. Isaak wrote:
>> On 2021-11-12 15:53, olcott wrote:
>>
>>> The ultimate measure of the halt status of an input is its behavior
>>> when directly executed.
>>
>> The input itself doesn't have a halt status.
>
> In this case it does. Ben simplified my syntax.

Nope.

This just shows that you don't have a valid Turing Model in place.

A sting of bytes does not in of itself have a Halting Status.

Interpreting that string as a set of instructions by executing it, makes
it have one.

Basically, your x(y) to be implemented in a Turing Machine would likely
be putting in the code for a UTM there, and the tape would need to be
loaded with a representation of the function P and all the code of H
that it calls, including that UTM.

That input tape, still, doesn't have behavior on its own. but ONLY as
viewed as either the representation of an actual Turing Machine, or as
the input to a UTM (which is what you do here).

FAIL.

[olcott]

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

computer science decider
a decider is a machine that accepts or rejects inputs.
https://cs.stackexchange.com/questions/84433/what-is-decider

halt decider
A halt decider correctly determines whether or not the direct execution
or pure simulation of its input will ever reach a final state of this
input.

[olcott]

On 11/12/2021 8:19 PM, Richard Damon wrote:
> On 11/12/21 8:59 PM, olcott wrote:
>> On 11/12/2021 7:47 PM, André G. Isaak wrote:
>>> On 2021-11-12 15:53, olcott wrote:
>>>
>>>> The ultimate measure of the halt status of an input is its behavior
>>>> when directly executed.
>>>
>>> The input itself doesn't have a halt status.
>>
>> In this case it does. Ben simplified my syntax.
>
> Nope.
>
> This just shows that you don't have a valid Turing Model in place.
>
> A sting of bytes does not in of itself have a Halting Status.
>
> Interpreting that string as a set of instructions by executing it, makes
> it have one.
>
> Basically, your x(y) to be implemented in a Turing Machine would likely
> be putting in the code for a UTM there, and the tape would need to be
> loaded with a representation of the function P and all the code of H
> that it calls, including that UTM.
>
> That input tape, still, doesn't have behavior on its own. but ONLY as
> viewed as either the representation of an actual Turing Machine, or as
> the input to a UTM (which is what you do here).
>
> FAIL.
>

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

computer science decider
a decider is a machine that accepts or rejects inputs.
https://cs.stackexchange.com/questions/84433/what-is-decider

halt decider

A halt decider accept or rejects an input on the basis of whether or not
the direct execution or pure simulation of this input would ever reach a

final state of this input.

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]

H(P,P)==0 is correct for every H at machine address 00001a7e with the
above string of machine language bytes as its input.

>>
>> #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
>> void P(ptr x)
>> {
>>    H(x, x);
>> }
>>
>> int main(void)
>> {
>>    H(P, P);
>> }
>>
>>
>>
>>> The machine it represents does. And the ultimate measure of the halt
>>> status of that machine is whether that machine halts when directly
>>> executed.
>>>
>>> P(P) halts when directly exectuted.
>>>
>>> Therefore H(P, P) == 0 is the wrong answer.
>>>
>>> André
>>>
>>
>>
>

[Richard Damon]

Right, THE COMPUTATION, not a partial simulation of one.
Note Non-Halting is defined as NEVER halting after unlimited number of
steps.

Not failing to reach the halt state after executing only a limited fixed
number of steps.

FAIL

> computer science decider
> a decider is a machine that accepts or rejects inputs.
> https://cs.stackexchange.com/questions/84433/what-is-decider
>
> halt decider
> A halt decider accept or rejects an input on the basis of whether or not
> the direct execution or pure simulation of this input would ever reach a
> final state of this input.
>

RIGHT, only FULL DIRECT EXECTUTION or PURE SIMULATION.

> _P()
> [00001a5e](01)  55              push ebp
> [00001a5f](02)  8bec            mov ebp,esp
> [00001a61](03)  8b4508          mov eax,[ebp+08]
> [00001a64](01)  50              push eax        // push P
> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
> [00001a68](01)  51              push ecx        // push P
> [00001a69](05)  e810000000      call 00001a7e   // call H
> [00001a6e](03)  83c408          add esp,+08
> [00001a71](01)  5d              pop ebp
> [00001a72](01)  c3              ret
> Size in bytes:(0021) [00001a72]
>
>
> H(P,P)==0 is correct for every H at machine address 00001a7e with the
> above string of machine language bytes as its input.
>

Nope.

If H is defined in a way that aborts its simulation and returns a value
in finite time then the DIRECT EXECTUTION of P will reach that terminal
state.

Yes, H in its PARTIAL simulation won't see that, but a partial
simulation proves nothing.

Yes, if H actual does an unconditional execution of the machine
represented by its input, then P(P) will become non-halting, but H(P,P)
never returns the 0 value to be right about it.


Also, if that is all the input it is given, then you haven't meet the
requriements.

That input is NOT a full description of the machine P, as it doesn't
fully define the behavior of the machine it is supposed to represent.

Make that the SOLE input to a direct exectuition and the call to H at
1a7e becomes undefined. For this to represent an equivalent to the
TURING MACHINE H^ (aka P) then it needs a FULL COPY of the code of H.

FAIL.

If you object, tell me what is the halting behavior of the following
program:

void X(ptr x)
{
if(foo(x,x)) {
while(1);
}
return;
}


It is just as complete a program description as what you gave for P
above with its call of H.

Go ahead, tell me what H(X,X) should return.

[Richard Damon]

Right, note you said DIRECT EXECUTION OR PURE SIMULATION determine the
behavior,

That means an UNCONDITIONAL DIRECT EXECTUTION or SIMULATION.

If H 'aborts' its simulation, it is NOT a DIRECT EXECTUTION OR PURE
SIMULATION.

So if H aborts its simulation, we need to look at an ACTUAL Direct
Exectution or PURE Simulation of that input.

Yes, if H IS a Direct Execution or Pure Simulation of its input, then
yes, the fact that its processing of P(P) doesn't reach that end state
shows that THAT P(P) is non-halting. Your problem is that ALL of these
machines also never return an answer, so fail to meet the requirements
of being a decider.

Note, this result ONLY applies to the P built on the H that never
aborts. Since P's behavior depends on H, changing to a different H gives
you different results.

When H does abort its simulation, then the simulation/execution by H is
NOT the required PURE SIMULATION or DIRECT EXECUTION, so its failure to
reach the end is NOT proof of non-halting, and since you have changed
the machine P by changing H you previous proof based on the actual
direct execution/pure simulation is not applicable.


You keep on trying to mix the results of one H with that of another, as
has been said before that is INVALID, it makes as much sense as proving
that your cat barks by noting that you neighbor has a cat, so you call
your pet, which happens to be a dog, a cat for this experement.

FAIL.

[olcott]

No this is not true. For the precisely defined computation of H(P,P) the
input P never gets past 00001a69.

[olcott]

If H somehow determines the correct halt status for its input by jumping
up and down yelling and screaming then H is a correct halt decider for
this input.

[Richard Damon]

On 11/12/21 11:08 PM, olcott wrote:

> If H somehow determines the correct halt status for its input by jumping
> up and down yelling and screaming then H is a correct halt decider for
> this input.

Except that it didn't get the right answer, since it says that a
Computation that is easily shown to Halt is non-halting.

Your only arguiement that it is right is based on some incorrect
description of what it does.

If it doesn't matter how it got the answer, then way does it matter what
its internal simulation did, since it didn't even matter that it did a
simulation.

This is part of your whole problem, you absolutely need to be consistant
to make your argument, but you keep on going off with inconsistent
arguments, which makes sense since it really appears that you logic
system is inconsistent.

H claiming that P(P) is non-halting can only be supported by a VALID
arguemnt showing a valid chain of reasoning to get to that conclusion.

You never give that, and one common root is that if H might abort its
simulation then you can not presume that H's simulation will be an
accurate depiction of the behavior of the machine, but the only way that
H can get the evidence to decide to abort its simulation is to presume
that it is such a simulation.

Yes, all you have done is jump up and down and yelled and screemed that
your H is a correct Halt Decider, but you havn't actually done anything
to acutally prove this.

BY DEFINITION, since when H(P,P) returns 0, the structure of P makes P
halt, then H(P,P) can never return 0 and be correct.

There is a case when returning zero WOULD have been correct, this
happens when H actually DOES a pure simulation of its input, but inthis
case H never actually does return that 0, so it remains not a proper
decider so isn't a counter example for Linz.

You are basically just a two faced liar, as you keep on switching your
definitions in the middle of a statement. That is just plain lying.

Linz proof shows that by the structure of the machine H^, that it is
actually IMPOSSIBLE of ANY H to return the right answer for the halting
status of the computation H^(<H^>) that was built on that H.

IMPOSSIBLE.

The key fact is that, by the nature of the way Turing Machines are
defined, it is possible for H^ to force H to give an answer in finite
time of how it will answer, and then it can act in the opposite.

The only way imaginable for H to win is to prevent H^ from using it, but
that just isn't possible with Turing Machines. Since every Turing
Machine performs a Computation and every Computation can be computed
with a Turing Machine, there is no space of H to hide and not let H^ use it.

[Richard Damon]

NOPE. You can not provide an H that has H(P,P) returning 0 and also the
direct execution of P(P) doesn't halt.

Yes, there are H's that never abort their operation and results in a
P(P) that is non-halting, but those H's never return the value 0 for H(P,P).

If you are making the assertion that such an H exists, the challenge is
to provide it.

Failure means you admit to lying.

[olcott]

All rebuttals must take this form:
Find an invocation of H(P,P) at machine address 00001a7e such that the
simulation or execution of (the exact byte sequence of) P reaches its
final address of 00001a72.

[Richard Damon]

No, they don't. You LIE when you make that claim.

The criteria you are asking for has NOTHING to do with the REQUIRED
DEFINITION OF HALTING, which is based on the behavior of the program
when DIRECTLY RUN.

ANY H(P,P) which returns 0 to the call of H(P,P) will get to 1A72 when
that P is run directly.

This has been proven, and you even agreed to it.

I, and the world, will take this as your admission of being a LIAR.

That is going to be your eternal legacy, branded as a LIAR, not willing
to admit that you don't understand what you talk about.

[olcott]

halt decider (Olcott 2021)
A halt decider accepts or rejects an input on the basis of whether or
not the direct execution or (possibly partial) pure simulation of this

input would ever reach a final state of this input.

I claim that the halt status for a specific H(P,P) is never halting
therefore every correct rebuttal must show that one of these instances
halts.

> ANY H(P,P) which returns 0 to the call of H(P,P) will get to 1A72 when
> that P is run directly.
>
> This has been proven, and you even agreed to it.
>
> I, and the world, will take this as your admission of being a LIAR.
>
> That is going to be your eternal legacy, branded as a LIAR, not willing
> to admit that you don't understand what you talk about.
>
>

--
Copyright 2021 Pete Olcott

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

[Richard Damon]

So, given that H(P,P) rejects P, which MEANS that it returns the value
of 0 from a 'call' to H(P,P) in some finite time.

Therefore a simple trace of the function P being directly executed is:

[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H

// Trace inside H not provided as you refuse to provide the code for H.
// BUT we know from the stipulation that H will reject P(P) in finite
// time, that in finite time it WILL return the value 0

[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret

THERE.

SHow what is wrong with this DIRECT execution of P(P).


Remember, the 'halt status' that H needs to decide on is the halt status
of the machine that the input represents, that is in this case the
computation P(P).

You are stuck with the fact that since H is defined to be a Turing
Machine, all copies of H will behave the same, so if the deciding copy
of H returns 0 for the call H(P,P) so will the copy in P.

If you want to claim otherwise, H no longer meets the requirements to BE
a decider.

FAIL.

[olcott]

Find a counter-example to this:

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]

H(P,P)==0 is correct for every H at machine address 00001a7e with the
above string of machine language bytes as its input.

**All rebuttals must take this form**

Find an invocation of H(P,P) at machine address 00001a7e such that the
simulation or execution of (the exact byte sequence of) P reaches its
final address of 00001a72.

[Richard Damon]

It rebuts itself.

Given that the call to H will return in finite time, then that sequence
of bytes will be executed.

Yes, if H doesn't actually return (and thus never returns 0) the
returning 0 would have been the right answer, but not the answer that H
gives, so the exists no H that correctly return 0.


It is NOT my job to find an H.

YOU need to provide an H that works.

All your Hs will fail in one of two ways:

1) They will NOT return the value 0

2) The P that they create will halt after they return the number 0.


A real simple counter example:

[00001a7e](01) c3 ret


That H will immediately return and P will get to 1A72.

FAIL.

[olcott]

That merely proves that you really aren't paying attention.
The above specification applies to every H that can possibly exist
including ones that do not return in finite time.

[Richard Damon]

Except that ones that don't return in finite time are not possible
counter examples to the Halting problem.

You seem to have lost your way.

Yes H(P,P) == 0 would be the right answer for the halting status of any
P(P) built on a H that doesn't return from H(P,P), but such an H fails
to be a counter example because it doesn't give the right answer.

IF H(P,P) actually returns 0, the it is shown that the P from that H
will be halting in computing P(P), so the 0 returned by H(PP) is wrong.

Therefore, there is no H that correctly return 0 from H(P,P).

PERIOD.

I think you have lost your last marble.


It is NOT good enough to just prove that for some H, that H(P,P) == 0
would be the right answer, you need to also show that this H DOES return
that value.

The fact that H(P,P) == 0 is right for some H, doesn't make it right for
all H. That is a FALSEHOOD.

FAIL.

You lies are getting worse.

[olcott]

When the specific P is executed or simulated by every element of an
infinte set of differently defined H never halts then H(P,P)==0 is
always correct no matter what H actually does.

The subset of these that return 0 are correct halt deciders for their
input.

[Richard Damon]

Except that is nonsense, as every H in that set needs to worry about the
P that is specific to IT.

>
> The subset of these that return 0 are correct halt deciders for their
> input.
>

But, if that P is NOT the P derived from it, they are not counter
examples to Linz.

It doesn't matter if some Hi can correctly decide an infinite number of
Pj correctly if it doesn't get Pi correct.

In every case, when Hi is asked to compute Hi(Pi,Pi) then one of the
following to things happen:

1) Either Hi{Pi,Pi) does not return the value 0, or
2) Hi(Pi,Pi) does return the value 0, but Pi(Pi) halts.

In both cases Hi fails to be a counter example for Linz.

FAIL.

You HAVE lost your way and trying to claim meaningless statements.

[olcott]

On 11/13/2021 10:10 AM, Richard Damon wrote:
>
> On 11/13/21 11:01 AM, olcott wrote:
>> On 11/13/2021 9:30 AM, Richard Damon wrote:
>>>
>>> Except that ones that don't return in finite time are not possible
>>> counter examples to the Halting problem.
>>>
>>> You seem to have lost your way.
>> When the specific P is executed or simulated by every element of an
>> infinte set of differently defined H never halts then H(P,P)==0 is
>> always correct no matter what H actually does.
>
> Except that is nonsense, as every H in that set needs to worry about the
> P that is specific to IT.

It is nonsense that a computation has the emotional state of worry.

>
>>
>> The subset of these that return 0 are correct halt deciders for their
>> input.
>>
>
> But, if that P is NOT the P derived from it, they are not counter
> examples to Linz.
>
> It doesn't matter if some Hi can correctly decide an infinite number of
> Pj correctly if it doesn't get Pi correct.
>
> In every case, when Hi is asked to compute Hi(Pi,Pi) then one of the
> following to things happen:
>
> 1) Either Hi{Pi,Pi) does not return the value 0, or
> 2) Hi(Pi,Pi) does return the value 0, but Pi(Pi) halts.
>
> In both cases Hi fails to be a counter example for Linz.
>
> FAIL.
>
> You HAVE lost your way and trying to claim meaningless statements.

[Richard Damon]

On 11/13/21 11:29 AM, olcott wrote:
> On 11/13/2021 10:10 AM, Richard Damon wrote:
>>
>> On 11/13/21 11:01 AM, olcott wrote:
>>> On 11/13/2021 9:30 AM, Richard Damon wrote:
>>>>
>>>> Except that ones that don't return in finite time are not possible
>>>> counter examples to the Halting problem.
>>>>
>>>> You seem to have lost your way.
>>> When the specific P is executed or simulated by every element of an
>>> infinte set of differently defined H never halts then H(P,P)==0 is
>>> always correct no matter what H actually does.
>>
>> Except that is nonsense, as every H in that set needs to worry about
>> the P that is specific to IT.
>
> It is nonsense that a computation has the emotional state of worry.

Ok, to be precise, the only case that MATTERS (for your proof) is that H
needs to get right its answer for the P that was specific to it.

None of you Hs get right the answer for the P built from them, thus none
of you Hs are counter example to Linz, so YOU FAIL.