On 7/31/21 12:41 PM, olcott wrote:
> On 7/31/2021 2:14 PM, Richard Damon wrote:
>> On 7/31/21 11:52 AM, olcott wrote:
>>> On 7/31/2021 1:25 PM, Richard Damon wrote:
>>>> On 7/31/21 10:00 AM, olcott wrote:
>>>>> On 7/31/2021 10:41 AM, Richard Damon wrote:
>>>>>> On 7/31/21 8:20 AM, olcott wrote:
>>>>>>
>>>>>>> The halt decider does not freaking fail on its freaking inputs.
>>>>>>
>>>>>> Yes it does. Even YOU have provided the proof of this.
>>>>>>
>>>>>> P(P) Halts.
>>>>>> H(P,P) says that P(P) is non-halting.
>>>>>> Thus, it is WRONG.
>>>>>>
>>>>>>>
>>>>>>> We know with 100% perfect complete logical certainty that the halt
>>>>>>> decider does correctly decide that its input never halts.
>>>>>>
>>>>>> You may THINK that, but you are mistaken.
>>>>>>
>>>>>>>
>>>>>>> That the input cannot possibly ever reach its final state of 0xc3f
>>>>>>> whether or not H aborts the simulation of this input conclusively
>>>>>>> proves
>>>>>>> that this input never halts beyond all possible logically correct
>>>>>>> doubt.
>>>>>>
>>>>>> That H does not happen to be able to simulate H to its end does not
>>>>>> prove anything, because H does incorrectly abort its simulation.
>>>>>>
>>>>>
>>>>> The input to H(P,P) cannot possibly reach its final state 0xc3f
>>>>> under a
>>>>> verifiably perfectly correct pure simulation of this input.
>>>>>
>>>>>
>>>>
>>>> Yes, if H is a pure simulator, then H^(H^) is non-Halting, but H(H^,H^)
>>>> is still wrong as if H is a pure simulator it never returns an answer.
>>>>
>>>> FAIL
>>>>
>>>
>>> You are only saying that a person cannot possibly make a left hand turn
>>> without making a left hand turn.
>>
>> No, I am saying that someone can not claim to only make left hand turns
>> if he does 50 left hand turns in a row and then makes a right hand turn.
>>
>> A Pure Simulator is one that NEVER stops simulating.
>>
>> Something that at some point stops simulting was NEVER a pure simulator.
>>
>>
>> IF you really believe what you claim, then tell us what the soup that
>> was 'pure' until you crapped in it tastes like. After all, if 'pure
>> until' is pure, then it still is a pure healthy meal.
>>
>>>
>>> Because the input to H(P,P) cannot possibly ever reach its final state
>>> 0xc3f either by a perfectly correct pure simulation or when this
>>> simulation is aborted we can know with 100% perfectly justified logical
>>> certainty that the input to H(P,P) never halts. From this we know with
>>> 100% perfectly justified logical certainty that H(P,P)==0 is correct.
>>
>> WRONG.
>>
>> You look at a wrong definition.
>>
>> Since H is NOT a PURE UNCONDITIONAL Simulator then the fact that H
>> doesn't reach the halting state doesn't prove ANYTHING other than H^
>> doesn't halt in less than the number of steps that it simulated.
>
> Anyone knowing the x86 language well enough (apparently not you) can see
> that the simulation of P cannot possibly ever reach its its final state
> of 0xc3f in an infinite number of steps.

Obviously YOU don't understand x86 assembly, as it is very clear that if
H return a 0 value (which it does) then P will return.

You only get your conclusion if you insert the FALSE assumption that H
will never return.

>
> _P()
> [00000c25](01)  55          push ebp
> [00000c26](02)  8bec        mov ebp,esp
> [00000c28](03)  8b4508      mov eax,[ebp+08]
> [00000c2b](01)  50          push eax       // 2nd Param
> [00000c2c](03)  8b4d08      mov ecx,[ebp+08]
> [00000c2f](01)  51          push ecx       // 1st Param
> [00000c30](05)  e820fdffff  call 00000955  // call H
> [00000c35](03)  83c408      add esp,+08
> [00000c38](02)  85c0        test eax,eax
> [00000c3a](02)  7402        jz 00000c3e
> [00000c3c](02)  ebfe        jmp 00000c3c
> [00000c3e](01)  5d          pop ebp
> [00000c3f](01)  c3          ret
> Size in bytes:(0027) [00000c3f]
>
> If any H ever aborts its simulation of P or no H ever aborts its
> simulation of P it never reaches its final state of 0xc3f.

The fact that the H we use happens to abort its simulation of a copy of
P it is simulating has ZERO impact of the fact that THIS copy finished
to its halting state (if it was the top level machine).

The fact that the top level machine does Halt PROVES that H was WRONG in
it determination that P was non-halting.
>
> Because P cannot possibly ever reach its final state we know for sure
> that P never halts.
>

FALSE PREMISE. P DOES reach its final state BECAUSE H incorrectly
aborted a different simulation.

FALSE PREMISE -> UNSOUND LOGIC.

H, and YOU are WRONG.

On 7/31/21 12:52 PM, olcott wrote:
> On 7/31/2021 2:23 PM, Richard Damon wrote:
>> On 7/31/21 11:57 AM, olcott wrote:
>>> On 7/31/2021 1:31 PM, Richard Damon wrote:
>>>> On 7/31/21 9:35 AM, olcott wrote:
>>>>
>>>>>
>>>>> One would think that this is true, yet because H knows that it only
>>>>> acts
>>>>> as a pure simulator of its input until after its halt status decision
>>>>> has been made it knows that it has no behavior that can possibly
>>>>> effect
>>>>> the behavior of P. Because of this H knows that it can totally ignore
>>>>> all of its own behavior in any execution trace that it examines as the
>>>>> basis of its halt status decision.
>>>>
>>>> Something that acted like a 'pure simulator until ...' is NOT a pure
>>>> simulator.
>>>>
>>>
>>> You are dishonestly dodging the point by dishonestly changing the
>>> subject to a different subject.
>>
>> What different subject? We are talking about the soundness of your
>> argument. You claim that you can treat H as a Pure Simulator, when it
>> isn't since it is only a pure simulator until ... which is NOT a pure
>> simulator.
>>
>> By Your Logic, you must think Trump still has Presidental powers,
>> because he was President until he got voted out.
>>
>>>
>>> The point is that because H acts as a pure simulator until after its
>>> halt status decision has been made H can ignore its own behavior in any
>>> execution traces.
>>
>> FALSE. DISPROVEN. UNSOUND. DELUSIONAL even.
>>
>> Try to actually prove it.
>>
>
> You apparently are not bright enough to understand this.

YOU seem to not be bright enough to see the Truth.
>
> People that are bright enough to understand this simply comprehend that
> a pure simulator or a simulating halt decider in pure simulation mode
> cannot possibly have any effect on the behavior of its input.

But it DOES on the machine that uses it, so H needs to evalutate THAT
effect on the copies of H that it encounters.

>
> These same people understand that because it cannot possibly have any
> effect on the behavior of its input that logically entails that it
> cannot possibly have any effect on any halt status decision of the
> behavior of this input.
>

THAT COPY can't affect the behavior of its input. The copies of it that
it finds can have inpact on the machines that use them.

FAIL.

> Finally these same people that understand that the behavior of the
> simulating halt decider while it is in pure simulation mode cannot not
> have any effect on its halt status decision will understand that this
> simulating halt decider can screen out its own address range and thus
> ignore its own behavior in any halt status decision as long as it only
> does this while it remains in pure simulation mode.

WRONG.

UNSOUND LOGIC.

Beware being an intentional Liar, YOU have even quoted the penalty for that.

On 7/31/2021 2:54 PM, Richard Damon wrote:
> On 7/31/21 12:41 PM, olcott wrote:
>> On 7/31/2021 2:14 PM, Richard Damon wrote:
>>> On 7/31/21 11:52 AM, olcott wrote:
>>>> On 7/31/2021 1:25 PM, Richard Damon wrote:
>>>>> On 7/31/21 10:00 AM, olcott wrote:
>>>>>> On 7/31/2021 10:41 AM, Richard Damon wrote:
>>>>>>> On 7/31/21 8:20 AM, olcott wrote:
>>>>>>>
>>>>>>>> The halt decider does not freaking fail on its freaking inputs.
>>>>>>>
>>>>>>> Yes it does. Even YOU have provided the proof of this.
>>>>>>>
>>>>>>> P(P) Halts.
>>>>>>> H(P,P) says that P(P) is non-halting.
>>>>>>> Thus, it is WRONG.
>>>>>>>
>>>>>>>>
>>>>>>>> We know with 100% perfect complete logical certainty that the halt
>>>>>>>> decider does correctly decide that its input never halts.
>>>>>>>
>>>>>>> You may THINK that, but you are mistaken.
>>>>>>>
>>>>>>>>
>>>>>>>> That the input cannot possibly ever reach its final state of 0xc3f
>>>>>>>> whether or not H aborts the simulation of this input conclusively
>>>>>>>> proves
>>>>>>>> that this input never halts beyond all possible logically correct
>>>>>>>> doubt.
>>>>>>>
>>>>>>> That H does not happen to be able to simulate H to its end does not
>>>>>>> prove anything, because H does incorrectly abort its simulation.
>>>>>>>
>>>>>>
>>>>>> The input to H(P,P) cannot possibly reach its final state 0xc3f
>>>>>> under a
>>>>>> verifiably perfectly correct pure simulation of this input.
>>>>>>
>>>>>>
>>>>>
>>>>> Yes, if H is a pure simulator, then H^(H^) is non-Halting, but H(H^,H^)
>>>>> is still wrong as if H is a pure simulator it never returns an answer.
>>>>>
>>>>> FAIL
>>>>>
>>>>
>>>> You are only saying that a person cannot possibly make a left hand turn
>>>> without making a left hand turn.
>>>
>>> No, I am saying that someone can not claim to only make left hand turns
>>> if he does 50 left hand turns in a row and then makes a right hand turn.
>>>
>>> A Pure Simulator is one that NEVER stops simulating.
>>>
>>> Something that at some point stops simulting was NEVER a pure simulator.
>>>
>>>
>>> IF you really believe what you claim, then tell us what the soup that
>>> was 'pure' until you crapped in it tastes like. After all, if 'pure
>>> until' is pure, then it still is a pure healthy meal.
>>>
>>>>
>>>> Because the input to H(P,P) cannot possibly ever reach its final state
>>>> 0xc3f either by a perfectly correct pure simulation or when this
>>>> simulation is aborted we can know with 100% perfectly justified logical
>>>> certainty that the input to H(P,P) never halts. From this we know with
>>>> 100% perfectly justified logical certainty that H(P,P)==0 is correct.
>>>
>>> WRONG.
>>>
>>> You look at a wrong definition.
>>>
>>> Since H is NOT a PURE UNCONDITIONAL Simulator then the fact that H
>>> doesn't reach the halting state doesn't prove ANYTHING other than H^
>>> doesn't halt in less than the number of steps that it simulated.
>>
>> Anyone knowing the x86 language well enough (apparently not you) can see
>> that the simulation of P cannot possibly ever reach its its final state
>> of 0xc3f in an infinite number of steps.
>
> Obviously YOU don't understand x86 assembly, as it is very clear that if
> H return a 0 value (which it does) then P will return.
>

P never ever returns any value to its input. This is the part that you
very persistently ignore. I really do honestly believe that you probably
do have attention deficit disorder.

> You only get your conclusion if you insert the FALSE assumption that H
> will never return.
>
>>
>> _P()
>> [00000c25](01)  55          push ebp
>> [00000c26](02)  8bec        mov ebp,esp
>> [00000c28](03)  8b4508      mov eax,[ebp+08]
>> [00000c2b](01)  50          push eax       // 2nd Param
>> [00000c2c](03)  8b4d08      mov ecx,[ebp+08]
>> [00000c2f](01)  51          push ecx       // 1st Param
>> [00000c30](05)  e820fdffff  call 00000955  // call H
>> [00000c35](03)  83c408      add esp,+08
>> [00000c38](02)  85c0        test eax,eax
>> [00000c3a](02)  7402        jz 00000c3e
>> [00000c3c](02)  ebfe        jmp 00000c3c
>> [00000c3e](01)  5d          pop ebp
>> [00000c3f](01)  c3          ret
>> Size in bytes:(0027) [00000c3f]
>>
>> If any H ever aborts its simulation of P or no H ever aborts its
>> simulation of P it never reaches its final state of 0xc3f.
>
> The fact that the H we use happens to abort its simulation of a copy of
> P it is simulating has ZERO impact of the fact that THIS copy finished
> to its halting state (if it was the top level machine).
>
> The fact that the top level machine does Halt PROVES that H was WRONG in
> it determination that P was non-halting.
>>
>> Because P cannot possibly ever reach its final state we know for sure
>> that P never halts.
>>
>
> FALSE PREMISE. P DOES reach its final state BECAUSE H incorrectly
> aborted a different simulation.
>
> FALSE PREMISE -> UNSOUND LOGIC.
>
> H, and YOU are WRONG.
>

--
Copyright 2021 Pete Olcott

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

On 7/31/2021 3:02 PM, Richard Damon wrote:
> On 7/31/21 12:52 PM, olcott wrote:
>> On 7/31/2021 2:23 PM, Richard Damon wrote:
>>> On 7/31/21 11:57 AM, olcott wrote:
>>>> On 7/31/2021 1:31 PM, Richard Damon wrote:
>>>>> On 7/31/21 9:35 AM, olcott wrote:
>>>>>
>>>>>>
>>>>>> One would think that this is true, yet because H knows that it only
>>>>>> acts
>>>>>> as a pure simulator of its input until after its halt status decision
>>>>>> has been made it knows that it has no behavior that can possibly
>>>>>> effect
>>>>>> the behavior of P. Because of this H knows that it can totally ignore
>>>>>> all of its own behavior in any execution trace that it examines as the
>>>>>> basis of its halt status decision.
>>>>>
>>>>> Something that acted like a 'pure simulator until ...' is NOT a pure
>>>>> simulator.
>>>>>
>>>>
>>>> You are dishonestly dodging the point by dishonestly changing the
>>>> subject to a different subject.
>>>
>>> What different subject? We are talking about the soundness of your
>>> argument. You claim that you can treat H as a Pure Simulator, when it
>>> isn't since it is only a pure simulator until ... which is NOT a pure
>>> simulator.
>>>
>>> By Your Logic, you must think Trump still has Presidental powers,
>>> because he was President until he got voted out.
>>>
>>>>
>>>> The point is that because H acts as a pure simulator until after its
>>>> halt status decision has been made H can ignore its own behavior in any
>>>> execution traces.
>>>
>>> FALSE. DISPROVEN. UNSOUND. DELUSIONAL even.
>>>
>>> Try to actually prove it.
>>>
>>
>> You apparently are not bright enough to understand this.
>
> YOU seem to not be bright enough to see the Truth.
>>
>> People that are bright enough to understand this simply comprehend that
>> a pure simulator or a simulating halt decider in pure simulation mode
>> cannot possibly have any effect on the behavior of its input.
>
> But it DOES on the machine that uses it, so H needs to evalutate THAT
> effect on the copies of H that it encounters.

I don't know what your weasel words mean.

Because P cannot possibly have any effect on the behavior of its inputs
P can ignore its own behavior in every execution trace that it examines.

>>
>> These same people understand that because it cannot possibly have any
>> effect on the behavior of its input that logically entails that it
>> cannot possibly have any effect on any halt status decision of the
>> behavior of this input.
>>
>
> THAT COPY can't affect the behavior of its input. The copies of it that
> it finds can have inpact on the machines that use them.
>
> FAIL.
>
>> Finally these same people that understand that the behavior of the
>> simulating halt decider while it is in pure simulation mode cannot not
>> have any effect on its halt status decision will understand that this
>> simulating halt decider can screen out its own address range and thus
>> ignore its own behavior in any halt status decision as long as it only
>> does this while it remains in pure simulation mode.
>
> WRONG.
>
> UNSOUND LOGIC.
>
> Beware being an intentional Liar, YOU have even quoted the penalty for that.
>

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> It matters not what I had.

Because you can't justify it the honest debate you claim to want.

> It only matters what I have.

I.e. nothing of any interest. You make it plain in a previous reply
that you've had nothing of interest going right back to the original
deceptive claim.

> If you are sincere about an honest dialogue then we must quit focusing
> on details of obsolete technology.

And yet you skipped the big picture part:

>> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
>> Dec 2018 code come to about "(Ĥ, Ĥ)"?
>
> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
> H(P,P)==0 now except that the never halting criteria is much more
> elaborate. The initial criteria was very crude.

Ah, so you never had H and H_Hat that do anything that anyone would say
is impossible. Had you said, back in Dec 2018, "I have C code such that
H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
interested.

I think you owe everyone an apology. Even if there was no indent to
deceive, your words back then did everything possible to suggest some
impossible Turing machine. And you wouldn't say, until recently, even
when explicitly asked, what decision H came to. It was fishy from the
start.

--
Ben.

On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> It matters not what I had.
>
> Because you can't justify it the honest debate you claim to want.
>
>> It only matters what I have.
>
> I.e. nothing of any interest. You make it plain in a previous reply
> that you've had nothing of interest going right back to the original
> deceptive claim.
>
>> If you are sincere about an honest dialogue then we must quit focusing
>> on details of obsolete technology.
>
> And yet you skipped the big picture part:
>
>>> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
>>> Dec 2018 code come to about "(Ĥ, Ĥ)"?
>>
>> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
>> H(P,P)==0 now except that the never halting criteria is much more
>> elaborate. The initial criteria was very crude.
>
> Ah, so you never had H and H_Hat that do anything that anyone would say
> is impossible. Had you said, back in Dec 2018, "I have C code such that
> H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
> interested.
>

If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.

If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.

If you are sincere about an honest dialogue then we must quit focusing
on details of obsolete technology.

> I think you owe everyone an apology. Even if there was no indent to
> deceive, your words back then did everything possible to suggest some
> impossible Turing machine. And you wouldn't say, until recently, even
> when explicitly asked, what decision H came to. It was fishy from the
> start.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 7/30/2021 2:58 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/30/2021 7:39 AM, Ben Bacarisse wrote:
>>
>>>> Any chance you will now say if
>>>>
>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
>>>>
>>>> transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult,
>>>> please ask for some help in understanding it.
>>>
>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn
>>
>> An answer. Thank you.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause
>> that applies to your H and Ĥ:
>
> There is no H in the relevant last paragraph of the Linz proof that
> forms the basis for the Linz conclusion.

Distraction. Everything you ignore below is about the proof and refers
only to Ĥ.

>>>>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>>>>>>> if M applied to wM does not halt
>>
>> so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me
>> that it does. That is what this full (but abbreviated) state transition
>> sequence means:
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Which is it?
>
> Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the
> ⟨Ĥ2⟩ copy then
> Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the
> ⟨Ĥ3⟩ copy then
> Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the
> ⟨Ĥ4⟩ copy then ...

This is an abuse of the notation (but I know what you mean). There is
no Ĥ1 or Ĥ2. If you think it helps to show which copy of ⟨Ĥ⟩ your
simulating "decider" is either running and/or currently looking at, you
need to come up with a notation that does that. At least I know what
this "math poem" means, because you've been saying this "it's a
simulator until" stuff for years.

> The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩)
> can't possibly ever reach its final state. Then it transitions to
> Ĥ0.qn causing the outermost Ĥ0 to halt.

Apart from the bad notation, yes. All those copies and tests and
eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

> Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt
> and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly
> ever reach its final state there is no contradiction or paradox and it
> decided correctly.

You are free to define "decide correctly" in any way you like provided
you are honest about it. But you hooked people in by saying that your Ĥ
is "exactly and precisely as in Linz", and you quoted, even now, what
Linz has to say about such TMs:

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

This is your quote. You brought it up. You claimed your Ĥ was as Linz
states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not
halt. Linz makes no exceptions based on why the transitions from Ĥ.q0
wM to Ĥ.qn occur. Linz does not say

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt or if M applied wM only halts
because...

Are you now saying that your TM was not "as in Linz"? (You should,
because you've admitted that elsewhere.)

--------
You have real trouble with this notation so I don't think you will know
what I'm saying above, but for anyone else, here is a summary:

If we have a TM "as in Linz" then this applies:

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

When asked what Ĥ does when given ⟨Ĥ⟩ PO says that it (eventually)
transitions to Ĥ.qn, so the above clause applies with M = Ĥ and wM =
⟨Ĥ⟩:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt

The first line says that Ĥ applied to ⟨Ĥ⟩ halts -- the final halting
state is right there (Ĥ.qn) -- but the second line says that this should
happen if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt. This is why
PO's Ĥ is not "as in Linz".

--
Ben.

On 7/31/21 1:39 PM, olcott wrote:
> On 7/31/2021 2:54 PM, Richard Damon wrote:
>> On 7/31/21 12:41 PM, olcott wrote:
>>> On 7/31/2021 2:14 PM, Richard Damon wrote:
>>>> On 7/31/21 11:52 AM, olcott wrote:
>>>>> On 7/31/2021 1:25 PM, Richard Damon wrote:
>>>>>> On 7/31/21 10:00 AM, olcott wrote:
>>>>>>> On 7/31/2021 10:41 AM, Richard Damon wrote:
>>>>>>>> On 7/31/21 8:20 AM, olcott wrote:
>>>>>>>>
>>>>>>>>> The halt decider does not freaking fail on its freaking inputs.
>>>>>>>>
>>>>>>>> Yes it does. Even YOU have provided the proof of this.
>>>>>>>>
>>>>>>>> P(P) Halts.
>>>>>>>> H(P,P) says that P(P) is non-halting.
>>>>>>>> Thus, it is WRONG.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> We know with 100% perfect complete logical certainty that the halt
>>>>>>>>> decider does correctly decide that its input never halts.
>>>>>>>>
>>>>>>>> You may THINK that, but you are mistaken.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> That the input cannot possibly ever reach its final state of 0xc3f
>>>>>>>>> whether or not H aborts the simulation of this input conclusively
>>>>>>>>> proves
>>>>>>>>> that this input never halts beyond all possible logically correct
>>>>>>>>> doubt.
>>>>>>>>
>>>>>>>> That H does not happen to be able to simulate H to its end does not
>>>>>>>> prove anything, because H does incorrectly abort its simulation.
>>>>>>>>
>>>>>>>
>>>>>>> The input to H(P,P) cannot possibly reach its final state 0xc3f
>>>>>>> under a
>>>>>>> verifiably perfectly correct pure simulation of this input.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Yes, if H is a pure simulator, then H^(H^) is non-Halting, but
>>>>>> H(H^,H^)
>>>>>> is still wrong as if H is a pure simulator it never returns an
>>>>>> answer.
>>>>>>
>>>>>> FAIL
>>>>>>
>>>>>
>>>>> You are only saying that a person cannot possibly make a left hand
>>>>> turn
>>>>> without making a left hand turn.
>>>>
>>>> No, I am saying that someone can not claim to only make left hand turns
>>>> if he does 50 left hand turns in a row and then makes a right hand
>>>> turn.
>>>>
>>>> A Pure Simulator is one that NEVER stops simulating.
>>>>
>>>> Something that at some point stops simulting was NEVER a pure
>>>> simulator.
>>>>
>>>>
>>>> IF you really believe what you claim, then tell us what the soup that
>>>> was 'pure' until you crapped in it tastes like. After all, if 'pure
>>>> until' is pure, then it still is a pure healthy meal.
>>>>
>>>>>
>>>>> Because the input to H(P,P) cannot possibly ever reach its final state
>>>>> 0xc3f either by a perfectly correct pure simulation or when this
>>>>> simulation is aborted we can know with 100% perfectly justified
>>>>> logical
>>>>> certainty that the input to H(P,P) never halts. From this we know with
>>>>> 100% perfectly justified logical certainty that H(P,P)==0 is correct.
>>>>
>>>> WRONG.
>>>>
>>>> You look at a wrong definition.
>>>>
>>>> Since H is NOT a PURE UNCONDITIONAL Simulator then the fact that H
>>>> doesn't reach the halting state doesn't prove ANYTHING other than H^
>>>> doesn't halt in less than the number of steps that it simulated.
>>>
>>> Anyone knowing the x86 language well enough (apparently not you) can see
>>> that the simulation of P cannot possibly ever reach its its final state
>>> of 0xc3f in an infinite number of steps.
>>
>> Obviously YOU don't understand x86 assembly, as it is very clear that if
>> H return a 0 value (which it does) then P will return.
>>
>
> P never ever returns any value to its input. This is the part that you
> very persistently ignore. I really do honestly believe that you probably
> do have attention deficit disorder.
>

What does the 'ret' function do? It returns. I never said a 'value' I
said it returns, which is your model equivalent to halting.

That is just a dishonest, and worthless dodge.

The Turing Machine P DOES Halt. Even you admit it. Thus H is WRONG to
say it doesn't.

>> You only get your conclusion if you insert the FALSE assumption that H
>> will never return.
>>
>>>
>>> _P()
>>> [00000c25](01)  55          push ebp
>>> [00000c26](02)  8bec        mov ebp,esp
>>> [00000c28](03)  8b4508      mov eax,[ebp+08]
>>> [00000c2b](01)  50          push eax       // 2nd Param
>>> [00000c2c](03)  8b4d08      mov ecx,[ebp+08]
>>> [00000c2f](01)  51          push ecx       // 1st Param
>>> [00000c30](05)  e820fdffff  call 00000955  // call H
>>> [00000c35](03)  83c408      add esp,+08
>>> [00000c38](02)  85c0        test eax,eax
>>> [00000c3a](02)  7402        jz 00000c3e
>>> [00000c3c](02)  ebfe        jmp 00000c3c
>>> [00000c3e](01)  5d          pop ebp
>>> [00000c3f](01)  c3          ret
>>> Size in bytes:(0027) [00000c3f]
>>>
>>> If any H ever aborts its simulation of P or no H ever aborts its
>>> simulation of P it never reaches its final state of 0xc3f.
>>
>> The fact that the H we use happens to abort its simulation of a copy of
>> P it is simulating has ZERO impact of the fact that THIS copy finished
>> to its halting state (if it was the top level machine).
>>
>> The fact that the top level machine does Halt PROVES that H was WRONG in
>> it determination that P was non-halting.
>>>
>>> Because P cannot possibly ever reach its final state we know for sure
>>> that P never halts.
>>>
>>
>> FALSE PREMISE. P DOES reach its final state BECAUSE H incorrectly
>> aborted a different simulation.
>>
>> FALSE PREMISE -> UNSOUND LOGIC.
>>
>> H, and YOU are WRONG.
>>
>
>

On 7/31/21 1:43 PM, olcott wrote:
> On 7/31/2021 3:02 PM, Richard Damon wrote:
>> On 7/31/21 12:52 PM, olcott wrote:
>>> On 7/31/2021 2:23 PM, Richard Damon wrote:
>>>> On 7/31/21 11:57 AM, olcott wrote:
>>>>> On 7/31/2021 1:31 PM, Richard Damon wrote:
>>>>>> On 7/31/21 9:35 AM, olcott wrote:
>>>>>>
>>>>>>>
>>>>>>> One would think that this is true, yet because H knows that it only
>>>>>>> acts
>>>>>>> as a pure simulator of its input until after its halt status
>>>>>>> decision
>>>>>>> has been made it knows that it has no behavior that can possibly
>>>>>>> effect
>>>>>>> the behavior of P. Because of this H knows that it can totally
>>>>>>> ignore
>>>>>>> all of its own behavior in any execution trace that it examines
>>>>>>> as the
>>>>>>> basis of its halt status decision.
>>>>>>
>>>>>> Something that acted like a 'pure simulator until ...' is NOT a pure
>>>>>> simulator.
>>>>>>
>>>>>
>>>>> You are dishonestly dodging the point by dishonestly changing the
>>>>> subject to a different subject.
>>>>
>>>> What different subject? We are talking about the soundness of your
>>>> argument. You claim that you can treat H as a Pure Simulator, when it
>>>> isn't since it is only a pure simulator until ... which is NOT a pure
>>>> simulator.
>>>>
>>>> By Your Logic, you must think Trump still has Presidental powers,
>>>> because he was President until he got voted out.
>>>>
>>>>>
>>>>> The point is that because H acts as a pure simulator until after its
>>>>> halt status decision has been made H can ignore its own behavior in
>>>>> any
>>>>> execution traces.
>>>>
>>>> FALSE. DISPROVEN. UNSOUND. DELUSIONAL even.
>>>>
>>>> Try to actually prove it.
>>>>
>>>
>>> You apparently are not bright enough to understand this.
>>
>> YOU seem to not be bright enough to see the Truth.
>>>
>>> People that are bright enough to understand this simply comprehend that
>>> a pure simulator or a simulating halt decider in pure simulation mode
>>> cannot possibly have any effect on the behavior of its input.
>>
>> But it DOES on the machine that uses it, so H needs to evalutate THAT
>> effect on the copies of H that it encounters.
>
> I don't know what your weasel words mean.

Maybe because you don't understand Turing Machines, or computers.

>
> Because P cannot possibly have any effect on the behavior of its inputs
> P can ignore its own behavior in every execution trace that it examines.
>

So P doesn't have anything to examine? I think you brain had a hiccup.

This sort of proves the absurdity of your claim that a decider doesn't
need to process copies of itself.

H (as a sub-machine) DOES have an effect on the P that incorporates that
H in it, and thus the algorithm of H need to include that when it
analyses the copy of itself in P.

FAIL.

>>>
>>> These same people understand that because it cannot possibly have any
>>> effect on the behavior of its input that logically entails that it
>>> cannot possibly have any effect on any halt status decision of the
>>> behavior of this input.
>>>
>>
>> THAT COPY can't affect the behavior of its input. The copies of it that
>> it finds can have inpact on the machines that use them.
>>
>> FAIL.
>>
>>> Finally these same people that understand that the behavior of the
>>> simulating halt decider while it is in pure simulation mode cannot not
>>> have any effect on its halt status decision will understand that this
>>> simulating halt decider can screen out its own address range and thus
>>> ignore its own behavior in any halt status decision as long as it only
>>> does this while it remains in pure simulation mode.
>>
>> WRONG.
>>
>> UNSOUND LOGIC.
>>
>> Beware being an intentional Liar, YOU have even quoted the penalty for
>> that.
>>
>
>

On 7/31/21 1:39 PM, olcott wrote:
> On 7/31/2021 2:54 PM, Richard Damon wrote:
>> On 7/31/21 12:41 PM, olcott wrote:
>>> On 7/31/2021 2:14 PM, Richard Damon wrote:
>>>> On 7/31/21 11:52 AM, olcott wrote:
>>>>> On 7/31/2021 1:25 PM, Richard Damon wrote:
>>>>>> On 7/31/21 10:00 AM, olcott wrote:
>>>>>>> On 7/31/2021 10:41 AM, Richard Damon wrote:
>>>>>>>> On 7/31/21 8:20 AM, olcott wrote:
>>>>>>>>
>>>>>>>>> The halt decider does not freaking fail on its freaking inputs.
>>>>>>>>
>>>>>>>> Yes it does. Even YOU have provided the proof of this.
>>>>>>>>
>>>>>>>> P(P) Halts.
>>>>>>>> H(P,P) says that P(P) is non-halting.
>>>>>>>> Thus, it is WRONG.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> We know with 100% perfect complete logical certainty that the halt
>>>>>>>>> decider does correctly decide that its input never halts.
>>>>>>>>
>>>>>>>> You may THINK that, but you are mistaken.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> That the input cannot possibly ever reach its final state of 0xc3f
>>>>>>>>> whether or not H aborts the simulation of this input conclusively
>>>>>>>>> proves
>>>>>>>>> that this input never halts beyond all possible logically correct
>>>>>>>>> doubt.
>>>>>>>>
>>>>>>>> That H does not happen to be able to simulate H to its end does not
>>>>>>>> prove anything, because H does incorrectly abort its simulation.
>>>>>>>>
>>>>>>>
>>>>>>> The input to H(P,P) cannot possibly reach its final state 0xc3f
>>>>>>> under a
>>>>>>> verifiably perfectly correct pure simulation of this input.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Yes, if H is a pure simulator, then H^(H^) is non-Halting, but
>>>>>> H(H^,H^)
>>>>>> is still wrong as if H is a pure simulator it never returns an
>>>>>> answer.
>>>>>>
>>>>>> FAIL
>>>>>>
>>>>>
>>>>> You are only saying that a person cannot possibly make a left hand
>>>>> turn
>>>>> without making a left hand turn.
>>>>
>>>> No, I am saying that someone can not claim to only make left hand turns
>>>> if he does 50 left hand turns in a row and then makes a right hand
>>>> turn.
>>>>
>>>> A Pure Simulator is one that NEVER stops simulating.
>>>>
>>>> Something that at some point stops simulting was NEVER a pure
>>>> simulator.
>>>>
>>>>
>>>> IF you really believe what you claim, then tell us what the soup that
>>>> was 'pure' until you crapped in it tastes like. After all, if 'pure
>>>> until' is pure, then it still is a pure healthy meal.
>>>>
>>>>>
>>>>> Because the input to H(P,P) cannot possibly ever reach its final state
>>>>> 0xc3f either by a perfectly correct pure simulation or when this
>>>>> simulation is aborted we can know with 100% perfectly justified
>>>>> logical
>>>>> certainty that the input to H(P,P) never halts. From this we know with
>>>>> 100% perfectly justified logical certainty that H(P,P)==0 is correct.
>>>>
>>>> WRONG.
>>>>
>>>> You look at a wrong definition.
>>>>
>>>> Since H is NOT a PURE UNCONDITIONAL Simulator then the fact that H
>>>> doesn't reach the halting state doesn't prove ANYTHING other than H^
>>>> doesn't halt in less than the number of steps that it simulated.
>>>
>>> Anyone knowing the x86 language well enough (apparently not you) can see
>>> that the simulation of P cannot possibly ever reach its its final state
>>> of 0xc3f in an infinite number of steps.
>>
>> Obviously YOU don't understand x86 assembly, as it is very clear that if
>> H return a 0 value (which it does) then P will return.
>>
>
> P never ever returns any value to its input. This is the part that you
> very persistently ignore. I really do honestly believe that you probably
> do have attention deficit disorder.

I didn't say to its input.

I said P returns, which of course would be to its caller. Maybe you
don't understand the fundamentals of Computer Architecture.

No Turing Machine returns a value to its input, that is a categorical
error to even think it.

H, returns a value to its caller, and when it does so, it affects that
actions of that Machine. This is why H can't ignore the behavior of a
copy of itself in the machine it is simulating.

Yes, H doesn't need to worry about the effect that THIS instance has on
the machine it is simulating, because, if you did your simulator right,
it has no effect on that, but the copies of itself that it simulates DO
have an affect on the machine they are part of.

>
>> You only get your conclusion if you insert the FALSE assumption that H
>> will never return.
>>
>>>
>>> _P()
>>> [00000c25](01)  55          push ebp
>>> [00000c26](02)  8bec        mov ebp,esp
>>> [00000c28](03)  8b4508      mov eax,[ebp+08]
>>> [00000c2b](01)  50          push eax       // 2nd Param
>>> [00000c2c](03)  8b4d08      mov ecx,[ebp+08]
>>> [00000c2f](01)  51          push ecx       // 1st Param
>>> [00000c30](05)  e820fdffff  call 00000955  // call H
>>> [00000c35](03)  83c408      add esp,+08
>>> [00000c38](02)  85c0        test eax,eax
>>> [00000c3a](02)  7402        jz 00000c3e
>>> [00000c3c](02)  ebfe        jmp 00000c3c
>>> [00000c3e](01)  5d          pop ebp
>>> [00000c3f](01)  c3          ret
>>> Size in bytes:(0027) [00000c3f]
>>>
>>> If any H ever aborts its simulation of P or no H ever aborts its
>>> simulation of P it never reaches its final state of 0xc3f.
>>
>> The fact that the H we use happens to abort its simulation of a copy of
>> P it is simulating has ZERO impact of the fact that THIS copy finished
>> to its halting state (if it was the top level machine).
>>
>> The fact that the top level machine does Halt PROVES that H was WRONG in
>> it determination that P was non-halting.
>>>
>>> Because P cannot possibly ever reach its final state we know for sure
>>> that P never halts.
>>>
>>
>> FALSE PREMISE. P DOES reach its final state BECAUSE H incorrectly
>> aborted a different simulation.
>>
>> FALSE PREMISE -> UNSOUND LOGIC.
>>
>> H, and YOU are WRONG.
>>
>
>

On 7/30/21 6:16 PM, olcott wrote:
> On 7/30/2021 2:58 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/30/2021 7:39 AM, Ben Bacarisse wrote:
>>
>>>> Any chance you will now say if
>>>>
>>>>>    Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
>>>>
>>>> transitions to Ĥ.qn or Ĥ.qy?  If you find this question difficult,
>>>> please ask for some help in understanding it.
>>>
>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn
>>
>> An answer.  Thank you.
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>    For Ĥ to be "exactly and precisely as in Linz" this, then, is the
>> clause
>> that applies to your H and Ĥ:
>>
>
> There is no H in the relevant last paragraph of the Linz proof that
> forms the basis for the Linz conclusion.
>
>>>>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>>>>>>> if M applied to wM does not halt
>>
>> so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me
>> that it does.  That is what this full (but abbreviated) state transition
>> sequence means:
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Which is it?
>>
>
> Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the
> ⟨Ĥ2⟩ copy then
> Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the
> ⟨Ĥ3⟩ copy then
> Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the
> ⟨Ĥ4⟩ copy then ...

As Ben says, this is incorrect.

H^0.q0 copies its input (H^1) to (H^2) the goes to H^0.qx which starts a
simulaiton of H^1 of H^2, this simulation then simulates the running of
H1^ which starts at the simulated state H^1.q0 and simulates its copying
of H^2 to H^3, and then simulates it going to H^1.qx and then it
simulates the simulation of H^2.

The Simulation of the Simulation of state H^2.q0 then simulates the
simulation of the copying of H^3 to H^4 ...

>
> The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't
> possibly ever reach its final state. Then it transitions to Ĥ0.qn
> causing the outermost Ĥ0 to halt.

The actual simulation that started at H^0.qx then INcorrect decides that
its input H^1,H^2 can't possible reach its final state, tansitioning to
H^0.qn where the machine Halts, show that H^(H^) is a Halting
Computation and thus that the copy of H at H^0.qx was wrong in deciding
that H^1(H^2) would never halt.

>
> Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt and
> it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly ever
> reach its final state there is no contradiction or paradox and it
> decided correctly.
>

Since H^0 is the same computaiton as H^1 as H^2 etc, ALL these machines
WILL behave the same, so H^0 deciding that H^1(H^2) is exactly the same
as the 'generic' statement that H(H^,H^) decided none halting when
H^(H^) is shown to be halting.

If H^1 behaves differently then H^0, you built your system incorrectly.

On 7/31/21 2:57 PM, olcott wrote:
> On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> It matters not what I had.
>>
>> Because you can't justify it the honest debate you claim to want.
>>
>>> It only matters what I have.
>>
>> I.e. nothing of any interest.  You make it plain in a previous reply
>> that you've had nothing of interest going right back to the original
>> deceptive claim.
>>
>>> If you are sincere about an honest dialogue then we must quit focusing
>>> on details of obsolete technology.
>>
>> And yet you skipped the big picture part:
>>
>>>> (5) You said you had "an H that decides (Ĥ, Ĥ)".  What decision did
>>>> your
>>>>      Dec 2018 code come to about "(Ĥ, Ĥ)"?
>>>
>>> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
>>> H(P,P)==0 now except that the never halting criteria is much more
>>> elaborate. The initial criteria was very crude.
>>
>> Ah, so you never had H and H_Hat that do anything that anyone would say
>> is impossible.  Had you said, back in Dec 2018, "I have C code such that
>> H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
>> interested.
>>
>
> If you are sincere about an honest dialogue then we must quit focusing
> on details of obsolete technology.
>
> If you are sincere about an honest dialogue then we must quit focusing
> on details of obsolete technology.
>
> If you are sincere about an honest dialogue then we must quit focusing
> on details of obsolete technology.
>

What is obsolete?

You have changed the NAME that you are calling H^, but it is still
exactly the same machine,

>> I think you owe everyone an apology.  Even if there was no indent to
>> deceive, your words back then did everything possible to suggest some
>> impossible Turing machine.  And you wouldn't say, until recently, even
>> when explicitly asked, what decision H came to.  It was fishy from the
>> start.
>
>
>

On 31/07/2021 01:42, olcott wrote:
> [...] At the end of 2018 I had only heard of TM complete and I knew
> that this required unlimited memory.

Which every computer with the capability of reading from and
writing to a suitable external medium [eg USB stick, CD, floppy, mag
tape, paper tape or punched cards] and obeying a relatively small
program has. That's pretty-much everything that we would normally
have called a computer from the 1950s onwards.

[...]
> C is equivalent to a TM for the subset of computations where it has
> all the memory that it needs. I don't think that anyone else beside
> me says this.

If you mean merely that C programs can be used to emulate a
finite-state machine, then that has "always" been known, and I guess
that few research papers have thought it worth saying; OTOH, it
would have been a normal thing to say for the past 40+ years when
explaining to students what a FSM is and giving examples. It would
also have been normal for the past 50+ years to explain that then-
current HLLs were overkill; you can build a UTM out of anything
that can do a few simple operations on [cf the above] an unbounded
storage medium. Everything else is an efficiency hack.

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

On 7/31/2021 5:08 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/30/2021 2:58 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/30/2021 7:39 AM, Ben Bacarisse wrote:
>>>
>>>>> Any chance you will now say if
>>>>>
>>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
>>>>>
>>>>> transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult,
>>>>> please ask for some help in understanding it.
>>>>
>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn
>>>
>>> An answer. Thank you.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause
>>> that applies to your H and Ĥ:
>>
>> There is no H in the relevant last paragraph of the Linz proof that
>> forms the basis for the Linz conclusion.
>
> Distraction. Everything you ignore below is about the proof and refers
> only to Ĥ.
>
>>>>>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>>>>>>>> if M applied to wM does not halt
>>>
>>> so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me
>>> that it does. That is what this full (but abbreviated) state transition
>>> sequence means:
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> Which is it?
>>
>> Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the
>> ⟨Ĥ2⟩ copy then
>> Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the
>> ⟨Ĥ3⟩ copy then
>> Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the
>> ⟨Ĥ4⟩ copy then ...
>
> This is an abuse of the notation (but I know what you mean). There is
> no Ĥ1 or Ĥ2. If you think it helps to show which copy of ⟨Ĥ⟩ your
> simulating "decider" is either running and/or currently looking at, you
> need to come up with a notation that does that.

A better notation is what I have in my PDF actual subscripts but people
here tel me that their newsreader makes sure to totally ignore posts
with HTML so that do even see the post at all.

> At least I know what
> this "math poem" means, because you've been saying this "it's a
> simulator until" stuff for years.
>
>> The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩)
>> can't possibly ever reach its final state. Then it transitions to
>> Ĥ0.qn causing the outermost Ĥ0 to halt.
>
> Apart from the bad notation, yes. All those copies and tests and
> eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
>> Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt
>> and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly
>> ever reach its final state there is no contradiction or paradox and it
>> decided correctly.
>
> You are free to define "decide correctly" in any way you like provided
> you are honest about it. But you hooked people in by saying that your Ĥ
> is "exactly and precisely as in Linz", and you quoted, even now, what
> Linz has to say about such TMs:
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt
>
> This is your quote. You brought it up. You claimed your Ĥ was as Linz
> states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not
> halt. Linz makes no exceptions based on why the transitions from Ĥ.q0
> wM to Ĥ.qn occur. Linz does not say
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt or if M applied wM only halts
> because...
>
> Are you now saying that your TM was not "as in Linz"? (You should,
> because you've admitted that elsewhere.)
>

Ĥ[0] is to be interpreted to mean Ĥ₀
[0] Means the actual Turing machine and not a TM description.
[1] Means the first TM description parameter
[2] Means a copy of the the first TM description parameter

Now I am saying that when the actual unmodified Linz Ĥ is understood to
have a UTM/Halt-Decider at Ĥ[0].qx that this Ĥ[0].qx does correctly
decide that its input: (⟨Ĥ[1]⟩, ⟨Ĥ[2]⟩) can't possibly ever reach its
final state of Ĥ[1].qn or Ĥ[2].qn, therefore we know that its input
never halts therefore we know that a state transition from Ĥ[0].qx to
Ĥ0.qn is necessarily correct.

This is not a case of the halt decider deciding that Ĥ never halts and
then Ĥ halts. There are three different instances of Ĥ involved. It is
only their differing placement in the execution trace that makes the
result vary.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> --------
> You have real trouble with this notation so I don't think you will know
> what I'm saying above, but for anyone else, here is a summary:
>
> If we have a TM "as in Linz" then this applies:
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt
>
> When asked what Ĥ does when given ⟨Ĥ⟩ PO says that it (eventually)
> transitions to Ĥ.qn, so the above clause applies with M = Ĥ and wM =
> ⟨Ĥ⟩:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> if Ĥ applied to ⟨Ĥ⟩ does not halt
>
> The first line says that Ĥ applied to ⟨Ĥ⟩ halts -- the final halting
> state is right there (Ĥ.qn) -- but the second line says that this should
> happen if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt. This is why
> PO's Ĥ is not "as in Linz".
>

--
Copyright 2021 Pete Olcott

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

On 7/31/2021 5:53 PM, Andy Walker wrote:
> On 31/07/2021 01:42, olcott wrote:
>> [...] At the end of 2018 I had only heard of TM complete and I knew
>> that this required unlimited memory.
>
>     Which every computer with the capability of reading from and
> writing to a suitable external medium [eg USB stick, CD, floppy, mag
> tape, paper tape or punched cards] and obeying a relatively small
> program has.  That's pretty-much everything that we would normally
> have called a computer from the 1950s onwards.
>
> [...]
>> C is equivalent to a TM for the subset of computations where it has
>> all the memory that it needs. I don't think that anyone else beside
>> me says this.
>
>     If you mean merely that C programs can be used to emulate a
> finite-state machine, then that has "always" been known, and I guess
> that few research papers have thought it worth saying;

Through RASP machines we know that all computations (having enough
memory) performed in C are equivalent to TM computations.
https://en.wikipedia.org/wiki/Random-access_stored-program_machine

Thus a C program that correctly decides the TM counter-examples that
"prove" that halting is undecidable directly maps to a TM that can do
the same thing, thus refuting the original theorem.

> OTOH, it
> would have been a normal thing to say for the past 40+ years when
> explaining to students what a FSM is and giving examples.  It would
> also have been normal for the past 50+ years to explain that then-
> current HLLs were overkill;  you can build a UTM out of anything
> that can do a few simple operations on [cf the above] an unbounded
> storage medium.  Everything else is an efficiency hack.
>

More generally my x86utm operating system implements x86 virtual
machines based on C functions that are computationally equivalent to
UTMs. This allows studying theory of computation problems using the high
level language of C.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On 7/31/21 7:47 PM, olcott wrote:
> On 7/31/2021 5:53 PM, Andy Walker wrote:
>> On 31/07/2021 01:42, olcott wrote:
>>> [...] At the end of 2018 I had only heard of TM complete and I knew
>>> that this required unlimited memory.
>>
>>      Which every computer with the capability of reading from and
>> writing to a suitable external medium [eg USB stick, CD, floppy, mag
>> tape, paper tape or punched cards] and obeying a relatively small
>> program has.  That's pretty-much everything that we would normally
>> have called a computer from the 1950s onwards.
>>
>> [...]
>>> C is equivalent to a TM for the subset of computations where it has
>>> all the memory that it needs. I don't think that anyone else beside
>>> me says this.
>>
>>      If you mean merely that C programs can be used to emulate a
>> finite-state machine, then that has "always" been known, and I guess
>> that few research papers have thought it worth saying;
>
> Through RASP machines we know that all computations (having enough
> memory) performed in C are equivalent to TM computations.
> https://en.wikipedia.org/wiki/Random-access_stored-program_machine

RASP machines have nothing to do with C. While it is probably possible
to write a C compiler that generates RASP code, I know of no such
implementation. Such a compiler might not be actually conformant to the
standard if it tries to expose the full capability of the machine, as
you can't define some required pre-defined symbols like CHAR_BIT and the
various _MAX and _MIN symbols.

Note, x86 is NOT RASP Machine

>
> Thus a C program that correctly decides the TM counter-examples that
> "prove" that halting is undecidable directly maps to a TM that can do
> the same thing, thus refuting the original theorem.
>

Except that your C program DOESN'T correctly decide as it says that
H^(H^) is non-Halting when it is Halting.

FAIL.

>>  OTOH, it
>> would have been a normal thing to say for the past 40+ years when
>> explaining to students what a FSM is and giving examples.  It would
>> also have been normal for the past 50+ years to explain that then-
>> current HLLs were overkill;  you can build a UTM out of anything
>> that can do a few simple operations on [cf the above] an unbounded
>> storage medium.  Everything else is an efficiency hack.
>>
>
> More generally my x86utm operating system implements x86 virtual
> machines based on C functions that are computationally equivalent to
> UTMs. This allows studying theory of computation problems using the high
> level language of C.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>

olcott <NoOne@NoWhere.com> writes:

> On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> It matters not what I had.
>> Because you can't justify it the honest debate you claim to want.
>>
>>> It only matters what I have.
>> I.e. nothing of any interest. You make it plain in a previous reply
>> that you've had nothing of interest going right back to the original
>> deceptive claim.
>>
>>> If you are sincere about an honest dialogue then we must quit focusing
>>> on details of obsolete technology.
>> And yet you skipped the big picture part:
>>
>>>> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
>>>> Dec 2018 code come to about "(Ĥ, Ĥ)"?
>>>
>>> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
>>> H(P,P)==0 now except that the never halting criteria is much more
>>> elaborate. The initial criteria was very crude.
>>
>> Ah, so you never had H and H_Hat that do anything that anyone would say
>> is impossible. Had you said, back in Dec 2018, "I have C code such that
>> H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
>> interested.
>
> If you are sincere about an honest dialogue then we must quit focusing
> on details of obsolete technology.

Ah, an honest dialogue requires me to ignore your past deception? Well,
I can accommodate that: you /currently/ don't have anything that anyone
would consider to be impossible or even interesting. An H/H_Hat pair
such that H(H_Hat, H_Hat) == 0 and H_Hat(H_Hat) halts is of no interest
to anyone. Is that better?

>> I think you owe everyone an apology. Even if there was no indent to
>> deceive, your words back then did everything possible to suggest some
>> impossible Turing machine. And you wouldn't say, until recently, even
>> when explicitly asked, what decision H came to. It was fishy from the
>> start.

You still owe everyone an apology. Neither Turing machines nor C code
are obsolete technology. If you really had what you falsely claimed to
have had, posting it at any time in the last 30 months would have
settled the matter. It still would, but you either never had anything
at all or you are too embarrassed to post what it was.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 7/31/2021 5:08 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/30/2021 2:58 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/30/2021 7:39 AM, Ben Bacarisse wrote:
>>>>
>>>>>> Any chance you will now say if
>>>>>>
>>>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
>>>>>>
>>>>>> transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult,
>>>>>> please ask for some help in understanding it.
>>>>>
>>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn
>>>>
>>>> An answer. Thank you.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> For Ĥ to be "exactly and precisely as in Linz" this, then, is the clause
>>>> that applies to your H and Ĥ:
>>>
>>> There is no H in the relevant last paragraph of the Linz proof that
>>> forms the basis for the Linz conclusion.
>> Distraction. Everything you ignore below is about the proof and refers
>> only to Ĥ.
>>
>>>>>>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>>>>>>>>> if M applied to wM does not halt
>>>>
>>>> so Ĥ (M) applied to ⟨Ĥ⟩ (wM) does not halt, but you have just told me
>>>> that it does. That is what this full (but abbreviated) state transition
>>>> sequence means:
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> Which is it?
>>>
>>> Ĥ0.q0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then Ĥ0.qx simulates Ĥ1 with the
>>> ⟨Ĥ2⟩ copy then
>>> Ĥ1.q0 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then Ĥ1.qx simulates Ĥ2 with the
>>> ⟨Ĥ3⟩ copy then
>>> Ĥ2.q0 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then Ĥ2.qx simulates Ĥ3 with the
>>> ⟨Ĥ4⟩ copy then ...
>> This is an abuse of the notation (but I know what you mean). There is
>> no Ĥ1 or Ĥ2. If you think it helps to show which copy of ⟨Ĥ⟩ your
>> simulating "decider" is either running and/or currently looking at, you
>> need to come up with a notation that does that.
>
> A better notation is what I have in my PDF actual subscripts but
> people here tel me that their newsreader makes sure to totally ignore
> posts with HTML so that do even see the post at all.

I am happy you have a notation you like. Are you prepared to address
that fact that your H^ is not "as in Linz"?

>> At least I know what
>> this "math poem" means, because you've been saying this "it's a
>> simulator until" stuff for years.
>>
>>> The outermost Ĥ0.qx correctly decides that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩)
>>> can't possibly ever reach its final state. Then it transitions to
>>> Ĥ0.qn causing the outermost Ĥ0 to halt.
>> Apart from the bad notation, yes. All those copies and tests and
>> eventual deciding are neatly summed up in the last ⊢* Ĥ.qn of
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>>> Because the outermost Ĥ0.qx did not decide that Ĥ0 would never halt
>>> and it is self evident that its input: (⟨Ĥ1⟩, ⟨Ĥ2⟩) can't possibly
>>> ever reach its final state there is no contradiction or paradox and it
>>> decided correctly.
>> You are free to define "decide correctly" in any way you like provided
>> you are honest about it. But you hooked people in by saying that your Ĥ
>> is "exactly and precisely as in Linz", and you quoted, even now, what
>> Linz has to say about such TMs:
>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>> if M applied to wM does not halt
>> This is your quote. You brought it up. You claimed your Ĥ was as Linz
>> states -- that Ĥ.q0 wM ⊢* Ĥ.qn if and only if M applied to wM does not
>> halt. Linz makes no exceptions based on why the transitions from Ĥ.q0
>> wM to Ĥ.qn occur. Linz does not say
>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>> if M applied to wM does not halt or if M applied wM only halts
>> because...
>> Are you now saying that your TM was not "as in Linz"? (You should,
>> because you've admitted that elsewhere.)
>
> Ĥ[0] is to be interpreted to mean Ĥ₀
> [0] Means the actual Turing machine and not a TM description.
> [1] Means the first TM description parameter
> [2] Means a copy of the the first TM description parameter
>
> Now I am saying that when the actual unmodified Linz Ĥ is understood
> to have a UTM/Halt-Decider at Ĥ[0].qx that this Ĥ[0].qx does correctly
> decide that its input: (⟨Ĥ[1]⟩, ⟨Ĥ[2]⟩) can't possibly ever reach its
> final state of Ĥ[1].qn or Ĥ[2].qn, therefore we know that its input
> never halts therefore we know that a state transition from Ĥ[0].qx to
> Ĥ0.qn is necessarily correct.

We all know you are declaring that to be correct. Here's why your Ĥ is
not "as in Linz". Linz requires that

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
if, and only if, the encoded M applied to wM does not halt. But you've
given us a case where your Ĥ is not like this:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
behaviour "correct". You can call it anything you like. But it's not
"as in Linz". It does not say anything about Linz's proof. It does not
do anything people would call impossible or even interesting.

Presumably, you will simply explain, yet again, why you choose to call
it correct. You might even, yet again, quote the symbols from Linz that
don't apply to your Ĥ in order to make you posts seem relevant.

--
Ben.

On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:
>
> Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
> behaviour "correct". You can call it anything you like. But it's not
> "as in Linz". It does not say anything about Linz's proof. It does not
> do anything people would call impossible or even interesting.
>
It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
theorems are refuted. Which you would expect. If results were consistent
it would have to be some cheap trick.

However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
nothing to do with the invert step of Linz' proof. This is maybe interesting,
but in a small way, it's not a revolutionary result which will turn computer
science upside down. But it's maybe worth mentioning.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:
>>
>> Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
>> behaviour "correct". You can call it anything you like. But it's not
>> "as in Linz". It does not say anything about Linz's proof. It does not
>> do anything people would call impossible or even interesting.
>>
> It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
> whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
> theorems are refuted. Which you would expect. If results were consistent
> it would have to be some cheap trick.

I case there is some confusion, I mean that PO's Ĥ is not an Ĥ as
specified in Linz. Yes, everything is in accordance with the truth as
laid out in Linz and, indeed, in any textbook.

I point this out to PO because he brings it up. He keeps posting the
specification of what an Ĥ, as Linz specifies it, would do:

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if (and only if) M applied to wM does not halt.

He claims (or used to claim) that his Ĥ meets this specification for at
least the one case where wM == ⟨Ĥ⟩:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.

To remain relevant, he /must/ keep insisting that his Ĥ meets the
requirements laid out in Linz, if only for this one key input.

> However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
> nothing to do with the invert step of Linz' proof. This is maybe interesting,
> but in a small way, it's not a revolutionary result which will turn computer
> science upside down. But it's maybe worth mentioning.

I don't follow. H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 making
that result the wrong one. If H(H_Hat, H_Hat) returned non-zero,
H_Hat(H_Hat) would not halt, making that the wrong result. Whilst I
don't like this sort of language, H fails on H_Hat(H_Hat) precisely
because of how H_Hat is constructed from H.

--
Ben.

On Sunday, 1 August 2021 at 13:41:25 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
> > nothing to do with the invert step of Linz' proof. This is maybe interesting,
> > but in a small way, it's not a revolutionary result which will turn computer
> > science upside down. But it's maybe worth mentioning.
> I don't follow. H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 making
> that result the wrong one. If H(H_Hat, H_Hat) returned non-zero,
> H_Hat(H_Hat) would not halt, making that the wrong result. Whilst I
> don't like this sort of language, H fails on H_Hat(H_Hat) precisely
> because of how H_Hat is constructed from H.
>
Consider this. H_Cap (similar to H_Hat but missing the invert step);

H_Cap(I)
{ return H(I, I):
}

Now if H is a "simulating halt decider" it must get this wrong. H is (skeleton
code)

H(I, I)
{ while(true)
{
Step(I, I);
if (tightloopdetected())
return Non_Halting;
else if (haltsofitsownaccord)
return Halting;
}
}

The question is how we write the function tightloopdetected(). If it returns
true then H(H_Cap, H_Cap) the H(H_Cap, H_Cap) will terminate. If
it returns false, it wlll not. So H can never make the right decision for H_Cap(H_Cap).

We've elimiated the "invert the result" step from Linz's proof. We have to
insist that H is a "simulating halt decider" to achieve this. But that seems
to be a reasonable condition. We know there are many properties of Turing
machines that cannot be determined other than by stepping them.

On 8/1/2021 7:12 AM, Malcolm McLean wrote:
> On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:
>>
>> Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
>> behaviour "correct". You can call it anything you like. But it's not
>> "as in Linz". It does not say anything about Linz's proof. It does not
>> do anything people would call impossible or even interesting.
>>
> It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
> whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
> theorems are refuted. Which you would expect. If results were consistent
> it would have to be some cheap trick.

Since both answers are correct:

(a) The input to H(P,P) really is a non-halting computation:
It can't possibly ever reach its final state whether or not H aborts its
simulation.

(b) The P of int main(){ P(); } does reach its final state.

Therefore (b) does not prove that H(P,P)==0 is incorrect.

These are two different instances of P at two different points in the
execution trace and the first P would never halt unless the second P was
aborted thus proving that int main(){ P(); } does specify the first
element of an infinite chain of function calls. P was only allowed to
halt only because it was not an input to the halt decider. This is like
a guy that gets away with a crime only because no one is watching.

// H and H2 are partial halt deciders
u32 PSR_Decider(u32 P, u32 I)
{ u32 Input_Halts1 = H((u32)P, (u32)I);
u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
Output("Input_Halts1 = ", Input_Halts1);
Output("Input_Halts2 = ", Input_Halts2);
if (Input_Halts1 != Input_Halts2)
return 1;
return 0;
}

Since u32 PSR_Decider(u32 P, u32 I) recognizes all and only these cases
Rice is refuted.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
> nothing to do with the invert step of Linz' proof. This is maybe interesting,
> but in a small way, it's not a revolutionary result which will turn computer
> science upside down. But it's maybe worth mentioning.
>

--
Copyright 2021 Pete Olcott

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

On 8/1/2021 7:41 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:
>>>
>>> Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
>>> behaviour "correct". You can call it anything you like. But it's not
>>> "as in Linz". It does not say anything about Linz's proof. It does not
>>> do anything people would call impossible or even interesting.
>>>
>> It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
>> whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
>> theorems are refuted. Which you would expect. If results were consistent
>> it would have to be some cheap trick.
>
> I case there is some confusion, I mean that PO's Ĥ is not an Ĥ as
> specified in Linz. Yes, everything is in accordance with the truth as
> laid out in Linz and, indeed, in any textbook.
>
> I point this out to PO because he brings it up. He keeps posting the
> specification of what an Ĥ, as Linz specifies it, would do:
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if (and only if) M applied to wM does not halt.
>
> He claims (or used to claim) that his Ĥ meets this specification for at
> least the one case where wM == ⟨Ĥ⟩:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>
> To remain relevant, he /must/ keep insisting that his Ĥ meets the
> requirements laid out in Linz, if only for this one key input.
>

Ĥ[0].q0 is taken to mean Ĥ₀.q0 which is the Turing machine.

Ĥ[1].q0 is taken to mean Ĥ₁.q0 which is the Turing machine
description input to Ĥ[0].q0

Ĥ[2].q0 is taken to mean Ĥ₂.q0 which is first copy of the
Turing machine description input to Ĥ[0].q0

Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn

It is neither a contradiction nor a paradox because there are three
different instances of Ĥ.

Because the only reason that the first instance halts is that Ĥ[0].qx
correctly determines that its input cannot possibly ever reach its final
state of Ĥ[1].qn or Ĥ[1].qy whether or not the simulating halt decider
aborts its simulation of this input, we know with 100% perfectly
justified logical certainty that the input to Ĥ[0].qx never halts.

>> However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
>> nothing to do with the invert step of Linz' proof. This is maybe interesting,
>> but in a small way, it's not a revolutionary result which will turn computer
>> science upside down. But it's maybe worth mentioning.
>
> I don't follow. H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 making
> that result the wrong one. If H(H_Hat, H_Hat) returned non-zero,
> H_Hat(H_Hat) would not halt, making that the wrong result. Whilst I
> don't like this sort of language, H fails on H_Hat(H_Hat) precisely
> because of how H_Hat is constructed from H.
>

Garbage in derives garbage out that this garbage collector** recognizes
and rejects:

** Pathological self-reference(Olcott 2004) decider

// H and H2 are partial halt deciders
u32 PSR_Decider(u32 P, u32 I)
{ u32 Input_Halts1 = H((u32)P, (u32)I);
u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
Output("Input_Halts1 = ", Input_Halts1);
Output("Input_Halts2 = ", Input_Halts2);
if (Input_Halts1 != Input_Halts2)
return 1;
return 0;
}

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On 8/1/21 8:02 AM, olcott wrote:
> On 8/1/2021 7:41 AM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:
>>>>
>>>> Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
>>>> behaviour "correct". You can call it anything you like. But it's not
>>>> "as in Linz". It does not say anything about Linz's proof. It does not
>>>> do anything people would call impossible or even interesting.
>>>>
>>> It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
>>> whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
>>> theorems are refuted. Which you would expect. If results were consistent
>>> it would have to be some cheap trick.
>>
>> I case there is some confusion, I mean that PO's Ĥ is not an Ĥ as
>> specified in Linz.  Yes, everything is in accordance with the truth as
>> laid out in Linz and, indeed, in any textbook.
>>
>> I point this out to PO because he brings it up.  He keeps posting the
>> specification of what an Ĥ, as Linz specifies it, would do:
>>
>>    Ĥ.q0 wM ⊢* Ĥ.qx wM wM  ⊢* Ĥ.qn
>>    if (and only if) M applied to wM does not halt.
>>
>> He claims (or used to claim) that his Ĥ meets this specification for at
>> least the one case where wM == ⟨Ĥ⟩:
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩  ⊢* Ĥ.qn
>>    if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>
>> To remain relevant, he /must/ keep insisting that his Ĥ meets the
>> requirements laid out in Linz, if only for this one key input.
>>
>
> Ĥ[0].q0 is taken to mean Ĥ₀.q0 which is the Turing machine.
>
> Ĥ[1].q0 is taken to mean Ĥ₁.q0 which is the Turing machine
> description input to Ĥ[0].q0
>
> Ĥ[2].q0 is taken to mean Ĥ₂.q0 which is first copy of the
> Turing machine description input to Ĥ[0].q0
>
> Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩  ⊢* Ĥ[0].qn
>
> It is neither a contradiction nor a paradox because there are three
> different instances of Ĥ.

Except that it is, as Turing macines are Computations, and All instance
of a given Computaton (Algorith/Turing Machine + Input) must give the
same results.

You don't seem to understand this Fundamental property.

What would you think of a program that every time you ran it told you a
different answer? (Like how much taxes you owed for a given year).

>
> Because the only reason that the first instance halts is that Ĥ[0].qx
> correctly determines that its input cannot possibly ever reach its final
> state of Ĥ[1].qn or Ĥ[1].qy whether or not the simulating halt decider
> aborts its simulation of this input, we know with 100% perfectly
> justified logical certainty that the input to Ĥ[0].qx never halts.
>
>>> However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
>>> nothing to do with the invert step of Linz' proof. This is maybe
>>> interesting,
>>> but in a small way, it's not a revolutionary result which will turn
>>> computer
>>> science upside down. But it's maybe worth mentioning.
>>
>> I don't follow.  H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 making
>> that result the wrong one.  If H(H_Hat, H_Hat) returned non-zero,
>> H_Hat(H_Hat) would not halt, making that the wrong result.  Whilst I
>> don't like this sort of language, H fails on H_Hat(H_Hat) precisely
>> because of how H_Hat is constructed from H.
>>
>
> Garbage in derives garbage out that this garbage collector** recognizes
> and rejects:

But H^ is NOT garbage.

Maybe the garbage is in H.

>
> ** Pathological self-reference(Olcott 2004) decider
>
> // H and H2 are partial halt deciders
> u32 PSR_Decider(u32 P, u32 I)
> {
>   u32 Input_Halts1 = H((u32)P, (u32)I);
>   u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
>   Output("Input_Halts1 = ", Input_Halts1);
>   Output("Input_Halts2 = ", Input_Halts2);
>   if (Input_Halts1 != Input_Halts2)
>     return 1;
>   return 0;
> }
>
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>

On 8/1/21 7:45 AM, olcott wrote:
> On 8/1/2021 7:12 AM, Malcolm McLean wrote:
>> On Sunday, 1 August 2021 at 11:54:57 UTC+1, Ben Bacarisse wrote:
>>>
>>> Here we can see that Ĥ applied to ⟨Ĥ⟩ halts. You can call your Ĥ's
>>> behaviour "correct". You can call it anything you like. But it's not
>>> "as in Linz". It does not say anything about Linz's proof. It does not
>>> do anything people would call impossible or even interesting.
>>>
>> It seems to be established that H(H_Hat, H_Hat) returns "non-halting"
>> whilst H_Hat(H_Hat) halts. So all is as Linz says it must be and no
>> theorems are refuted. Which you would expect. If results were consistent
>> it would have to be some cheap trick.
>
> Since both answers are correct:
>
> (a) The input to H(P,P) really is a non-halting computation:
> It can't possibly ever reach its final state whether or not H aborts its
> simulation.
>

Wrong, as previously shown.

> (b) The P of int main(){ P(); } does reach its final state.

Right, which is WHY (a) is wrong.

>
> Therefore (b) does not prove that H(P,P)==0 is incorrect.

WHY?

The DEFINITION of a Halting Decider is a machine that tells you what the
machine its input represents would do with the given input.

The MEANING of H(P,I) is asking what will P(I) do?

>
> These are two different instances of P at two different points in the
> execution trace and the first P would never halt unless the second P was
> aborted thus proving that int main(){ P(); } does specify the first
> element of an infinite chain of function calls. P was only allowed to
> halt only because it was not an input to the halt decider. This is like
> a guy that gets away with a crime only because no one is watching.

Doesn't matter that a second P was aborted. The Actual Machine P(P) does
Halt, so anything that aborts a simulation of P(P) and says it is
non-halting is incorrect.

>
> // H and H2 are partial halt deciders
> u32 PSR_Decider(u32 P, u32 I)
> {
>   u32 Input_Halts1 = H((u32)P, (u32)I);
>   u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
>   Output("Input_Halts1 = ", Input_Halts1);
>   Output("Input_Halts2 = ", Input_Halts2);
>   if (Input_Halts1 != Input_Halts2)
>     return 1;
>   return 0;
> }
>
> Since u32 PSR_Decider(u32 P, u32 I) recognizes all and only these cases
> Rice is refuted.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>> However the reasons PO's halt decider fails on H_Hat(H_Hat) have got
>> nothing to do with the invert step of Linz' proof. This is maybe
>> interesting,
>> but in a small way, it's not a revolutionary result which will turn
>> computer
>> science upside down. But it's maybe worth mentioning.
>>
>
>