olcott <NoOne@NoWhere.com> writes:

> On 7/5/2021 5:58 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> | void P(u32 x)
>> | {
>> | u32 Input_Halts = H(x, x);
>> | if (Input_Halts)
>> | HERE: goto HERE;
>> | }
>>
>>> Every computation that would never halt unless its simulation is
>>> aborted is equally not a halting computation.
>>
>> For H(P,P) to be correct one of these must apply:
>> H(P,P) == 0 and P(P) does not halt, or
>> H(P,P) != 0 and P(P) halts.
>> Neither is the case. Simple facts that you deny.
>>
>
> That the prefix to infinitely nested simulation halts because its
> suffix is aborted cannot reasonably be construed as a computation that
> halts in the same way that that following computation can be construed
> as a computation that halts:
>
> int Add(int N, int M)
> {
> return N + M;
> }

You are welcome to think that different computations halt in different
ways. However, a computation that halts, for whatever reason, is a
halting computation. P(P) halts, so H(P,P) == 0 is wrong.

> Every computation that never halts unless is simulation is aborted
> defines the exact same set of non-halting computations as the halting
> problem, except for the halting problem counter-example templates.

Yes, H(P,P) == 0 is wrong if P(P) halts. As you have defined it, the
POOH ("PO Other-Halting") problem is also undecidable, but that's just
way over your head right now, despite the fact you keep quoting me
saying that.

> Because it defines the exact same halting and non-halting set of
> computations as the halting problem it is proved to be an equivalent
> criterion measure.

You just said they are not the same sets. You have given an explicit
example where they differ: P(P) halts but is non-POOH. I don't think
you are coping very well. I think you should take a break.

--
Ben.

On 7/5/2021 9:35 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/5/2021 5:58 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>> | void P(u32 x)
>>> | {
>>> | u32 Input_Halts = H(x, x);
>>> | if (Input_Halts)
>>> | HERE: goto HERE;
>>> | }
>>>
>>>> Every computation that would never halt unless its simulation is
>>>> aborted is equally not a halting computation.
>>>
>>> For H(P,P) to be correct one of these must apply:
>>> H(P,P) == 0 and P(P) does not halt, or
>>> H(P,P) != 0 and P(P) halts.
>>> Neither is the case. Simple facts that you deny.
>>>
>>
>> That the prefix to infinitely nested simulation halts because its
>> suffix is aborted cannot reasonably be construed as a computation that
>> halts in the same way that that following computation can be construed
>> as a computation that halts:
>>
>> int Add(int N, int M)
>> {
>> return N + M;
>> }
>
> You are welcome to think that different computations halt in different
> ways. However, a computation that halts, for whatever reason, is a
> halting computation. P(P) halts, so H(P,P) == 0 is wrong.
>

H(P,P) == 0 is axiomatically correct thus impossibly incorrect.

If all X's are Y and all Y's are Z then all X's are Z even if you really
really hate it and even if it really really seems to form a direct
contradiction.

>> Every computation that never halts unless is simulation is aborted
>> defines the exact same set of non-halting computations as the halting
>> problem, except for the halting problem counter-example templates.
>
> Yes, H(P,P) == 0 is wrong if P(P) halts. As you have defined it, the
> POOH ("PO Other-Halting") problem is also undecidable, but that's just
> way over your head right now, despite the fact you keep quoting me
> saying that.
>

Once you understand that H(P,P) == 0 is axiomatically correct thus
impossibly incorrect, then you see that the fact that P(P) halts cannot
possibly be a contradiction.

The view that H(P,P) == 0 is not correct requires the view that in some
cases where UTM(P,I) never halts P(I) does halt.

Since we know that every case where UTM(P,I) never halts logically
entails that P(I) never halts we know that when the pure x86 emulation
of (P,I) never halts that this logically entails that the x86 execution
of P(I) never halts.

Since we know that H acts as a pure x86 emulator until it detects that
its input would never halt unless aborted then H can always ignore its
own address range when it is making its halt status decision.

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

Because we can see that the execution trace of P on input P provides no
escape from its infinitely nested simulation we can know that H must
abort its simulation of (P,P).

int main()
{ P((u32)P);
}

The fact that the above computation never halts unless some H aborts
some P (in the nested simulation) proves that this H that aborted that P
was correct.

>> Because it defines the exact same halting and non-halting set of
>> computations as the halting problem it is proved to be an equivalent
>> criterion measure.
>
> You just said they are not the same sets. You have given an explicit
> example where they differ: P(P) halts but is non-POOH. I don't think
> you are coping very well. I think you should take a break.
>

--
Copyright 2021 Pete Olcott

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

On 7/5/21 11:30 PM, olcott wrote:
> On 7/5/2021 9:35 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/5/2021 5:58 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>> |    void P(u32 x)
>>>> |    {
>>>> |      u32 Input_Halts = H(x, x);
>>>> |      if (Input_Halts)
>>>> |     HERE: goto HERE;
>>>> |    }
>>>>
>>>>> Every computation that would never halt unless its simulation is
>>>>> aborted is equally not a halting computation.
>>>>
>>>> For H(P,P) to be correct one of these must apply:
>>>>          H(P,P) == 0 and P(P) does not halt, or
>>>>          H(P,P) != 0 and P(P) halts.
>>>> Neither is the case.  Simple facts that you deny.
>>>>
>>>
>>> That the prefix to infinitely nested simulation halts because its
>>> suffix is aborted cannot reasonably be construed as a computation that
>>> halts in the same way that that following computation can be construed
>>> as a computation that halts:
>>>
>>> int Add(int N, int M)
>>> {
>>>    return N + M;
>>> }
>>
>> You are welcome to think that different computations halt in different
>> ways.  However, a computation that halts, for whatever reason, is a
>> halting computation.  P(P) halts, so H(P,P) == 0 is wrong.
>>
>
> H(P,P) == 0 is axiomatically correct thus impossibly incorrect.

H(P,P) == 0 is by DEFINITION incorrect since P(P) does Halt. Your
'axioms' are incorrect, thus your logic unsound.

>
> If all X's are Y and all Y's are Z then all X's are Z even if you really
> really hate it and even if it really really seems to form a direct
> contradiction.

But Halting is Halting, and P(P) is Halting.
>>> Every computation that never halts unless is simulation is aborted
>>> defines the exact same set of non-halting computations as the halting
>>> problem, except for the halting problem counter-example templates.
>>
>> Yes, H(P,P) == 0 is wrong if P(P) halts.  As you have defined it, the
>> POOH ("PO Other-Halting") problem is also undecidable, but that's just
>> way over your head right now, despite the fact you keep quoting me
>> saying that.
>>
>
> Once you understand that H(P,P) == 0 is axiomatically correct thus
> impossibly incorrect, then you see that the fact that P(P) halts cannot
> possibly be a contradiction.

But it isn't. PERIOD.

>
> The view that H(P,P) == 0 is not correct requires the view that in some
> cases where UTM(P,I) never halts P(I) does halt.

Except UTM(P,P) does Halt for this P. Your problem is that you forget
that P changes when you change H (is that why you dropped the hat
notation, H^ made it clear that H^ was based on H?)

>
> Since we know that every case where UTM(P,I) never halts logically
> entails that P(I) never halts we know that when the pure x86 emulation
> of (P,I) never halts that this logically entails that the x86 execution
> of P(I) never halts.

Except that UTH(H^,H^) does halt. UNSOUND LOGIC.
>
> Since we know that H acts as a pure x86 emulator until it detects that
> its input would never halt unless aborted then H can always ignore its
> own address range when it is making its halt status decision.

But 'Acts as (x) until ...' is NOT that same as 'IS (x)'. H is NOT a
pure simulator, so you can't treat it as one for logical proofs.

>
> void P(u32 x)
> {
>   u32 Input_Halts = H(x, x);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
> Because we can see that the execution trace of P on input P provides no
> escape from its infinitely nested simulation we can know that H must
> abort its simulation of (P,P).

An incorrect trace built on transformations built on faulty logic. That
trace is only valid if H NEVER abort a simulation. Since it does, the
transformation done is invalid, so H made an unsound conclusion.

>
> int main()
> {
>   P((u32)P);
> }
>
> The fact that the above computation never halts unless some H aborts
> some P (in the nested simulation) proves that this H that aborted that P
> was correct.
>

Not the definition on Halting. Your core probelm.

P DOES get to its terminal state, thus it is Halting.

>>> Because it defines the exact same halting and non-halting set of
>>> computations as the halting problem it is proved to be an equivalent
>>> criterion measure.
>>
>> You just said they are not the same sets.  You have given an explicit
>> example where they differ: P(P) halts but is non-POOH.  I don't think
>> you are coping very well.  I think you should take a break.
>>
>
>

this is a theory group. get the hell out.

olcott <NoOne@NoWhere.com> writes:

> On 7/5/2021 9:35 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/5/2021 5:58 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>> | void P(u32 x)
>>>> | {
>>>> | u32 Input_Halts = H(x, x);
>>>> | if (Input_Halts)
>>>> | HERE: goto HERE;
>>>> | }
>>>>
>>>>> Every computation that would never halt unless its simulation is
>>>>> aborted is equally not a halting computation.
>>>>
>>>> For H(P,P) to be correct one of these must apply:
>>>> H(P,P) == 0 and P(P) does not halt, or
>>>> H(P,P) != 0 and P(P) halts.
>>>> Neither is the case. Simple facts that you deny.

> H(P,P) == 0 is axiomatically correct thus impossibly incorrect.

H(P,P) == 0 may well be the correct POOH answer. Since you get to
define the PO "Other-Halting" problem, you get to state what the correct
answers are. In that sense it's axiomatic. My only objection can be
that no one cares about the POOH problem.

H is clearly not computing the halting function as it returns 0 for a
halting computation. You don't get to "adjust" (as you so
euphemistically say) the definition of halting.

> Once you understand that H(P,P) == 0 is axiomatically correct thus
> impossibly incorrect, then you see that the fact that P(P) halts
> cannot possibly be a contradiction.

I have never challenged your right to define a new decision problem.
What the correct answers are is then entirely up to you, and though I'd
call them definitions rather than axioms they can only be challenged as
being silly or not interesting (and they are both).

> The view that H(P,P) == 0 is not correct requires the view that in
> some cases where UTM(P,I) never halts P(I) does halt.

UTM(P,P) halts because P(P) halts.

> Because we can see that the execution trace of P on input P...

.... halts, we know that H is not a halt decider because it is wrong
about the P(P) case. H may well be a POOH decider. You get to define
what the right answers are for a POOH decider.

--
Ben.