olcott <NoOne@NoWhere.com> writes:

> On 7/30/2021 6:39 AM, Ben Bacarisse wrote:

>> The fact that, despite explicitly claiming that you have "an H that
>> decides (Ĥ, Ĥ)", you have steadfastly avoided saying what that decision
>> is for more than two and half years, strongly suggests that you don't
>> like the answer you might have to give.
>>
>> But even if you mistakenly think it's a side issue, someone engaging in
>> honest debate and searching for mutual understanding would answer it
>> anyway. It's one word. One word that you claimed to have known for
>
> There are too many rat holes of miscommunication that are bound up in
> the case where one halt decider examines what another different halts
> decider does. I want to reach complete closure before my cancer kills
> me so I don't have time to waste on dead-ends.

You've answered it in another sub-thread. Up-thread I asked

|| Which was the case back then:
|| (1) H rejects (H^, H^) and H^ does not halt in input H^, or
|| (2) H accepts (H^, H^) and H^ halts on input H^, or
|| (3) H rejects (H^, H^) and H^ halts on input H^.

and it turns out that it's (3). Of course, you did not have a TM back
then, so for your C code H(H^, H^) == 0 has to stand in for "H rejects
(H^, H^)".

--
Ben.

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 Ĥ:

>>>>>>>>>>> Ĥ.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?

--
Ben.

On 7/30/21 8:58 AM, olcott wrote:
> On 7/30/2021 9:54 AM, André G. Isaak wrote:
>> On 2021-07-29 22:34, olcott wrote:
>>> On 7/29/2021 8:25 PM, André G. Isaak wrote:
>>>> On 2021-07-29 18:54, olcott wrote:
>>
>>> _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]
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> Begin Local Halt Decider Simulation at Machine Address:c25
>>> [00000c25][00211776][0021177a] 55         push ebp      // P begins
>>> [00000c26][00211776][0021177a] 8bec       mov ebp,esp
>>> [00000c28][00211776][0021177a] 8b4508     mov eax,[ebp+08]
>>> [00000c2b][00211772][00000c25] 50         push eax      // push P
>>> [00000c2c][00211772][00000c25] 8b4d08     mov ecx,[ebp+08]
>>> [00000c2f][0021176e][00000c25] 51         push ecx      // push P
>>> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P)
>>>
>>> [00000c25][0025c19e][0025c1a2] 55         push ebp      // P begins
>>> [00000c26][0025c19e][0025c1a2] 8bec       mov ebp,esp
>>> [00000c28][0025c19e][0025c1a2] 8b4508     mov eax,[ebp+08]
>>> [00000c2b][0025c19a][00000c25] 50         push eax      // push P
>>> [00000c2c][0025c19a][00000c25] 8b4d08     mov ecx,[ebp+08]
>>> [00000c2f][0025c196][00000c25] 51         push ecx      // push P
>>> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P)
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>>>> P either remains infinitely stuck in its first seven instructions
>>>>> or H seeing that P is permanently stuck in its first seven
>>>>> instructions stops simulating P. There is no possible way that P
>>>>> ever reaches its final state, thus meeting the NEVER HALTS criteria.
>>>>
>>>> If you stopped ignoring what occurs at address 955 you would find
>>>> that you are mistaken.
>>>>
>>>> André
>>>>
>>>
>>> The claim is that the input to H(P,P) cannot possibly reach its final
>>> state @ 0x3cf. Since we know that H is a simulating halt decider we
>>> know that it can either continue to simulate P(P) or stop simulating
>>> P(P). In either case the input to H(P,P) cannot possibly reach its
>>> final state @ 0x3cf.
>>
>> Without knowing what happens at address 955, none of the above tells
>> us anything at all about what happens in this code.
>>
>> André
>>
>>
>
> That is very obviously flat out not true when we know that H is a
> simulating partial halt decider. In this case H either continues to
> simulate its input or stops simulating its input either way this input
> never reaches its final state of 0x3cf.
>
>
But since H is a Decider and NOT a pure simulator, the fact that it
doesn't reach a Halt state, but instead it aborted its simulation
doesn't prove or disprove the halting state of the machine that was
given as its input.

Only the results of a PURE simulation matter, one that will give the
machine as many steps as needed to reach the any finite number of steps
needed.

On 7/30/2021 2:22 PM, Ben Bacarisse wrote:
> I lost internet connection after writing a reply to this so it's
> possible both versions will appear. I hope not...
>
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> (I answered your other belligerent reply before I read this.)
>>>>>
>>>>>> I would prefer to move away from division and animosity to achieve an
>>>>>> honest dialogue striving for mutual agreement, are you game?
>>>>> Sure. Here are some other things about which I would like to seek
>>>>> mutual agreement:
>>>>> (1) A TM, M, halts on input s if the sequence of machine configurations
>>>>> generated by M's state transition function, along with the input s,
>>>>> is finite.
>>>>
>>>> I like André's reaches one of its own finite states better.
>>>> Is this OK with you?
>>> What you say here is too vague. If you can write it clearly and
>>> formally, I'm sure we could agree on it, but I suspect you can't. In
>>> the spirit of reaching an agreement, is there anything you object to in
>>> my definition?
>>
>> Your definition seems to be ambiguous when the simulation of a
>> computation has been aborted, André's definition is not ambiguous in
>> this case.
>
> It's not ambiguous. On the other hand, your definition (I won't call
> it André's unless he says you've got it right) uses too many vague
> words. If you can write it formally, we may be able to agree on it.
>

_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]

All of the inputs to H are complete functions that were translated by
the Microsoft C compiler have well-defined final states. The above
function has 0xc3f as its sole final state. If it reaches this final
state it halts. If its execution trace proves that it can never reach
this final state then it never halts.

>>>>> M is said to accept s if the final state is an accepting
>>>>> state. Otherwise M is said to reject the input s.
>>>>>
>>>> Yes
>>>>
>>>>> (2) A halt decider is a TM, D, that accepts only and all inputs of the
>>>>> form <m,s> where m encodes a TM that halts on input s. D rejects
>>>>> all others inputs.
>>>>
>>>> Yes with André's definition of halting.
>>>> Is this OK with you?
>>> Not unless you can write it clearly, no.
>>
>> We can work on this.
>
> Well, I can't. You can have another go at saying what you mean, but
> I've already had my say. I don't want to change my definition though
> I'll add to it if you think some parts need more explanation. By the
> way, it's the one with which you agreed before.
>

We must have a perfectly definitive way of dividing inputs that stop
running because their computation has fully completed from inputs that
stop running for any other reason.

>> The input to my partial halt decider is always a complete function
>> compiled from C and complete functions always have the explicit final
>> state of their last address.
>
> I'm talking about Turing machines. If you want to talk about the
> halting theorem, you should be prepared to discuss a formal model of
> computation. It would take a lot of work for you to pin down
> a C-based model of computation and I don't think you want to do that
> work.
>

Because it is utterly impossible to specify all of the relevant details
in the TM model of computation I created the x86utm system. All of the
formal proofs leave out most of the relevant details because these key
details cannot be specified in any reasonably compact and concise form.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and

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

The second ⊢* wildcard state has millions of unspecified steps that are
mere hand-waving. Because all of the conventional proofs are mostly
hand-waving it never occurred to anyone that a simulating halt decider
at Ĥ.qx would correctly decide that it must stop the simulation of its
input thus proving that its input never halts.

>>>>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>>>>> defined in any of the usual textbooks) that you called H to which
>>>>> Linz's "hat" constriction could be applied to get another TM, H^?
>>>>
>>>> I never had a Turing machine.
>>> OK, thanks. That's clear.
>>>
>>>> It was encoded in nearly complete C.
>>> This raises lots of questions:
>>> (3a) What are "the exact TMD instructions of the Linz Turing machine H"
>>> that you had encoded by Dec 14th in relation to this C code?
>>
>> Like I said I did not have a Turing Machine.
>
> Right, so why did you say words that make no sense in relation to what
> you did have? I'm trying to build trust so we can reach some mutual
> understanding, but that means I need to know why you repeatedly tried to
> make it seem as if you had what you incorrectly said you had, rather
> than what you did have.
>

I had the essence of the computational equivalent of what I claimed and
would have simply claimed that I has the essence of he computational
equivalent if I had known that TM equivalence was a thing that other
people knew about and not just private knowledge that I had.

At the end of 2018 I had only heard of TM complete and I knew that this
required unlimited memory. TM equivalence for a subset of computations
still seems to be a thing that no one else knows about. 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.

>>> (3b) What does "I provide the exact ⊢* wildcard states after the Linz
>>> H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H would
>>> correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?
>>
>> the proof ...is so short and simple that
>> it may be of interest to casual readers.
>> The version below uses CPL...
>>
>> rec routine P
>> §L:if T[P] go to L
>> Return §
>>
>> Strachey, C 1965. An impossible program The Computer Journal, Volume
>> 7, Issue 4, January 1965, Page 313,
>> https://doi.org/10.1093/comjnl/7.4.313
>>
>> In the same way that Strachey claims that his little CPL program sums
>> up the entire proof my premise is that this C code sums up the entire
>> proof.
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> What I had in 2018 was a crude way that code determined that the above
>> does specify infinitely nested simulation. "the exact ⊢* wildcard
>> states" refers to this code.
>
> Is this the best, most diligent answer to (3b) that you have? I must
> say it does not come close to explaining what these "exact states after
> the Linz H.q0 and after Ĥ.qx" are,

I was a crude kludge that worked.

> nor does it explain why you used the
> ⊢* notation when you did not have a Turing machine.

So you are not aware that all comutations have state transitions?
I count the x86 state transition as moving from one instruction to the
next.

> Was that a poetic
> usage as well, like the license you used to call your C code an "actual
> Turing machine"?
>
>>> Given that you had C code, the "UTM in C++" that you were writing that
>>> would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
>>> interpreter.
>>
>> It was not a C interpreter. It is an x86 emulator.
>
> Below you say it was not an x86 emulator but I not you say "is" not
> "was". I'm asking about what the "UTM in C++" that you planned to write
> was. You do explain that below.
>

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 ...

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.

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.

--
Copyright 2021 Pete Olcott

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

On 7/30/21 5:42 PM, olcott wrote:
> On 7/30/2021 2:22 PM, Ben Bacarisse wrote:
>> I lost internet connection after writing a reply to this so it's
>> possible both versions will appear.   I hope not...
>>
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> (I answered your other belligerent reply before I read this.)
>>>>>>
>>>>>>> I would prefer to move away from division and animosity to
>>>>>>> achieve an
>>>>>>> honest dialogue striving for mutual agreement, are you game?
>>>>>> Sure.  Here are some other things about which I would like to seek
>>>>>> mutual agreement:
>>>>>> (1) A TM, M, halts on input s if the sequence of machine
>>>>>> configurations
>>>>>>        generated by M's state transition function, along with the
>>>>>> input s,
>>>>>>        is finite.
>>>>>
>>>>> I like André's reaches one of its own finite states better.
>>>>> Is this OK with you?
>>>> What you say here is too vague.  If you can write it clearly and
>>>> formally, I'm sure we could agree on it, but I suspect you can't.  In
>>>> the spirit of reaching an agreement, is there anything you object to in
>>>> my definition?
>>>
>>> Your definition seems to be ambiguous when the simulation of a
>>> computation has been aborted, André's definition is not ambiguous in
>>> this case.
>>
>> It's not ambiguous.  On the other hand, your definition (I won't call
>> it André's unless he says you've got it right) uses too many vague
>> words.  If you can write it formally, we may be able to agree on it.
>>
>
> _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]
>
> All of the inputs to H are complete functions that were translated by
> the Microsoft C compiler have well-defined final states. The above
> function has 0xc3f as its sole final state. If it reaches this final
> state it halts. If its execution trace proves that it can never reach
> this final state then it never halts.

But the execution trace of main calling P(P) directly shows that P(P)
itself WILL halt, the problem is that H makes the mistake of thinking it
won't and stops it too soon. Thus H is wrong.

Behavior of the machine the input represent is the REAL ACTUAL
DEFINITION of Halting.

If you claim H can be right here, then we can just define a differnt
decider that immediately aborts the simulation and declair its input
never reached a halting state, and thus is non-halting.

FAIL.

>
>>>>>> M is said to accept s if the final state is an accepting
>>>>>>        state.  Otherwise M is said to reject the input s.
>>>>>>
>>>>> Yes
>>>>>
>>>>>> (2) A halt decider is a TM, D, that accepts only and all inputs of
>>>>>> the
>>>>>>        form <m,s> where m encodes a TM that halts on input s.  D
>>>>>> rejects
>>>>>>        all others inputs.
>>>>>
>>>>> Yes with André's definition of halting.
>>>>> Is this OK with you?
>>>> Not unless you can write it clearly, no.
>>>
>>> We can work on this.
>>
>> Well, I can't.  You can have another go at saying what you mean, but
>> I've already had my say.  I don't want to change my definition though
>> I'll add to it if you think some parts need more explanation.  By the
>> way, it's the one with which you agreed before.
>>
>
> We must have a perfectly definitive way of dividing inputs that stop
> running because their computation has fully completed from inputs that
> stop running for any other reason.

WHY?

And we do, we run the machines that the input represents and see what
they do. P(P) Halts. There is NO requirement that H needs to be able to
get the answer right, just that there IS a correct answer to the ACTUAL
question, does P(I) reach a halting state in a finite number of steps.
>
>>> The input to my partial halt decider is always a complete function
>>> compiled from C and complete functions always have the explicit final
>>> state of their last address.
>>
>> I'm talking about Turing machines.  If you want to talk about the
>> halting theorem, you should be prepared to discuss a formal model of
>> computation.  It would take a lot of work for you to pin down
>> a C-based model of computation and I don't think you want to do that
>> work.
>>
>
> Because it is utterly impossible to specify all of the relevant details
> in the TM model of computation I created the x86utm system. All of the
> formal proofs leave out most of the relevant details because these key
> details cannot be specified in any reasonably compact and concise form.

But it isn't. Maybe for you it is, but by the Turing Equivalence Theorem
you are using, if your machine actually is the Computational Equivalent
of a Turing Machine, such a Turing Machine can be made.

If you REALLY mean that can't be done, then it says your 'program' isn't
a computation and thus doesn't fullfil the requirements.

>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> if M applied to wM halts, and
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt
>
> The second ⊢* wildcard state has millions of unspecified steps that are
> mere hand-waving. Because all of the conventional proofs are mostly
> hand-waving it never occurred to anyone that a simulating halt decider
> at Ĥ.qx would correctly decide that it must stop the simulation of its
> input thus proving that its input never halts.

They aren't hand waving, YOU do hand waving.

Note, you in effect are admitting to your flaw, because a simulator
stopping its simulation NEVER actual PROVES anything.

UNSOUND LOGIC, FAIL.

>
>>>>>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>>>>>>        defined in any of the usual textbooks) that you called H to
>>>>>> which
>>>>>>        Linz's "hat" constriction could be applied to get another
>>>>>> TM, H^?
>>>>>
>>>>> I never had a Turing machine.
>>>> OK, thanks.  That's clear.
>>>>
>>>>> It was encoded in nearly complete C.
>>>> This raises lots of questions:
>>>> (3a) What are "the exact TMD instructions of the Linz Turing machine H"
>>>>        that you had encoded by Dec 14th in relation to this C code?
>>>
>>> Like I said I did not have a Turing Machine.
>>
>> Right, so why did you say words that make no sense in relation to what
>> you did have?  I'm trying to build trust so we can reach some mutual
>> understanding, but that means I need to know why you repeatedly tried to
>> make it seem as if you had what you incorrectly said you had, rather
>> than what you did have.
>>
>
> I had the essence of the computational equivalent of what I claimed and
> would have simply claimed that I has the essence of he computational
> equivalent if I had known that TM equivalence was a thing that other
> people knew about and not just private knowledge that I had.
>
> At the end of 2018 I had only heard of TM complete and I knew that this
> required unlimited memory. TM equivalence for a subset of computations
> still seems to be a thing that no one else knows about. 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.

On 7/30/2021 12:44 AM, Richard Damon wrote:
> On 7/29/21 9:34 PM, olcott wrote:
>
>> The claim is that the input to H(P,P) cannot possibly reach its final
>> state @ 0x3cf. Since we know that H is a simulating halt decider we know
>> that it can either continue to simulate P(P) or stop simulating P(P). In
>> either case the input to H(P,P) cannot possibly reach its final state @
>> 0x3cf.
>>
>
> But that doesn't actually matter.
>

Sure it does it proves that the input to H(P,P) never halts thus proving
that H(P,P)==0 is correct no matter what another different P that is not
an input to H does.

--
Copyright 2021 Pete Olcott

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

On 7/30/21 6:42 PM, olcott wrote:
> On 7/30/2021 12:44 AM, Richard Damon wrote:
>> On 7/29/21 9:34 PM, olcott wrote:
>>
>>> The claim is that the input to H(P,P) cannot possibly reach its final
>>> state @ 0x3cf. Since we know that H is a simulating halt decider we know
>>> that it can either continue to simulate P(P) or stop simulating P(P). In
>>> either case the input to H(P,P) cannot possibly reach its final state @
>>> 0x3cf.
>>>
>>
>> But that doesn't actually matter.
>>
>
> Sure it does it proves that the input to H(P,P) never halts thus proving
> that H(P,P)==0 is correct no matter what another different P that is not
> an input to H does.
>

WHY?

As I said, the fact that an ABORTED simulation didn't reach a final
halting state does NOT prove that the machine it represents is
non-halting. The Definition only refers to the ACTUAL Machine, or we can
use the definition of a UTM to show that a PURE SIMULATOR that NEVER
aborts its simulation does the same thing.

The fact that H^(H^) Halts PROVES that H aborted it simulation of
H(H^,H^) too soon. We can even see the point in the trace of H^(H^) of
where H simulated to and that if it didn't abort that copy, it would
have come to a halt, by following the exact same computation in H^(H^).

By your definition, a pathological halt decider could decide that ALL
Computations are non-halting.

Your 'Proof' that H uses is UNSOUND, as it presumes that H will NEVER
terminate its simulation, when H will. So it doesn't run the simulation
far enough.

FAIL.

On 7/30/2021 8:57 PM, Richard Damon wrote:
> On 7/30/21 6:42 PM, olcott wrote:
>> On 7/30/2021 12:44 AM, Richard Damon wrote:
>>> On 7/29/21 9:34 PM, olcott wrote:
>>>
>>>> The claim is that the input to H(P,P) cannot possibly reach its final
>>>> state @ 0x3cf. Since we know that H is a simulating halt decider we know
>>>> that it can either continue to simulate P(P) or stop simulating P(P). In
>>>> either case the input to H(P,P) cannot possibly reach its final state @
>>>> 0x3cf.
>>>>
>>>
>>> But that doesn't actually matter.
>>>
>>
>> Sure it does it proves that the input to H(P,P) never halts thus proving
>> that H(P,P)==0 is correct no matter what another different P that is not
>> an input to H does.
>>
>
> WHY?
>
> As I said, the fact that an ABORTED simulation didn't reach a final
> halting state does NOT prove that the machine it represents is
> non-halting.

The fact that the input to H(P,P) and the input to embedded halt decider
Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) of the actual full blown Linz proof can't possibly reach
their final state whether or not this input is ever aborted conclusively
proves that both H and Ĥ.qx correctly decide that their inputs never halt.

--
Copyright 2021 Pete Olcott

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

On 7/30/21 7:08 PM, olcott wrote:
> On 7/30/2021 8:57 PM, Richard Damon wrote:
>> On 7/30/21 6:42 PM, olcott wrote:
>>> On 7/30/2021 12:44 AM, Richard Damon wrote:
>>>> On 7/29/21 9:34 PM, olcott wrote:
>>>>
>>>>> The claim is that the input to H(P,P) cannot possibly reach its final
>>>>> state @ 0x3cf. Since we know that H is a simulating halt decider we
>>>>> know
>>>>> that it can either continue to simulate P(P) or stop simulating
>>>>> P(P). In
>>>>> either case the input to H(P,P) cannot possibly reach its final
>>>>> state @
>>>>> 0x3cf.
>>>>>
>>>>
>>>> But that doesn't actually matter.
>>>>
>>>
>>> Sure it does it proves that the input to H(P,P) never halts thus proving
>>> that H(P,P)==0 is correct no matter what another different P that is not
>>> an input to H does.
>>>
>>
>> WHY?
>>
>> As I said, the fact that an ABORTED simulation didn't reach a final
>> halting state does NOT prove that the machine it represents is
>> non-halting.
>
> The fact that the input to H(P,P) and the input to embedded halt decider
> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) of the actual full blown Linz proof can't possibly reach
> their final state whether or not this input is ever aborted conclusively
> proves that both H and Ĥ.qx correctly decide that their inputs never halt.
>

No, it does NOT prove that. Only a UNCONDITIONAL Simulation would show that.

As I have said, all that your statement proves is that no H can prove
that its H^ halts.

Failure to prove is not a proof of the opposite.

You logic is totally UNSOUND.

You logic is totally inconsistent.

I would even say your mind seems to be UNSOUND if it can't see the
UNSOUNDNESS of the argument.

I would say you also totally don't understand how logic works if you
think that this is a real proof.

On 7/30/2021 10:54 PM, Richard Damon wrote:
> On 7/30/21 7:08 PM, olcott wrote:
>> On 7/30/2021 8:57 PM, Richard Damon wrote:
>>> On 7/30/21 6:42 PM, olcott wrote:
>>>> On 7/30/2021 12:44 AM, Richard Damon wrote:
>>>>> On 7/29/21 9:34 PM, olcott wrote:
>>>>>
>>>>>> The claim is that the input to H(P,P) cannot possibly reach its final
>>>>>> state @ 0x3cf. Since we know that H is a simulating halt decider we
>>>>>> know
>>>>>> that it can either continue to simulate P(P) or stop simulating
>>>>>> P(P). In
>>>>>> either case the input to H(P,P) cannot possibly reach its final
>>>>>> state @
>>>>>> 0x3cf.
>>>>>>
>>>>>
>>>>> But that doesn't actually matter.
>>>>>
>>>>
>>>> Sure it does it proves that the input to H(P,P) never halts thus proving
>>>> that H(P,P)==0 is correct no matter what another different P that is not
>>>> an input to H does.
>>>>
>>>
>>> WHY?
>>>
>>> As I said, the fact that an ABORTED simulation didn't reach a final
>>> halting state does NOT prove that the machine it represents is
>>> non-halting.
>>
>> The fact that the input to H(P,P) and the input to embedded halt decider
>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) of the actual full blown Linz proof can't possibly reach
>> their final state whether or not this input is ever aborted conclusively
>> proves that both H and Ĥ.qx correctly decide that their inputs never halt.
>>
>
> No, it does NOT prove that. Only a UNCONDITIONAL Simulation would show that.
>

_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]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P1 begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1(P2,P2)

[00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2(P3,P3)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Anyone that knows the x86 language can see that the input to P cannot
possibly ever reach its halt state of 0xc3f whether or not H remains in
pure simulator mode AKA unconditional simulation.

> As I have said, all that your statement proves is that no H can prove
> that its H^ halts.
>
> Failure to prove is not a proof of the opposite.
>
> You logic is totally UNSOUND.
>
> You logic is totally inconsistent.
>
> I would even say your mind seems to be UNSOUND if it can't see the
> UNSOUNDNESS of the argument.
>
> I would say you also totally don't understand how logic works if you
> think that this is a real proof.
>
>

--
Copyright 2021 Pete Olcott

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

On Saturday, 31 July 2021 at 22:15:01 UTC+8, olcott wrote:
> On 7/30/2021 10:54 PM, Richard Damon wrote:
> > On 7/30/21 7:08 PM, olcott wrote:
> >> On 7/30/2021 8:57 PM, Richard Damon wrote:
> >>> On 7/30/21 6:42 PM, olcott wrote:
> >>>> On 7/30/2021 12:44 AM, Richard Damon wrote:
> >>>>> On 7/29/21 9:34 PM, olcott wrote:
> >>>>>
> >>>>>> The claim is that the input to H(P,P) cannot possibly reach its final
> >>>>>> state @ 0x3cf. Since we know that H is a simulating halt decider we
> >>>>>> know
> >>>>>> that it can either continue to simulate P(P) or stop simulating
> >>>>>> P(P). In
> >>>>>> either case the input to H(P,P) cannot possibly reach its final
> >>>>>> state @
> >>>>>> 0x3cf.
> >>>>>>
> >>>>>
> >>>>> But that doesn't actually matter.
> >>>>>
> >>>>
> >>>> Sure it does it proves that the input to H(P,P) never halts thus proving
> >>>> that H(P,P)==0 is correct no matter what another different P that is not
> >>>> an input to H does.
> >>>>
> >>>
> >>> WHY?
> >>>
> >>> As I said, the fact that an ABORTED simulation didn't reach a final
> >>> halting state does NOT prove that the machine it represents is
> >>> non-halting.
> >>
> >> The fact that the input to H(P,P) and the input to embedded halt decider
> >> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) of the actual full blown Linz proof can't possibly reach
> >> their final state whether or not this input is ever aborted conclusively
> >> proves that both H and Ĥ.qx correctly decide that their inputs never halt.
> >>
> >
> > No, it does NOT prove that. Only a UNCONDITIONAL Simulation would show that.
> >
> _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]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> Begin Local Halt Decider Simulation at Machine Address:c25
> [00000c25][00211776][0021177a] 55 push ebp // P1 begins
> [00000c26][00211776][0021177a] 8bec mov ebp,esp
> [00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
> [00000c2b][00211772][00000c25] 50 push eax // push P
> [00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
> [00000c2f][0021176e][00000c25] 51 push ecx // push P
> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1(P2,P2)
>
> [00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
> [00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
> [00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
> [00000c2b][0025c19a][00000c25] 50 push eax // push P
> [00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
> [00000c2f][0025c196][00000c25] 51 push ecx // push P
> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2(P3,P3)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> Anyone that knows the x86 language can see that the input to P cannot
> possibly ever reach its halt state of 0xc3f whether or not H remains in
> pure simulator mode AKA unconditional simulation.

Exactly, That is why "undecidable" is called.
There always exists "pathological" inputs that the halt decider H will fail..
The "pathological" self-reference input need not necessarily to look anything
like self-reference or "pathological".

> > As I have said, all that your statement proves is that no H can prove
> > that its H^ halts.
> >
> > Failure to prove is not a proof of the opposite.
> >
> > You logic is totally UNSOUND.
> >
> > You logic is totally inconsistent.
> >
> > I would even say your mind seems to be UNSOUND if it can't see the
> > UNSOUNDNESS of the argument.
> >
> > I would say you also totally don't understand how logic works if you
> > think that this is a real proof.
> >
> >
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

On 7/31/2021 10:02 AM, wij wrote:
> On Saturday, 31 July 2021 at 22:15:01 UTC+8, olcott wrote:
>> On 7/30/2021 10:54 PM, Richard Damon wrote:
>>> On 7/30/21 7:08 PM, olcott wrote:
>>>> On 7/30/2021 8:57 PM, Richard Damon wrote:
>>>>> On 7/30/21 6:42 PM, olcott wrote:
>>>>>> On 7/30/2021 12:44 AM, Richard Damon wrote:
>>>>>>> On 7/29/21 9:34 PM, olcott wrote:
>>>>>>>
>>>>>>>> The claim is that the input to H(P,P) cannot possibly reach its final
>>>>>>>> state @ 0x3cf. Since we know that H is a simulating halt decider we
>>>>>>>> know
>>>>>>>> that it can either continue to simulate P(P) or stop simulating
>>>>>>>> P(P). In
>>>>>>>> either case the input to H(P,P) cannot possibly reach its final
>>>>>>>> state @
>>>>>>>> 0x3cf.
>>>>>>>>
>>>>>>>
>>>>>>> But that doesn't actually matter.
>>>>>>>
>>>>>>
>>>>>> Sure it does it proves that the input to H(P,P) never halts thus proving
>>>>>> that H(P,P)==0 is correct no matter what another different P that is not
>>>>>> an input to H does.
>>>>>>
>>>>>
>>>>> WHY?
>>>>>
>>>>> As I said, the fact that an ABORTED simulation didn't reach a final
>>>>> halting state does NOT prove that the machine it represents is
>>>>> non-halting.
>>>>
>>>> The fact that the input to H(P,P) and the input to embedded halt decider
>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) of the actual full blown Linz proof can't possibly reach
>>>> their final state whether or not this input is ever aborted conclusively
>>>> proves that both H and Ĥ.qx correctly decide that their inputs never halt.
>>>>
>>>
>>> No, it does NOT prove that. Only a UNCONDITIONAL Simulation would show that.
>>>
>> _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]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> Begin Local Halt Decider Simulation at Machine Address:c25
>> [00000c25][00211776][0021177a] 55 push ebp // P1 begins
>> [00000c26][00211776][0021177a] 8bec mov ebp,esp
>> [00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
>> [00000c2b][00211772][00000c25] 50 push eax // push P
>> [00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
>> [00000c2f][0021176e][00000c25] 51 push ecx // push P
>> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1(P2,P2)
>>
>> [00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
>> [00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
>> [00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
>> [00000c2b][0025c19a][00000c25] 50 push eax // push P
>> [00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
>> [00000c2f][0025c196][00000c25] 51 push ecx // push P
>> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2(P3,P3)
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>> Anyone that knows the x86 language can see that the input to P cannot
>> possibly ever reach its halt state of 0xc3f whether or not H remains in
>> pure simulator mode AKA unconditional simulation.
>
> Exactly, That is why "undecidable" is called.
> There always exists "pathological" inputs that the halt decider H will fail.

The halt decider does not freaking fail on its freaking inputs.

We know with 100% perfect complete logical certainty that the halt
decider does correctly decide that its input never halts.

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.

If you don't know the x86 language then this may not be apparent.

> The "pathological" self-reference input need not necessarily to look anything
> like self-reference or "pathological".
>
>
>>> As I have said, all that your statement proves is that no H can prove
>>> that its H^ halts.
>>>
>>> Failure to prove is not a proof of the opposite.
>>>
>>> You logic is totally UNSOUND.
>>>
>>> You logic is totally inconsistent.
>>>
>>> I would even say your mind seems to be UNSOUND if it can't see the
>>> UNSOUNDNESS of the argument.
>>>
>>> I would say you also totally don't understand how logic works if you
>>> think that this is a real proof.
>>>
>>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein

--
Copyright 2021 Pete Olcott

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

On 7/31/21 7:14 AM, olcott wrote:
> On 7/30/2021 10:54 PM, Richard Damon wrote:
>> On 7/30/21 7:08 PM, olcott wrote:
>>> On 7/30/2021 8:57 PM, Richard Damon wrote:
>>>> On 7/30/21 6:42 PM, olcott wrote:
>>>>> On 7/30/2021 12:44 AM, Richard Damon wrote:
>>>>>> On 7/29/21 9:34 PM, olcott wrote:
>>>>>>
>>>>>>> The claim is that the input to H(P,P) cannot possibly reach its
>>>>>>> final
>>>>>>> state @ 0x3cf. Since we know that H is a simulating halt decider we
>>>>>>> know
>>>>>>> that it can either continue to simulate P(P) or stop simulating
>>>>>>> P(P). In
>>>>>>> either case the input to H(P,P) cannot possibly reach its final
>>>>>>> state @
>>>>>>> 0x3cf.
>>>>>>>
>>>>>>
>>>>>> But that doesn't actually matter.
>>>>>>
>>>>>
>>>>> Sure it does it proves that the input to H(P,P) never halts thus
>>>>> proving
>>>>> that H(P,P)==0 is correct no matter what another different P that
>>>>> is not
>>>>> an input to H does.
>>>>>
>>>>
>>>> WHY?
>>>>
>>>> As I said, the fact that an ABORTED simulation didn't reach a final
>>>> halting state does NOT prove that the machine it represents is
>>>> non-halting.
>>>
>>> The fact that the input to H(P,P) and the input to embedded halt decider
>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) of the actual full blown Linz proof can't possibly reach
>>> their final state whether or not this input is ever aborted conclusively
>>> proves that both H and Ĥ.qx correctly decide that their inputs never
>>> halt.
>>>
>>
>> No, it does NOT prove that. Only a UNCONDITIONAL Simulation would show
>> that.
>>
>
> _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]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> Begin Local Halt Decider Simulation at Machine Address:c25
> [00000c25][00211776][0021177a] 55         push ebp      // P1 begins
> [00000c26][00211776][0021177a] 8bec       mov ebp,esp
> [00000c28][00211776][0021177a] 8b4508     mov eax,[ebp+08]
> [00000c2b][00211772][00000c25] 50         push eax      // push P
> [00000c2c][00211772][00000c25] 8b4d08     mov ecx,[ebp+08]
> [00000c2f][0021176e][00000c25] 51         push ecx      // push P
> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1(P2,P2)
>
> [00000c25][0025c19e][0025c1a2] 55         push ebp      // P2 begins
> [00000c26][0025c19e][0025c1a2] 8bec       mov ebp,esp
> [00000c28][0025c19e][0025c1a2] 8b4508     mov eax,[ebp+08]
> [00000c2b][0025c19a][00000c25] 50         push eax      // push P
> [00000c2c][0025c19a][00000c25] 8b4d08     mov ecx,[ebp+08]
> [00000c2f][0025c196][00000c25] 51         push ecx      // push P
> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2(P3,P3)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> Anyone that knows the x86 language can see that the input to P cannot
> possibly ever reach its halt state of 0xc3f whether or not H remains in
> pure simulator mode AKA unconditional simulation.

Wrong. Obviously you don't understand how computers work. Your trace is
incorrect, as a call to 00000955 should then create code that RUNS at
00000955.

The transformation of a trace of a simulator to the trace of the
simulated code is only applicable for a TRULY PURE SIMULATOR (not an I
will call it pure but it sill might not be simulator)

Once H1 leaves its misnamed 'pure simulation mode' and returns its
answer that it thinks P2 is non-halting, then P1 will halt. Even YOU
have posted this trace (starting at P0) and even YOU agree that P0 will
halt. Since P1 is an identical computation to P0, its trace will be
identical, so H0 stopping it part way is just proof that H is wrong.

H uses UNSOUND logic and gets a wrong anwers.

You OBVIOUSLY have some form of mental deficiency as this has been
pointed out MANY times before, but you seem to be stuck in you PROVABLY
wrong idea.

>
>> As I have said, all that your statement proves is that no H can prove
>> that its H^ halts.
>>
>> Failure to prove is not a proof of the opposite.
>>
>> You logic is totally UNSOUND.
>>
>> You logic is totally inconsistent.
>>
>> I would even say your mind seems to be UNSOUND if it can't see the
>> UNSOUNDNESS of the argument.
>>
>> I would say you also totally don't understand how logic works if you
>> think that this is a real proof.
>>
>>
>
>

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.

As has been shown, if you replace THAT instance of H with a real PURE
simulation, that simulation will run to completion, thus PROVING that H
was incorrect.

Important note, that you don't seem to understand this, this change is
ONLY to this top level H that we are verifying, we are NOT ALLOWED to
change the copy of H that is embedded in the input, that would be like
studing Dogs to find out the properties of a Cat.

>
> If you don't know the x86 language then this may not be apparent.

Right, Like since you have no clue about Turing Machines or what a
Computation is, my statements won't make sense to you.

On 7/31/2021 10:26 AM, Richard Damon wrote:
> On 7/31/21 7:14 AM, olcott wrote:
>> On 7/30/2021 10:54 PM, Richard Damon wrote:
>>> On 7/30/21 7:08 PM, olcott wrote:
>>>> On 7/30/2021 8:57 PM, Richard Damon wrote:
>>>>> On 7/30/21 6:42 PM, olcott wrote:
>>>>>> On 7/30/2021 12:44 AM, Richard Damon wrote:
>>>>>>> On 7/29/21 9:34 PM, olcott wrote:
>>>>>>>
>>>>>>>> The claim is that the input to H(P,P) cannot possibly reach its
>>>>>>>> final
>>>>>>>> state @ 0x3cf. Since we know that H is a simulating halt decider we
>>>>>>>> know
>>>>>>>> that it can either continue to simulate P(P) or stop simulating
>>>>>>>> P(P). In
>>>>>>>> either case the input to H(P,P) cannot possibly reach its final
>>>>>>>> state @
>>>>>>>> 0x3cf.
>>>>>>>>
>>>>>>>
>>>>>>> But that doesn't actually matter.
>>>>>>>
>>>>>>
>>>>>> Sure it does it proves that the input to H(P,P) never halts thus
>>>>>> proving
>>>>>> that H(P,P)==0 is correct no matter what another different P that
>>>>>> is not
>>>>>> an input to H does.
>>>>>>
>>>>>
>>>>> WHY?
>>>>>
>>>>> As I said, the fact that an ABORTED simulation didn't reach a final
>>>>> halting state does NOT prove that the machine it represents is
>>>>> non-halting.
>>>>
>>>> The fact that the input to H(P,P) and the input to embedded halt decider
>>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) of the actual full blown Linz proof can't possibly reach
>>>> their final state whether or not this input is ever aborted conclusively
>>>> proves that both H and Ĥ.qx correctly decide that their inputs never
>>>> halt.
>>>>
>>>
>>> No, it does NOT prove that. Only a UNCONDITIONAL Simulation would show
>>> that.
>>>
>>
>> _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]
>>
>>  machine   stack     stack     machine    assembly
>>  address   address   data      code       language
>>  ========  ========  ========  =========  =============
>> Begin Local Halt Decider Simulation at Machine Address:c25
>> [00000c25][00211776][0021177a] 55         push ebp      // P1 begins
>> [00000c26][00211776][0021177a] 8bec       mov ebp,esp
>> [00000c28][00211776][0021177a] 8b4508     mov eax,[ebp+08]
>> [00000c2b][00211772][00000c25] 50         push eax      // push P
>> [00000c2c][00211772][00000c25] 8b4d08     mov ecx,[ebp+08]
>> [00000c2f][0021176e][00000c25] 51         push ecx      // push P
>> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1(P2,P2)
>>
>> [00000c25][0025c19e][0025c1a2] 55         push ebp      // P2 begins
>> [00000c26][0025c19e][0025c1a2] 8bec       mov ebp,esp
>> [00000c28][0025c19e][0025c1a2] 8b4508     mov eax,[ebp+08]
>> [00000c2b][0025c19a][00000c25] 50         push eax      // push P
>> [00000c2c][0025c19a][00000c25] 8b4d08     mov ecx,[ebp+08]
>> [00000c2f][0025c196][00000c25] 51         push ecx      // push P
>> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2(P3,P3)
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> Anyone that knows the x86 language can see that the input to P cannot
>> possibly ever reach its halt state of 0xc3f whether or not H remains in
>> pure simulator mode AKA unconditional simulation.
>
> Wrong. Obviously you don't understand how computers work. Your trace is
> incorrect, as a call to 00000955 should then create code that RUNS at
> 00000955.
>

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.

I will add this to my paper so that it is clear.

> The transformation of a trace of a simulator to the trace of the
> simulated code is only applicable for a TRULY PURE SIMULATOR (not an I
> will call it pure but it sill might not be simulator)
>
> Once H1 leaves its misnamed 'pure simulation mode' and returns its
> answer that it thinks P2 is non-halting, then P1 will halt. Even YOU
> have posted this trace (starting at P0) and even YOU agree that P0 will
> halt. Since P1 is an identical computation to P0, its trace will be
> identical, so H0 stopping it part way is just proof that H is wrong.
>
> H uses UNSOUND logic and gets a wrong anwers.
>
> You OBVIOUSLY have some form of mental deficiency as this has been
> pointed out MANY times before, but you seem to be stuck in you PROVABLY
> wrong idea.
>
>>
>>> As I have said, all that your statement proves is that no H can prove
>>> that its H^ halts.
>>>
>>> Failure to prove is not a proof of the opposite.
>>>
>>> You logic is totally UNSOUND.
>>>
>>> You logic is totally inconsistent.
>>>
>>> I would even say your mind seems to be UNSOUND if it can't see the
>>> UNSOUNDNESS of the argument.
>>>
>>> I would say you also totally don't understand how logic works if you
>>> think that this is a real proof.
>>>
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

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

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.

--
Copyright 2021 Pete Olcott

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

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 obviously don't understand verifiably correct, as it is verifiable
that H^(H^) is a halting computation, you have even posted a 'trace'
that proves it. So a Non-Halting answer CAN'T be correct.

The fact that H doesn't reach that point because it incorrectly aborts
its trace doesn't prove that H^ is non-halting, that only applies if an
UNCONDITIONAL PURE Simulation never reaches the halt state for every
finite number of steps performed. On YOU seem to make the MISTAKE of
assuming that an aborted simulation can prove this.

So, your statement that H can never simulate its input to the halt state
doesn't actually prove the statement you claim it does, can you try to
actual form a REAL ANALYTICAL PROOF (If you even know what that means)
to show what you claim. All you have proved is that H can not PROVE that
H^(H^) is halting, but lack of proof is not proof of falsehood, that may
be part of your problem, you hold to that false idea.

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.

That is like claiming you can't be a murderer because you were a
perfectly law abiding citizen until you shot the victim.

Once H does abort its simulation, it shows that it NEVER was a pure
simulator.

Note, Being a 'Pure Simulator' is like most things about Turing Machines
NOT a 'temporal' concept, but a total state. UTMs are COMPUTATION which
mean that are mappings of input to output. Just because you STARTED
following those rules, once you break them your computation doesn't
follow those conditions, so you can't claim any of the properties of
UTM, like the ability to replace a UTM simulating a machine with the
machine being simulated. That ONLY applies for a UTM, and acting like a
UTM untill x is NOT acting like a UTM.

FAIL

UNSOUND.

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.

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.

> You obviously don't understand verifiably correct, as it is verifiable
> that H^(H^) is a halting computation, you have even posted a 'trace'
> that proves it. So a Non-Halting answer CAN'T be correct.
>
> The fact that H doesn't reach that point because it incorrectly aborts
> its trace doesn't prove that H^ is non-halting, that only applies if an
> UNCONDITIONAL PURE Simulation never reaches the halt state for every
> finite number of steps performed. On YOU seem to make the MISTAKE of
> assuming that an aborted simulation can prove this.
>
> So, your statement that H can never simulate its input to the halt state
> doesn't actually prove the statement you claim it does, can you try to
> actual form a REAL ANALYTICAL PROOF (If you even know what that means)
> to show what you claim. All you have proved is that H can not PROVE that
> H^(H^) is halting, but lack of proof is not proof of falsehood, that may
> be part of your problem, you hold to that false idea.
>

--
Copyright 2021 Pete Olcott

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

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.

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.

H can ignore its own behavior in any execution traces while it remains a
pure simulator of its input because a pure simulator of its input cannot
possibly have any effect on the behavior of its input thus not have any
effect on the halt status decision regarding the behavior of the input.

--
Copyright 2021 Pete Olcott

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

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. Since
non-halting requires showing that there is NO finite number of steps
that it halts into, just showing it doesn't halt for a small number
doesn't mean anything.

Since H^(H^) DOES Halt when run as a machine, or simulated by a REAL
UTM, it IS a Halting Computation.

The DEFINITION of Halting refers to the ACTUAL running of the Mahcine.

There is a second definition of a UTM that says that such a pure
simulation of a a mmchine will give the same results, so could be used also.

Since the simulation of H is NOT identical to the simulation produced by
a UTM (it stops early), H is NOT a UTM (of if it is, then this H never
answers H(H^,H^) for its H^) so we can't use the simulation of H until
you actually PROVE that the results are applicable. This requires a REAL
FORMAL ANALYTICAL PROOF (which you seem incapable of generating), not
just a rhetorical claim.

Note, you also like to use the FALSE transformation of converting the
simulation of a conditional simulator into the simulation of the
simulated machine. This transform is only valid for a UTM, ie a TOTALLY
unconditional simulation.

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.

H is wrong because it doesn't look at all of the behaior of the machine
it is deciding on.

> H can ignore its own behavior in any execution traces while it remains a
> pure simulator of its input because a pure simulator of its input cannot
> possibly have any effect on the behavior of its input thus not have any
> effect on the halt status decision regarding the behavior of the input.
>
>

WRONG. DISPROVEN. UNSOUND. DELUSIONAL.

FAIL.

H doesn't affact the behavior of the machine it is simulating, but DOES
affect the machine that it is part of. Ignoring that just makes you UNSOUND.

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.

_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.

Because P cannot possibly ever reach its final state we know for sure
that P never halts.

> Since
> non-halting requires showing that there is NO finite number of steps
> that it halts into, just showing it doesn't halt for a small number
> doesn't mean anything.
>
> Since H^(H^) DOES Halt when run as a machine, or simulated by a REAL
> UTM, it IS a Halting Computation.
>
> The DEFINITION of Halting refers to the ACTUAL running of the Mahcine.
>
> There is a second definition of a UTM that says that such a pure
> simulation of a a mmchine will give the same results, so could be used also.
>
> Since the simulation of H is NOT identical to the simulation produced by
> a UTM (it stops early), H is NOT a UTM (of if it is, then this H never
> answers H(H^,H^) for its H^) so we can't use the simulation of H until
> you actually PROVE that the results are applicable. This requires a REAL
> FORMAL ANALYTICAL PROOF (which you seem incapable of generating), not
> just a rhetorical claim.
>
> Note, you also like to use the FALSE transformation of converting the
> simulation of a conditional simulator into the simulation of the
> simulated machine. This transform is only valid for a UTM, ie a TOTALLY
> unconditional simulation.
>

--
Copyright 2021 Pete Olcott

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

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.

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.

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.

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.

> H is wrong because it doesn't look at all of the behaior of the machine
> it is deciding on.
>
>
>> H can ignore its own behavior in any execution traces while it remains a
>> pure simulator of its input because a pure simulator of its input cannot
>> possibly have any effect on the behavior of its input thus not have any
>> effect on the halt status decision regarding the behavior of the input.
>>
>>
>
> WRONG. DISPROVEN. UNSOUND. DELUSIONAL.
>
> FAIL.
>
> H doesn't affact the behavior of the machine it is simulating, but DOES
> affect the machine that it is part of. Ignoring that just makes you UNSOUND.
>

--
Copyright 2021 Pete Olcott

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