On 9/18/21 5:48 PM, olcott wrote:
> On 9/18/2021 4:38 PM, Richard Damon wrote:
>> On 9/18/21 5:22 PM, olcott wrote:
>>> On 9/18/2021 3:55 PM, Richard Damon wrote:
>>>> On 9/18/21 4:07 PM, olcott wrote:
>>>>> On 9/18/2021 2:52 PM, Richard Damon wrote:
>>>>>> On 9/18/21 3:30 PM, olcott wrote:
>>>>>>> On 9/18/2021 2:08 PM, Richard Damon wrote:
>>>>>>>> On 9/18/21 12:50 PM, olcott wrote:
>>>>>>>>> On 9/18/2021 11:28 AM, Richard Damon wrote:
>>>>>>>>>> On 9/18/21 12:15 PM, olcott wrote:
>>>>>>>>>>> On 9/18/2021 10:52 AM, Richard Damon wrote:
>>>>>>>>>>>> On 9/18/21 11:39 AM, olcott wrote:
>>>>>>>>>>>>> On 9/18/2021 10:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/18/21 11:29 AM, olcott wrote:
>>>>>>>>>>>>>>> On 9/18/2021 10:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/18/21 11:17 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/18/2021 10:04 AM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2021-09-18 07:57, olcott wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I either must stick with C/x86 code or write a RASP
>>>>>>>>>>>>>>>>>>> machine, the
>>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>>> way that my key insights can possible be fully
>>>>>>>>>>>>>>>>>>> understood
>>>>>>>>>>>>>>>>>>> is to
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> every single detail as fully operational code such that
>>>>>>>>>>>>>>>>>>> we can
>>>>>>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>>>>>> see what it does and thus not merely imagine what it
>>>>>>>>>>>>>>>>>>> would do.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Why do you insist on continuously repeating this rather
>>>>>>>>>>>>>>>>>> ridiculous
>>>>>>>>>>>>>>>>>> claim?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When working with Turing Machines one doesn't need to
>>>>>>>>>>>>>>>>>> 'merely
>>>>>>>>>>>>>>>>>> imagine
>>>>>>>>>>>>>>>>>> what it would do.' One can see *exactly* what it does.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When H is defined as a simulating halt decider then H
>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>> decides
>>>>>>>>>>>>>>>>> the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that it doesn't, as H says H^(H^) is non-halting
>>>>>>>>>>>>>>>> when it
>>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>> Halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which says that it is deciding that H^(<H^>) is a non-halting
>>>>>>>>>>>>>> computation, but if we run H^(<H^>) it ends up at its
>>>>>>>>>>>>>> terminal
>>>>>>>>>>>>>> state
>>>>>>>>>>>>>> H^.qy which halts. (Since the code for H^ is derived from the
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>> of H,
>>>>>>>>>>>>>> and the state H^.qn is the corresponding state to H.qn)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So does my use of a static local variable by itself make my
>>>>>>>>>>>>> code not
>>>>>>>>>>>>> apply to the halting problem or not?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, but that doesn't mean that the presence of the static local
>>>>>>>>>>>> variable
>>>>>>>>>>>> is unconditionally allowed.
>>>>>>>>>>>>
>>>>>>>>>>>> You need to PROVE that your program is a Computation.
>>>>>>>>>>>>
>>>>>>>>>>>> Lack of things like static local variables make that proof much
>>>>>>>>>>>> easier.
>>>>>>>>>>>> as if all information inside the program can only be derived
>>>>>>>>>>>> from the
>>>>>>>>>>>> official input, then there is no source of 'illegal'
>>>>>>>>>>>> information.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The halt status decision is entirely based on the execution
>>>>>>>>>>> trace
>>>>>>>>>>> derived from the input machine address pair.
>>>>>>>>>>
>>>>>>>>>> Right, but that ALSO applies to the simulated copies of H, which
>>>>>>>>>> need to
>>>>>>>>>> give the exact same answer given the exact same input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The original way that it worked was that the very first slave
>>>>>>>>> that saw
>>>>>>>>> that an infinite behavior pattern was matched reported this
>>>>>>>>> through a
>>>>>>>>> static variable that every master/slave instance of H used as
>>>>>>>>> their
>>>>>>>>> while (**Aborted == 0) termination condition.
>>>>>>>>>
>>>>>>>>> Then I changed this so that only the master made the halt status
>>>>>>>>> decision. Its trigger for testing the halt status was that the
>>>>>>>>> local
>>>>>>>>> static execution trace is longer than it was the last time that it
>>>>>>>>> tested the halt status.
>>>>>>>>
>>>>>>>> The key is that the system needs to be setup so that each of the
>>>>>>>> 'slave'
>>>>>>>> H's would also generate that exact same answer if the outer copy
>>>>>>>> (and
>>>>>>>> just that copy) is modified to not abort to allow the testing of it
>>>>>>>> being right in deciding to abort.
>>>>>>>>
>>>>>>>
>>>>>>> The inner and outer generate the exact same answer. The inner
>>>>>>> used to
>>>>>>> generate the answer and now the outer generates the same answer.
>>>>>>> If I
>>>>>>> don't force it to decide at a certain point then the inner one that
>>>>>>> reports that its input never halts is the one that has reached the
>>>>>>> deepest recursion depth and thus sees more of the execution trace
>>>>>>> before
>>>>>>> the other ones.
>>>>>>
>>>>>> So, you are admitting that the slave H WILL return the Non-Halting
>>>>>> answer in finite time and thus the H^ that called it was NOT in
>>>>>> infinite
>>>>>> recursion and does itself Halt in finite time?
>>>>>>
>>>>>
>>>>> There is no H^. This is only the C/x86 code that has H1/H.
>>>>
>>>> If you have no code that matches the H^ in the Linz proof, then you
>>>> aren't talking about it.
>>>>
>>>> You, for some strange reason, see to want to call this P.
>>>>
>>>> The fact that you don't seem to understand the ^ operator of Linz makes
>>>> me wonder how much you actually understand what the proof is talking
>>>> about.
>>>>
>>>>
>>>>>
>>>>>> THAT is the implication that the slave H will behave exactly the
>>>>>> same as
>>>>>> the master.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>> This means that since the 'master' H(P,P) returns non-halting,
>>>>>>>>>> that
>>>>>>>>>> must
>>>>>>>>>> be consistent with the copy of H inside P ALSO return the
>>>>>>>>>> answer of
>>>>>>>>>> non-halting when given that exact same input.
>>>>>>>>>>
>>>>>>>>>> The 'assumption' that it will not return is a violation of that.
>>>>>>>>>>
>>>>>>>>>> Either H is using unsound logic, or H is not a computation
>>>>>>>>>> because
>>>>>>>>>> the
>>>>>>>>>> 'slave' H doesn't behave the same way.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Presence of things like static local variables don't by
>>>>>>>>>>>> themselves
>>>>>>>>>>>> invalidate you ability to be a Computation, but do mean you
>>>>>>>>>>>> really do
>>>>>>>>>>>> need to show that it is one.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That is great. What are the requirements of a computation?
>>>>>>>>>>>
>>>>>>>>>>> given an input of the function domain it can return the
>>>>>>>>>>> corresponding
>>>>>>>>>>> output. https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>>
>>>>>>>>>> It is a bit more that a function with a specific value for a
>>>>>>>>>> specific
>>>>>>>>>> input, as it also needs to be the results of an 'algorithm', a
>>>>>>>>>> step by
>>>>>>>>>> step listing of instructions to get to the result.
>>>>>>>>>>
>>>>>>>>>> If all of the inputs to the algorithm are part of the formal
>>>>>>>>>> input to
>>>>>>>>>> the function, then you get a computation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Formal input is typically restricted to input parameters.
>>>>>>>>> The use of the static local execution_trace is to store
>>>>>>>>> intermediate
>>>>>>>>> results that are derived on the basis of the input parameters.
>>>>>>>>
>>>>>>>> Watch out, input parameters are for THAT INSTANCE, so a slave
>>>>>>>> instance
>>>>>>>> can't act differently (as far as its caller can tell) just because
>>>>>>>> it is
>>>>>>>> a slave instance.
>>>>>>>
>>>>>>> Yet in this case that is simply factually incorrect. The deeper
>>>>>>> that the
>>>>>>> recursive simulation goes the longer the execution trace becomes. As
>>>>>>> soon as the execution trace is long enough to match an infinitely
>>>>>>> repeating pattern simulation is aborted.
>>>>>>>
>>>>>>> Without a static local variable it is impossible for the halt
>>>>>>> decider to
>>>>>>> see that it has ever been invoked more than once. Without a static
>>>>>>> local
>>>>>>> variable every time that it is invoked its execution trace is
>>>>>>> emptied.
>>>>>>
>>>>>> Again, it isn't the fact that the static local variable exist that
>>>>>> causes the problem, but EVERY copy of the decider needs to act
>>>>>> exactly
>>>>>> the same to its caller when provided the exact same inputs.
>>>>>>
>>>>>> So the slave Hs need to be able and considered to abort their own
>>>>>> simulations just like the master did, and thus reveal that the master
>>>>>> was in error in assuming they would not.
>>>>>>
>>>>>
>>>>> The way that it originally worked was that the first recursive
>>>>> simulation of H that saw P called H twice in a row was the one that
>>>>> aborted the simulation.
>>>>
>>>>
>>>> 'Aborting the simulation' as in aborting the whole operation makes H
>>>> not
>>>> a proper halt decider, unless H^ was built as a seperate program that
>>>> exec'ed the decider to get the answer, but I don't think your simulator
>>>> can handle that case.
>>>>
>>>> You NEED for the outer H to return the answer.
>>>
>>> That is why I changed it so that it does it that way now.
>>>
>>>>
>>>>>
>>>>>>>
>>>>>>>> Remember each instance represents its own computation,
>>>>>>>> and that computation must generate that same answer for the same
>>>>>>>> inputs.
>>>>>>>>
>>>>>>>
>>>>>>> That seems to mean that every function called in infinite
>>>>>>> recursion is
>>>>>>> not allowed to keep track that it was called in infinite recursion.
>>>>>>
>>>>>> No, it does not say that. Since every level of the decider WILL abort
>>>>>> its simulation in a finite amount of time, there NEVER WAS an
>>>>>> infinite
>>>>>> recursion at any point.
>>>>>>
>>>>>
>>>>> This is the part that is over your head.
>>>>> It took me at least three days to understand this myself.
>>>>>
>>>>> Unless the first H that sees the infinite behavior aborts its
>>>>> simulation
>>>>> no H ever aborts its simulation.
>>>>
>>>>
>>>> WRONG. Your are doing your logic backwards.
>>>>
>>>> The algorithm for H has to be determined FIRST.
>>>>
>>>> Once this is established then either H WILL abort H^(H^) or H will not
>>>> abort H^*H^).
>>>>
>>>> If H doesn't abort H^(H^) then H will never answer the question
>>>> H(H^,H^)
>>>>
>>>> If H does abort H^(H^) then there is NO infinite behavior in the system
>>>> at all, BECAUSE H will abort it in finite time and H needs to take that
>>>> behavior of the copies of H it is simulating into account.
>>>>
>>>
>>> There is Olcott H1/H/P and Linz H/Ĥ
>>> Whenever I am talking about Ĥ I am only taling about Linz.
>>
>>
>> And your H1/H show that either H1/H are two different computations, and
>> thus H1 is NOT the H that disprove Linz, or H1/H isn't actually a
>> computation and thus doesn't disprove Linz.
>>
>> FAIL.
>
> My H1/H are the same two different computations that the Linz H/Ĥ are.

NO!!!

Olcott H is NOT Linz H^, Your H is only the piece of Linz H^ that is
supposed to be the copy of Linz H.

FAIL.

>
> Olcott H1 does not have pathological self reference
> Olcott H has pathological self referenceLinz H
>
> Linz H does not have pathological self reference
> Linz Ĥ has pathological self reference

Linz H^ does NOT have ANY self-reference in the machince itself. H^ only
references the machine H, no self-reference at all.

The Computation H^(<H^>) isn't even really a self-reference, as <H^>
does NOT have any definition of 'self' in it, it is NOT refering to the
machine it is applied to. It is just a representation of a Machine, a
perfectly normal sort of input.

Note, Turing Machine are incapable of actually providing a
'self-reference' on the tape for the machine.

>>
>>>
>>>> Anytime you use logic postulating over different version of H, you are
>>>> likely doing it wrong.
>>>>
>>>>>
>>>>> It it like being stuck in an infinite loop where you keep saying that
>>>>> you will mow the lawn tomorrow. When tomorrow arrives you will
>>>>> still mow
>>>>> the law tomorrow yet now tomorrow refers to a different day.
>>>>
>>>>
>>>> Right, but that isn't the case here. STRAWMAN.
>>>>
>>>> EVERY H will abort its simulation after a finite amount of work, and
>>>
>>> No H ever aborts any simulation of its input unless this input is
>>> aborted at a fixed number of recursive simulations. I set this limit at
>>> the smallest number of 2.
>>
>> You need to define what you H does. PERIOD. This 'No H' is just proving
>> the point
>>
>> If H doesn't abort, then H doesn't answer and fails.
>>
>
> Olcott H aborts the simulation of its input as soon as its input calls H
> exactly two times.

Ok, so the computation P(<P>) that it is simulating, when run as an
independent machine also Halts, showing that H's decision to call the
input a representation of a non-halting machine wrong.

If H does abort its simulation, you aren't in THIS case but the one
below that you seem to ignore.

>
>> If H does abort, H^/P Halts and H is wrong.
>>
>> It doesn't matter WHY H^/P Halts, just that it does.
>>
>> FAIL
>>
>>>
>>> If H keeps waiting for the next H to abort the simulation of its input
>>> that it like you saying that you will mow the lawn tomorrow every single
>>> day.
>>
>> Yes, and that version of H never answers, so it is wrong.
>>
>>>
>>> On Tuesday you say tommorow, then on Wednesday you say tomorrow...
>>>
>>> When I say exact two iterations on Tuesday I am saying that the lawn
>>> will be mowed on Wednesday. As soon as Wednesday gets here (exactly two
>>> recursive simulations) it is now time to mow the lawn (abort the input).
>>>
>>>
>>
>> And for the H that does abort, there never was an infinite execution so
>> H^/P is halting.
>>
>> Again, it doesn't matter WHY H^/P end up halting, the fact that it does
>> means that it is halting.
>>
>> The trace pattern that H calls as the proof of non-halting behavior is
>> identical to the piece of the trace of H^/P that halted, thus calling it
>> proof of non-halting is incorrect.
>>
>
>