On 3/8/2024 10:35 AM, immibis wrote:
> On 8/03/24 17:23, olcott wrote:
>> On 3/8/2024 10:17 AM, immibis wrote:
>>> On 8/03/24 03:16, olcott wrote:
>>>> On 3/7/2024 7:37 PM, immibis wrote:
>>>>> On 8/03/24 00:04, olcott wrote:
>>>>>> On 3/7/2024 4:21 PM, Richard Damon wrote:
>>>>>>> On 3/7/24 12:20 PM, olcott wrote:
>>>>>>>> On 3/7/2024 1:59 PM, Richard Damon wrote:
>>>>>>>>> On 3/6/24 11:11 PM, olcott wrote:
>>>>>>>>>> On 3/7/2024 12:37 AM, Richard Damon wrote:
>>>>>>>>>>> On 3/6/24 10:17 PM, olcott wrote:
>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn     // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>> does not halt
>>>>>>>>>>>>
>>>>>>>>>>>> The design of Olcott Machines makes quite easy for Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>> to get its abort criteria.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Which doesn't match the Halting Problem requirements,
>>>>>>>>>>
>>>>>>>>>> It does match the Halting Problem requirements, when
>>>>>>>>>> they are implemented indirectly as "abort criteria".
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Which is a different criteria, so you are just admitting that
>>>>>>>>> you are using a strawman desception and thus INTENTIONALLY LYING.
>>>>>>>>>
>>>>>>>>> Somehow you think lies are ok if they help you prove your false
>>>>>>>>> statements.
>>>>>>>>
>>>>>>>> The Linz second ⊢* enables H to compute any damn
>>>>>>>> thing as long as this ends up computing halting.
>>>>>>>>
>>>>>>>
>>>>>>> Note quite, it is whatever the algorithm for H generates.
>>>>>>>
>>>>>>> That exact same algorithm exists in H^.H, so that WILL get the
>>>>>>> same answer, and since you logic says it doesn't, that means you
>>>>>>> are lying that H^ was built by the specification, or as to what H
>>>>>>> will actually do.
>>>>>>
>>>>>> *Already addressed in my reply to you here*
>>>>>> We finally know exactly how H1(D,D) derives a different result
>>>>>> than H(D,D)
>>>>>>
>>>>>
>>>>> We know it's because H and H1 are different programs, not copies.
>>>>
>>>> *Even when we remove the infinite loop appended to Ĥ.Hqy*
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy // Ĥ applied to ⟨Ĥ⟩ halts
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>>
>>>> An Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> could trivially determine
>>>> that it is calling itself in recursive simulation.
>>>>
>>>> and Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> could trivially determine
>>>> that it is NOT calling itself in recursive simulation.
>>>>
>>>> This is true even when the embedded portion of H is
>>>> identical to <H>.
>>>>
>>>
>>> The copy of
>>>    H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>> is not
>>>    Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ>
>>>
>>> it is actually
>>>    Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>
>>> this is easily done by deleting <Ĥ> from the tape and inserting <H>
>>>
>>
>> Because my cancer came back too quickly (in less than 24 months)
>> I can't afford the time to diverge from Linz until I have closure
>> on Linz. I am on year 4.2 of a 50% five year mortality rate.
>
> Here is the closure on Linz: It does not apply to Olcott machines
> because it is only a proof about Turing machines. For Olcott machines
> you need a different proof.

I am working on the computability of the halting problem
(the exact same TMD / input pairs) by a slightly augmented
notion of Turing machines as elaborated below:

Olcott machines are entirely comprised of a UTM + TMD and one
extra step that any UTM could perform, append the TMD to the end
of its own tape.

*Criterion Measure*
H is assumed to be a simulating termination analyzer that aborts the
simulation of any input that would cause its own non-termination and
returns NO. Otherwise H always returns YES.

A halt decider must compute halting indirectly otherwise
Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ has no basis for any answer at all.

Both Linz Ĥ.H and Linz H have their basis when computed as
Olcott machines. When they compute halting indirectly by
*Criterion Measure* then H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> also gets the correct
halt status of its input.

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn
therefore
H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ⊢* H.qy

When three people agree that this is correct we can diverge
to other aspects of this.

I cannot afford to tolerate the [change the subject] form of
rebuttal that wasted 15 years with Ben Bacarisse.

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 3/8/2024 1:47 AM, Richard Damon wrote:
> On 3/7/24 11:29 PM, olcott wrote:
>> On 3/8/2024 12:48 AM, Richard Damon wrote:
>>> On 3/7/24 10:30 PM, olcott wrote:
>>>> On 3/8/2024 12:09 AM, Richard Damon wrote:
>>>>> On 3/7/24 9:38 PM, olcott wrote:
>>>>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What are the exact steps which the exact same program
>>>>>>>>>>>>>>>>> with the exact same input uses to get two different
>>>>>>>>>>>>>>>>> results?
>>>>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H
>>>>>>>>>>>>>>>>> is not defined to do exactly the same steps as H, which
>>>>>>>>>>>>>>>>> means you failed to do the Linz procedure.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>>>>> Can I continue to simulate my input without ever
>>>>>>>>>>>>>>>> aborting it?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>>>>>> programmed to do.
>>>>>>>>>>>>
>>>>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To make the Linz proof work properly with Olcott machines,
>>>>>>>>>>>>> Ĥ should search for 4 spaces, delete its own machine
>>>>>>>>>>>>> description, and then insert the description of the
>>>>>>>>>>>>> original H. Then the Linz proof works for Olcott machines.
>>>>>>>>>>>>
>>>>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>>>>> halt decider
>>>>>>>>>>>
>>>>>>>>>>> It always gives exactly the same answer as the working one,
>>>>>>>>>>> so how is it possibly broken?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>>>> not halt
>>>>>>>>>>
>>>>>>>>>> When this is executed in an Olcott machine then
>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>>>>
>>>>>>>>> WHY?
>>>>>>>>>
>>>>>>>>> The Master UTM will not change the usage at H^.H, because that
>>>>>>>>> is just an internal state of the Machine H^
>>>>>>>>>
>>>>>>>>
>>>>>>>> The ONLY thing that the master UTM does differently is append
>>>>>>>> the TMD to the TMD's own tape.
>>>>>>>
>>>>>>> Right, so it gives H and H^ that input.
>>>>>>>
>>>>>>> H^ can erase that input and replace it.
>>>>>>>
>>>>>>>>
>>>>>>>>> At that point we have the IDENTICAL set of transitions (with
>>>>>>>>> just an equivalence mapping of state numbers) as H will have,
>>>>>>>>> and the EXACT same input as H
>>>>>>>>
>>>>>>>> it is stipulated by the definition of Olcott machines
>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>>>>
>>>>>>> Nope.
>>>>>>>
>>>>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>>>>
>>>>>> You already know that there is no such thing as sub-machines of
>>>>>> Turing machines. Turing machines have a set of states and a tape.
>>>>>> They have no sub-machines.
>>>>>
>>>>> A "Sub-Machine" of a Turing Machine is where you put a copy of
>>>>> another Turing Machine into the state space of the overall/parent
>>>>> machine,
>>>>>
>>>>> When the machine H^ reaches the state H^.H, then it encounters the
>>>>> EXACT sequence of states (after the eqivalence mapping generated
>>>>> when inserting them H's q0 -> H^.Hqo and so on)
>>>>>
>>>>> It is called a sub-machine because it acts largely as if that
>>>>> Turing Machihe "called" the equivalent Turing Machine as a
>>>>> subroutine, only the machine code was expanded "inline".
>>>>
>>>> There is no way that any conventional Turing machine can tell
>>>> that the states of another Turing machine are embedded withing it.
>>>
>>> It doesn't need to "KNOW", but it HAS THEM there.
>>>
>>> It was DESIGNED that way, so the programmer knows what he did.
>>>
>>
>> immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
>> Your words seemed to agree with this.
>
> It can't get the <H> from an external source, but can have a copy of
> that inside of it and use that to replace it.
>

On 8/03/24 18:25, olcott wrote:
> On 3/8/2024 1:47 AM, Richard Damon wrote:
>> On 3/7/24 11:29 PM, olcott wrote:
>>> On 3/8/2024 12:48 AM, Richard Damon wrote:
>>>> On 3/7/24 10:30 PM, olcott wrote:
>>>>> On 3/8/2024 12:09 AM, Richard Damon wrote:
>>>>>> On 3/7/24 9:38 PM, olcott wrote:
>>>>>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>>>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What are the exact steps which the exact same program
>>>>>>>>>>>>>>>>>> with the exact same input uses to get two different
>>>>>>>>>>>>>>>>>> results?
>>>>>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H
>>>>>>>>>>>>>>>>>> is not defined to do exactly the same steps as H,
>>>>>>>>>>>>>>>>>> which means you failed to do the Linz procedure.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>>>>>> Can I continue to simulate my input without ever
>>>>>>>>>>>>>>>>> aborting it?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>>>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>>>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>>>>>>> programmed to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>>>>>>>>> space delimited Turing Machine input followed by four
>>>>>>>>>>>>>>> spaces.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To make the Linz proof work properly with Olcott machines,
>>>>>>>>>>>>>> Ĥ should search for 4 spaces, delete its own machine
>>>>>>>>>>>>>> description, and then insert the description of the
>>>>>>>>>>>>>> original H. Then the Linz proof works for Olcott machines.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>
>>>>>>>>>>>> It always gives exactly the same answer as the working one,
>>>>>>>>>>>> so how is it possibly broken?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>>>>> not halt
>>>>>>>>>>>
>>>>>>>>>>> When this is executed in an Olcott machine then
>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>>>>>
>>>>>>>>>> WHY?
>>>>>>>>>>
>>>>>>>>>> The Master UTM will not change the usage at H^.H, because that
>>>>>>>>>> is just an internal state of the Machine H^
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The ONLY thing that the master UTM does differently is append
>>>>>>>>> the TMD to the TMD's own tape.
>>>>>>>>
>>>>>>>> Right, so it gives H and H^ that input.
>>>>>>>>
>>>>>>>> H^ can erase that input and replace it.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> At that point we have the IDENTICAL set of transitions (with
>>>>>>>>>> just an equivalence mapping of state numbers) as H will have,
>>>>>>>>>> and the EXACT same input as H
>>>>>>>>>
>>>>>>>>> it is stipulated by the definition of Olcott machines
>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>>>>>
>>>>>>>> Nope.
>>>>>>>>
>>>>>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>>>>>
>>>>>>> You already know that there is no such thing as sub-machines of
>>>>>>> Turing machines. Turing machines have a set of states and a tape.
>>>>>>> They have no sub-machines.
>>>>>>
>>>>>> A "Sub-Machine" of a Turing Machine is where you put a copy of
>>>>>> another Turing Machine into the state space of the overall/parent
>>>>>> machine,
>>>>>>
>>>>>> When the machine H^ reaches the state H^.H, then it encounters the
>>>>>> EXACT sequence of states (after the eqivalence mapping generated
>>>>>> when inserting them H's q0 -> H^.Hqo and so on)
>>>>>>
>>>>>> It is called a sub-machine because it acts largely as if that
>>>>>> Turing Machihe "called" the equivalent Turing Machine as a
>>>>>> subroutine, only the machine code was expanded "inline".
>>>>>
>>>>> There is no way that any conventional Turing machine can tell
>>>>> that the states of another Turing machine are embedded withing it.
>>>>
>>>> It doesn't need to "KNOW", but it HAS THEM there.
>>>>
>>>> It was DESIGNED that way, so the programmer knows what he did.
>>>>
>>>
>>> immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
>>> Your words seemed to agree with this.
>>
>> It can't get the <H> from an external source, but can have a copy of
>> that inside of it and use that to replace it.
>>
>
> Not unless it is yet another parameter, thus diverges
> too far from the original Linz.

On 3/8/2024 11:57 AM, immibis wrote:
> On 8/03/24 18:25, olcott wrote:
>> On 3/8/2024 1:47 AM, Richard Damon wrote:
>>> On 3/7/24 11:29 PM, olcott wrote:
>>>> On 3/8/2024 12:48 AM, Richard Damon wrote:
>>>>> On 3/7/24 10:30 PM, olcott wrote:
>>>>>> On 3/8/2024 12:09 AM, Richard Damon wrote:
>>>>>>> On 3/7/24 9:38 PM, olcott wrote:
>>>>>>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>>>>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>>>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What are the exact steps which the exact same program
>>>>>>>>>>>>>>>>>>> with the exact same input uses to get two different
>>>>>>>>>>>>>>>>>>> results?
>>>>>>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because
>>>>>>>>>>>>>>>>>>> Ĥ.H is not defined to do exactly the same steps as H,
>>>>>>>>>>>>>>>>>>> which means you failed to do the Linz procedure.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>>>>>>> Can I continue to simulate my input without ever
>>>>>>>>>>>>>>>>>> aborting it?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or
>>>>>>>>>>>>>>>>> Turing machines). They execute instructions (or
>>>>>>>>>>>>>>>>> transitions) in sequence, determined by their
>>>>>>>>>>>>>>>>> programming and their input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>>>>>>>> programmed to do.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>>>>>>> conventional UTM's combined with Conventional Turing
>>>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>>>>>>>>>> space delimited Turing Machine input followed by four
>>>>>>>>>>>>>>>> spaces.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To make the Linz proof work properly with Olcott
>>>>>>>>>>>>>>> machines, Ĥ should search for 4 spaces, delete its own
>>>>>>>>>>>>>>> machine description, and then insert the description of
>>>>>>>>>>>>>>> the original H. Then the Linz proof works for Olcott
>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>
>>>>>>>>>>>>> It always gives exactly the same answer as the working one,
>>>>>>>>>>>>> so how is it possibly broken?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>> does not halt
>>>>>>>>>>>>
>>>>>>>>>>>> When this is executed in an Olcott machine then
>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>>>>>>
>>>>>>>>>>> WHY?
>>>>>>>>>>>
>>>>>>>>>>> The Master UTM will not change the usage at H^.H, because
>>>>>>>>>>> that is just an internal state of the Machine H^
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The ONLY thing that the master UTM does differently is append
>>>>>>>>>> the TMD to the TMD's own tape.
>>>>>>>>>
>>>>>>>>> Right, so it gives H and H^ that input.
>>>>>>>>>
>>>>>>>>> H^ can erase that input and replace it.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> At that point we have the IDENTICAL set of transitions (with
>>>>>>>>>>> just an equivalence mapping of state numbers) as H will have,
>>>>>>>>>>> and the EXACT same input as H
>>>>>>>>>>
>>>>>>>>>> it is stipulated by the definition of Olcott machines
>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>>>>>>
>>>>>>>>> Nope.
>>>>>>>>>
>>>>>>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>>>>>>
>>>>>>>> You already know that there is no such thing as sub-machines of
>>>>>>>> Turing machines. Turing machines have a set of states and a tape.
>>>>>>>> They have no sub-machines.
>>>>>>>
>>>>>>> A "Sub-Machine" of a Turing Machine is where you put a copy of
>>>>>>> another Turing Machine into the state space of the overall/parent
>>>>>>> machine,
>>>>>>>
>>>>>>> When the machine H^ reaches the state H^.H, then it encounters
>>>>>>> the EXACT sequence of states (after the eqivalence mapping
>>>>>>> generated when inserting them H's q0 -> H^.Hqo and so on)
>>>>>>>
>>>>>>> It is called a sub-machine because it acts largely as if that
>>>>>>> Turing Machihe "called" the equivalent Turing Machine as a
>>>>>>> subroutine, only the machine code was expanded "inline".
>>>>>>
>>>>>> There is no way that any conventional Turing machine can tell
>>>>>> that the states of another Turing machine are embedded withing it.
>>>>>
>>>>> It doesn't need to "KNOW", but it HAS THEM there.
>>>>>
>>>>> It was DESIGNED that way, so the programmer knows what he did.
>>>>>
>>>>
>>>> immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
>>>> Your words seemed to agree with this.
>>>
>>> It can't get the <H> from an external source, but can have a copy of
>>> that inside of it and use that to replace it.
>>>
>>
>> Not unless it is yet another parameter, thus diverges
>> too far from the original Linz.
>
> Why can't a Turing machine write the finite string <H> onto its own tape?

On 3/8/24 9:25 AM, olcott wrote:
> On 3/8/2024 1:47 AM, Richard Damon wrote:
>> On 3/7/24 11:29 PM, olcott wrote:
>>> On 3/8/2024 12:48 AM, Richard Damon wrote:
>>>> On 3/7/24 10:30 PM, olcott wrote:
>>>>> On 3/8/2024 12:09 AM, Richard Damon wrote:
>>>>>> On 3/7/24 9:38 PM, olcott wrote:
>>>>>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>>>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What are the exact steps which the exact same program
>>>>>>>>>>>>>>>>>> with the exact same input uses to get two different
>>>>>>>>>>>>>>>>>> results?
>>>>>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H
>>>>>>>>>>>>>>>>>> is not defined to do exactly the same steps as H,
>>>>>>>>>>>>>>>>>> which means you failed to do the Linz procedure.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>>>>>> Can I continue to simulate my input without ever
>>>>>>>>>>>>>>>>> aborting it?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing
>>>>>>>>>>>>>>>> machines). They execute instructions (or transitions) in
>>>>>>>>>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>>>>>>> programmed to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>>>>>>>>> space delimited Turing Machine input followed by four
>>>>>>>>>>>>>>> spaces.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To make the Linz proof work properly with Olcott machines,
>>>>>>>>>>>>>> Ĥ should search for 4 spaces, delete its own machine
>>>>>>>>>>>>>> description, and then insert the description of the
>>>>>>>>>>>>>> original H. Then the Linz proof works for Olcott machines.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>
>>>>>>>>>>>> It always gives exactly the same answer as the working one,
>>>>>>>>>>>> so how is it possibly broken?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does
>>>>>>>>>>> not halt
>>>>>>>>>>>
>>>>>>>>>>> When this is executed in an Olcott machine then
>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>>>>>
>>>>>>>>>> WHY?
>>>>>>>>>>
>>>>>>>>>> The Master UTM will not change the usage at H^.H, because that
>>>>>>>>>> is just an internal state of the Machine H^
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The ONLY thing that the master UTM does differently is append
>>>>>>>>> the TMD to the TMD's own tape.
>>>>>>>>
>>>>>>>> Right, so it gives H and H^ that input.
>>>>>>>>
>>>>>>>> H^ can erase that input and replace it.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> At that point we have the IDENTICAL set of transitions (with
>>>>>>>>>> just an equivalence mapping of state numbers) as H will have,
>>>>>>>>>> and the EXACT same input as H
>>>>>>>>>
>>>>>>>>> it is stipulated by the definition of Olcott machines
>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>>>>>
>>>>>>>> Nope.
>>>>>>>>
>>>>>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>>>>>
>>>>>>> You already know that there is no such thing as sub-machines of
>>>>>>> Turing machines. Turing machines have a set of states and a tape.
>>>>>>> They have no sub-machines.
>>>>>>
>>>>>> A "Sub-Machine" of a Turing Machine is where you put a copy of
>>>>>> another Turing Machine into the state space of the overall/parent
>>>>>> machine,
>>>>>>
>>>>>> When the machine H^ reaches the state H^.H, then it encounters the
>>>>>> EXACT sequence of states (after the eqivalence mapping generated
>>>>>> when inserting them H's q0 -> H^.Hqo and so on)
>>>>>>
>>>>>> It is called a sub-machine because it acts largely as if that
>>>>>> Turing Machihe "called" the equivalent Turing Machine as a
>>>>>> subroutine, only the machine code was expanded "inline".
>>>>>
>>>>> There is no way that any conventional Turing machine can tell
>>>>> that the states of another Turing machine are embedded withing it.
>>>>
>>>> It doesn't need to "KNOW", but it HAS THEM there.
>>>>
>>>> It was DESIGNED that way, so the programmer knows what he did.
>>>>
>>>
>>> immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
>>> Your words seemed to agree with this.
>>
>> It can't get the <H> from an external source, but can have a copy of
>> that inside of it and use that to replace it.
>>
>
> Not unless it is yet another parameter, thus diverges
> too far from the original Linz.

On 3/8/24 8:15 AM, olcott wrote:
> On 3/8/2024 10:09 AM, immibis wrote:
>> On 8/03/24 07:30, olcott wrote:
>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
>>> copy of itself with a copy of its own input thus immediately
>>> detects recursive simulation just like H(D,D).
>>>
>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> immediately detects that is NOT about to simulate a
>>> copy of itself with a copy of its own input thus immediately
>>> rejects recursive simulation just like H1(D,D).
>>
>> And what about Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ?
>>
>
> Let's first determine that Olcott machines refute
> the uncomputability of the Peter Linz ⟨Ĥ⟩ ⟨Ĥ⟩.

You don't understand what uncomputability means.

it doesn't mean a praticlur computation with a particular input, but
that no machine can compute the values for ALL inputs.

A given specific input, you can ALWAYS produce a machine that gives the
right result (if you know the result) as you can just make a machine
that spits out that answer.

The problem is making a single machine that answers ALL possible inputs.

Thus it is the HALTING FUNCTION that is uncomputable, not the Halting
Behavior of a particular machine.

>
> Because my cancer came back in less than 24 months that
> means I don't have time for endless divergence.
>

So, it sounds like you are going to die with the reputation of being a
pathetic ignorant hypocritical pathological lying idiot unless you
change your methods.

You might want to think about that.

On 3/8/24 10:12 AM, olcott wrote:
> On 3/8/2024 11:57 AM, immibis wrote:
>> On 8/03/24 18:25, olcott wrote:
>>> On 3/8/2024 1:47 AM, Richard Damon wrote:
>>>> On 3/7/24 11:29 PM, olcott wrote:
>>>>> On 3/8/2024 12:48 AM, Richard Damon wrote:
>>>>>> On 3/7/24 10:30 PM, olcott wrote:
>>>>>>> On 3/8/2024 12:09 AM, Richard Damon wrote:
>>>>>>>> On 3/7/24 9:38 PM, olcott wrote:
>>>>>>>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>>>>>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>>>>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>>>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What are the exact steps which the exact same
>>>>>>>>>>>>>>>>>>>> program with the exact same input uses to get two
>>>>>>>>>>>>>>>>>>>> different results?
>>>>>>>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because
>>>>>>>>>>>>>>>>>>>> Ĥ.H is not defined to do exactly the same steps as
>>>>>>>>>>>>>>>>>>>> H, which means you failed to do the Linz procedure.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>>>>>>>> Can I continue to simulate my input without ever
>>>>>>>>>>>>>>>>>>> aborting it?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or
>>>>>>>>>>>>>>>>>> Turing machines). They execute instructions (or
>>>>>>>>>>>>>>>>>> transitions) in sequence, determined by their
>>>>>>>>>>>>>>>>>> programming and their input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>>>>>>>>> programmed to do.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>>>>>>>> conventional UTM's combined with Conventional Turing
>>>>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The input to Olcott machines can simply be the
>>>>>>>>>>>>>>>>> conventional
>>>>>>>>>>>>>>>>> space delimited Turing Machine input followed by four
>>>>>>>>>>>>>>>>> spaces.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To make the Linz proof work properly with Olcott
>>>>>>>>>>>>>>>> machines, Ĥ should search for 4 spaces, delete its own
>>>>>>>>>>>>>>>> machine description, and then insert the description of
>>>>>>>>>>>>>>>> the original H. Then the Linz proof works for Olcott
>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It always gives exactly the same answer as the working
>>>>>>>>>>>>>> one, so how is it possibly broken?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>> does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>>> When this is executed in an Olcott machine then
>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>>>>>>>
>>>>>>>>>>>> WHY?
>>>>>>>>>>>>
>>>>>>>>>>>> The Master UTM will not change the usage at H^.H, because
>>>>>>>>>>>> that is just an internal state of the Machine H^
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The ONLY thing that the master UTM does differently is append
>>>>>>>>>>> the TMD to the TMD's own tape.
>>>>>>>>>>
>>>>>>>>>> Right, so it gives H and H^ that input.
>>>>>>>>>>
>>>>>>>>>> H^ can erase that input and replace it.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> At that point we have the IDENTICAL set of transitions (with
>>>>>>>>>>>> just an equivalence mapping of state numbers) as H will
>>>>>>>>>>>> have, and the EXACT same input as H
>>>>>>>>>>>
>>>>>>>>>>> it is stipulated by the definition of Olcott machines
>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>>>>>>>
>>>>>>>>>> Nope.
>>>>>>>>>>
>>>>>>>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>>>>>>>
>>>>>>>>> You already know that there is no such thing as sub-machines of
>>>>>>>>> Turing machines. Turing machines have a set of states and a tape.
>>>>>>>>> They have no sub-machines.
>>>>>>>>
>>>>>>>> A "Sub-Machine" of a Turing Machine is where you put a copy of
>>>>>>>> another Turing Machine into the state space of the
>>>>>>>> overall/parent machine,
>>>>>>>>
>>>>>>>> When the machine H^ reaches the state H^.H, then it encounters
>>>>>>>> the EXACT sequence of states (after the eqivalence mapping
>>>>>>>> generated when inserting them H's q0 -> H^.Hqo and so on)
>>>>>>>>
>>>>>>>> It is called a sub-machine because it acts largely as if that
>>>>>>>> Turing Machihe "called" the equivalent Turing Machine as a
>>>>>>>> subroutine, only the machine code was expanded "inline".
>>>>>>>
>>>>>>> There is no way that any conventional Turing machine can tell
>>>>>>> that the states of another Turing machine are embedded withing it.
>>>>>>
>>>>>> It doesn't need to "KNOW", but it HAS THEM there.
>>>>>>
>>>>>> It was DESIGNED that way, so the programmer knows what he did.
>>>>>>
>>>>>
>>>>> immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
>>>>> Your words seemed to agree with this.
>>>>
>>>> It can't get the <H> from an external source, but can have a copy of
>>>> that inside of it and use that to replace it.
>>>>
>>>
>>> Not unless it is yet another parameter, thus diverges
>>> too far from the original Linz.
>>
>> Why can't a Turing machine write the finite string <H> onto its own tape?
>
> Unless it is an extra parameter it has no basis for doing this.
> If it is an extra parameter then it is no longer the Linz proof.
>

On 3/8/24 8:29 AM, olcott wrote:
> On 3/8/2024 10:18 AM, immibis wrote:
>> On 8/03/24 17:15, olcott wrote:
>>> On 3/8/2024 10:09 AM, immibis wrote:
>>>> On 8/03/24 07:30, olcott wrote:
>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> immediately detects that is about to simulate a
>>>>> copy of itself with a copy of its own input thus immediately
>>>>> detects recursive simulation just like H(D,D).
>>>>>
>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> immediately detects that is NOT about to simulate a
>>>>> copy of itself with a copy of its own input thus immediately
>>>>> rejects recursive simulation just like H1(D,D).
>>>>
>>>> And what about Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ?
>>>>
>>>
>>> Let's first determine that Olcott machines refute
>>> the uncomputability of the Peter Linz ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> Peter Linz Ĥ ⟨Ĥ⟩ is a Turing machine. The exact same proof does not
>> work for Olcott machines because they are different. A different proof
>> proves that Olcott machines cannot compute the halting problem. I have
>> already told you this proof (but not in great detail).
>
> I am working on the computability of the halting problem
> (the exact same TMD / input pairs) by a slightly augmented
> notion of Turing machines as elaborated below:
>
> Olcott machines are entirely comprised of a UTM + TMD and one
> extra step that any UTM could perform, append the TMD to the end
> of its own tape.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn
> therefore
> H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ⊢* H.qy
>
> Olcott machines take Turing Machine Descriptions.
> Thus an Olcott machine does compute halting for
> the Linz H ⟨Ĥ⟩ ⟨Ĥ⟩.

Nope, because no ALGORITH always gets the right answer for every
Computation inputted.

ANY of your H's can have an H^ built on THAT PARTICULAR H, which will
act in the contrary manner to what THAT H answers.

Doesn't matter that some other version with a different address get it
right, if you don't know which address of H you need to use to get the
right answer, it doesn't help, thus ALL need to give the right answer.

Otherwise, just having two machine one that says "Halting" to all
inputs, and one that says "Non-Halting" to all inputs would be a
solution, you just need to ask the right one, but that requires a true
halting decider to tell you which one to ask, so you get into a circle.

That was one of your earlier problems, you Halting decider needed a
Halting decider for it to use to decide to abort it simulation.

>
>>>
>>> Because my cancer came back in less than 24 months that
>>> means I don't have time for endless divergence.
>>>
>> Then why do you keep doing it?
>
> You are the one diverging here.
>

On 3/8/24 9:22 AM, olcott wrote:
> On 3/8/2024 10:35 AM, immibis wrote:
>> On 8/03/24 17:23, olcott wrote:
>>> On 3/8/2024 10:17 AM, immibis wrote:
>>>> On 8/03/24 03:16, olcott wrote:
>>>>> On 3/7/2024 7:37 PM, immibis wrote:
>>>>>> On 8/03/24 00:04, olcott wrote:
>>>>>>> On 3/7/2024 4:21 PM, Richard Damon wrote:
>>>>>>>> On 3/7/24 12:20 PM, olcott wrote:
>>>>>>>>> On 3/7/2024 1:59 PM, Richard Damon wrote:
>>>>>>>>>> On 3/6/24 11:11 PM, olcott wrote:
>>>>>>>>>>> On 3/7/2024 12:37 AM, Richard Damon wrote:
>>>>>>>>>>>> On 3/6/24 10:17 PM, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn     // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>> does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>>> The design of Olcott Machines makes quite easy for Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>> to get its abort criteria.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Which doesn't match the Halting Problem requirements,
>>>>>>>>>>>
>>>>>>>>>>> It does match the Halting Problem requirements, when
>>>>>>>>>>> they are implemented indirectly as "abort criteria".
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Which is a different criteria, so you are just admitting that
>>>>>>>>>> you are using a strawman desception and thus INTENTIONALLY LYING.
>>>>>>>>>>
>>>>>>>>>> Somehow you think lies are ok if they help you prove your
>>>>>>>>>> false statements.
>>>>>>>>>
>>>>>>>>> The Linz second ⊢* enables H to compute any damn
>>>>>>>>> thing as long as this ends up computing halting.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Note quite, it is whatever the algorithm for H generates.
>>>>>>>>
>>>>>>>> That exact same algorithm exists in H^.H, so that WILL get the
>>>>>>>> same answer, and since you logic says it doesn't, that means you
>>>>>>>> are lying that H^ was built by the specification, or as to what
>>>>>>>> H will actually do.
>>>>>>>
>>>>>>> *Already addressed in my reply to you here*
>>>>>>> We finally know exactly how H1(D,D) derives a different result
>>>>>>> than H(D,D)
>>>>>>>
>>>>>>
>>>>>> We know it's because H and H1 are different programs, not copies.
>>>>>
>>>>> *Even when we remove the infinite loop appended to Ĥ.Hqy*
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy // Ĥ applied to ⟨Ĥ⟩ halts
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>>>
>>>>> An Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> could trivially determine
>>>>> that it is calling itself in recursive simulation.
>>>>>
>>>>> and Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> could trivially determine
>>>>> that it is NOT calling itself in recursive simulation.
>>>>>
>>>>> This is true even when the embedded portion of H is
>>>>> identical to <H>.
>>>>>
>>>>
>>>> The copy of
>>>>    H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>> is not
>>>>    Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ>
>>>>
>>>> it is actually
>>>>    Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>
>>>> this is easily done by deleting <Ĥ> from the tape and inserting <H>
>>>>
>>>
>>> Because my cancer came back too quickly (in less than 24 months)
>>> I can't afford the time to diverge from Linz until I have closure
>>> on Linz. I am on year 4.2 of a 50% five year mortality rate.
>>
>> Here is the closure on Linz: It does not apply to Olcott machines
>> because it is only a proof about Turing machines. For Olcott machines
>> you need a different proof.
>
> I am working on the computability of the halting problem
> (the exact same TMD / input pairs) by a slightly augmented
> notion of Turing machines as elaborated below:
>
> Olcott machines are entirely comprised of a UTM + TMD and one
> extra step that any UTM could perform, append the TMD to the end
> of its own tape.
>
> *Criterion Measure*
> H is assumed to be a simulating termination analyzer that aborts the
> simulation of any input that would cause its own non-termination and
> returns NO. Otherwise H always returns YES.
>
> A halt decider must compute halting indirectly otherwise
> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ has no basis for any answer at all.
>
> Both Linz Ĥ.H and Linz H have their basis when computed as
> Olcott machines. When they compute halting indirectly by
> *Criterion Measure* then H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> also gets the correct
> halt status of its input.
>
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn
> therefore
> H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> ⊢* H.qy
>
> When three people agree that this is correct we can diverge
> to other aspects of this.
>
> I cannot afford to tolerate the [change the subject] form of
> rebuttal that wasted 15 years with Ben Bacarisse.
>
>

In other words, you have decided to continue your insanity of going down
paths you don't understand to waste the rest of you life.

I suspect that you will be assigned the task of continuing that work in
the after-life with an AI that is programmed to be smarter than you
giving you the refuations that you still will not understand for eternity.

On 8/03/24 19:12, olcott wrote:
> On 3/8/2024 11:57 AM, immibis wrote:
>> On 8/03/24 18:25, olcott wrote:
>>> On 3/8/2024 1:47 AM, Richard Damon wrote:
>>>> On 3/7/24 11:29 PM, olcott wrote:
>>>>> On 3/8/2024 12:48 AM, Richard Damon wrote:
>>>>>> On 3/7/24 10:30 PM, olcott wrote:
>>>>>>> On 3/8/2024 12:09 AM, Richard Damon wrote:
>>>>>>>> On 3/7/24 9:38 PM, olcott wrote:
>>>>>>>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>>>>>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>>>>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>>>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its
>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What are the exact steps which the exact same
>>>>>>>>>>>>>>>>>>>> program with the exact same input uses to get two
>>>>>>>>>>>>>>>>>>>> different results?
>>>>>>>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because
>>>>>>>>>>>>>>>>>>>> Ĥ.H is not defined to do exactly the same steps as
>>>>>>>>>>>>>>>>>>>> H, which means you failed to do the Linz procedure.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>>>>>>>> Can I continue to simulate my input without ever
>>>>>>>>>>>>>>>>>>> aborting it?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or
>>>>>>>>>>>>>>>>>> Turing machines). They execute instructions (or
>>>>>>>>>>>>>>>>>> transitions) in sequence, determined by their
>>>>>>>>>>>>>>>>>> programming and their input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> They cannot do anything except for exactly what they are
>>>>>>>>>>>>>>>> programmed to do.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>>>>>>>> conventional UTM's combined with Conventional Turing
>>>>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The input to Olcott machines can simply be the
>>>>>>>>>>>>>>>>> conventional
>>>>>>>>>>>>>>>>> space delimited Turing Machine input followed by four
>>>>>>>>>>>>>>>>> spaces.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is followed by the machine description of the machine
>>>>>>>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To make the Linz proof work properly with Olcott
>>>>>>>>>>>>>>>> machines, Ĥ should search for 4 spaces, delete its own
>>>>>>>>>>>>>>>> machine description, and then insert the description of
>>>>>>>>>>>>>>>> the original H. Then the Linz proof works for Olcott
>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It always gives exactly the same answer as the working
>>>>>>>>>>>>>> one, so how is it possibly broken?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>> does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>>> When this is executed in an Olcott machine then
>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>>>>>>>
>>>>>>>>>>>> WHY?
>>>>>>>>>>>>
>>>>>>>>>>>> The Master UTM will not change the usage at H^.H, because
>>>>>>>>>>>> that is just an internal state of the Machine H^
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The ONLY thing that the master UTM does differently is append
>>>>>>>>>>> the TMD to the TMD's own tape.
>>>>>>>>>>
>>>>>>>>>> Right, so it gives H and H^ that input.
>>>>>>>>>>
>>>>>>>>>> H^ can erase that input and replace it.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> At that point we have the IDENTICAL set of transitions (with
>>>>>>>>>>>> just an equivalence mapping of state numbers) as H will
>>>>>>>>>>>> have, and the EXACT same input as H
>>>>>>>>>>>
>>>>>>>>>>> it is stipulated by the definition of Olcott machines
>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>>>>>>>
>>>>>>>>>> Nope.
>>>>>>>>>>
>>>>>>>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>>>>>>>
>>>>>>>>> You already know that there is no such thing as sub-machines of
>>>>>>>>> Turing machines. Turing machines have a set of states and a tape.
>>>>>>>>> They have no sub-machines.
>>>>>>>>
>>>>>>>> A "Sub-Machine" of a Turing Machine is where you put a copy of
>>>>>>>> another Turing Machine into the state space of the
>>>>>>>> overall/parent machine,
>>>>>>>>
>>>>>>>> When the machine H^ reaches the state H^.H, then it encounters
>>>>>>>> the EXACT sequence of states (after the eqivalence mapping
>>>>>>>> generated when inserting them H's q0 -> H^.Hqo and so on)
>>>>>>>>
>>>>>>>> It is called a sub-machine because it acts largely as if that
>>>>>>>> Turing Machihe "called" the equivalent Turing Machine as a
>>>>>>>> subroutine, only the machine code was expanded "inline".
>>>>>>>
>>>>>>> There is no way that any conventional Turing machine can tell
>>>>>>> that the states of another Turing machine are embedded withing it.
>>>>>>
>>>>>> It doesn't need to "KNOW", but it HAS THEM there.
>>>>>>
>>>>>> It was DESIGNED that way, so the programmer knows what he did.
>>>>>>
>>>>>
>>>>> immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
>>>>> Your words seemed to agree with this.
>>>>
>>>> It can't get the <H> from an external source, but can have a copy of
>>>> that inside of it and use that to replace it.
>>>>
>>>
>>> Not unless it is yet another parameter, thus diverges
>>> too far from the original Linz.
>>
>> Why can't a Turing machine write the finite string <H> onto its own tape?
>
> Unless it is an extra parameter it has no basis for doing this.
> If it is an extra parameter then it is no longer the Linz proof.
>

On 3/8/2024 12:58 PM, immibis wrote:
> On 8/03/24 19:12, olcott wrote:
>> On 3/8/2024 11:57 AM, immibis wrote:
>>> On 8/03/24 18:25, olcott wrote:
>>>> On 3/8/2024 1:47 AM, Richard Damon wrote:
>>>>> On 3/7/24 11:29 PM, olcott wrote:
>>>>>> On 3/8/2024 12:48 AM, Richard Damon wrote:
>>>>>>> On 3/7/24 10:30 PM, olcott wrote:
>>>>>>>> On 3/8/2024 12:09 AM, Richard Damon wrote:
>>>>>>>>> On 3/7/24 9:38 PM, olcott wrote:
>>>>>>>>>> On 3/7/2024 9:53 PM, Richard Damon wrote:
>>>>>>>>>>> On 3/7/24 7:29 PM, olcott wrote:
>>>>>>>>>>>> On 3/7/2024 8:34 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 3/7/24 6:02 PM, olcott wrote:
>>>>>>>>>>>>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>>>>>>>>>>>>> On 7/03/24 18:05, olcott wrote:
>>>>>>>>>>>>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>>>>>>>>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>>>>>>>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>>>>>>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>>>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its
>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort
>>>>>>>>>>>>>>>>>>>>>> its simulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> What are the exact steps which the exact same
>>>>>>>>>>>>>>>>>>>>> program with the exact same input uses to get two
>>>>>>>>>>>>>>>>>>>>> different results?
>>>>>>>>>>>>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because
>>>>>>>>>>>>>>>>>>>>> Ĥ.H is not defined to do exactly the same steps as
>>>>>>>>>>>>>>>>>>>>> H, which means you failed to do the Linz procedure.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>>>>>>>>>>>>> Can I continue to simulate my input without ever
>>>>>>>>>>>>>>>>>>>> aborting it?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or
>>>>>>>>>>>>>>>>>>> Turing machines). They execute instructions (or
>>>>>>>>>>>>>>>>>>> transitions) in sequence, determined by their
>>>>>>>>>>>>>>>>>>> programming and their input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yet because they both know their own machine address
>>>>>>>>>>>>>>>>>> they can both correctly determine whether or not they
>>>>>>>>>>>>>>>>>> themselves are called in recursive simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> They cannot do anything except for exactly what they
>>>>>>>>>>>>>>>>> are programmed to do.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>>>>>>>>>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>>>>>>>>>>>>> aborts its simulation of D(D). H1 can see that its
>>>>>>>>>>>>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>>>>>>>>>>>> conventional UTM's combined with Conventional Turing
>>>>>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The input to Olcott machines can simply be the
>>>>>>>>>>>>>>>>>> conventional
>>>>>>>>>>>>>>>>>> space delimited Turing Machine input followed by four
>>>>>>>>>>>>>>>>>> spaces.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This is followed by the machine description of the
>>>>>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To make the Linz proof work properly with Olcott
>>>>>>>>>>>>>>>>> machines, Ĥ should search for 4 spaces, delete its own
>>>>>>>>>>>>>>>>> machine description, and then insert the description of
>>>>>>>>>>>>>>>>> the original H. Then the Linz proof works for Olcott
>>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That someone can intentionally break an otherwise correct
>>>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It always gives exactly the same answer as the working
>>>>>>>>>>>>>>> one, so how is it possibly broken?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>> halts
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>> does not halt
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When this is executed in an Olcott machine then
>>>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WHY?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Master UTM will not change the usage at H^.H, because
>>>>>>>>>>>>> that is just an internal state of the Machine H^
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The ONLY thing that the master UTM does differently is append
>>>>>>>>>>>> the TMD to the TMD's own tape.
>>>>>>>>>>>
>>>>>>>>>>> Right, so it gives H and H^ that input.
>>>>>>>>>>>
>>>>>>>>>>> H^ can erase that input and replace it.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> At that point we have the IDENTICAL set of transitions
>>>>>>>>>>>>> (with just an equivalence mapping of state numbers) as H
>>>>>>>>>>>>> will have, and the EXACT same input as H
>>>>>>>>>>>>
>>>>>>>>>>>> it is stipulated by the definition of Olcott machines
>>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)
>>>>>>>>>>>
>>>>>>>>>>> Nope.
>>>>>>>>>>>
>>>>>>>>>>> H^.H isn't a "Olcott Machine" it is a sub-machine of H^
>>>>>>>>>>
>>>>>>>>>> You already know that there is no such thing as sub-machines of
>>>>>>>>>> Turing machines. Turing machines have a set of states and a tape.
>>>>>>>>>> They have no sub-machines.
>>>>>>>>>
>>>>>>>>> A "Sub-Machine" of a Turing Machine is where you put a copy of
>>>>>>>>> another Turing Machine into the state space of the
>>>>>>>>> overall/parent machine,
>>>>>>>>>
>>>>>>>>> When the machine H^ reaches the state H^.H, then it encounters
>>>>>>>>> the EXACT sequence of states (after the eqivalence mapping
>>>>>>>>> generated when inserting them H's q0 -> H^.Hqo and so on)
>>>>>>>>>
>>>>>>>>> It is called a sub-machine because it acts largely as if that
>>>>>>>>> Turing Machihe "called" the equivalent Turing Machine as a
>>>>>>>>> subroutine, only the machine code was expanded "inline".
>>>>>>>>
>>>>>>>> There is no way that any conventional Turing machine can tell
>>>>>>>> that the states of another Turing machine are embedded withing it.
>>>>>>>
>>>>>>> It doesn't need to "KNOW", but it HAS THEM there.
>>>>>>>
>>>>>>> It was DESIGNED that way, so the programmer knows what he did.
>>>>>>>
>>>>>>
>>>>>> immibis thought that Ĥ could copy external <H> on top of internal <Ĥ>
>>>>>> Your words seemed to agree with this.
>>>>>
>>>>> It can't get the <H> from an external source, but can have a copy
>>>>> of that inside of it and use that to replace it.
>>>>>
>>>>
>>>> Not unless it is yet another parameter, thus diverges
>>>> too far from the original Linz.
>>>
>>> Why can't a Turing machine write the finite string <H> onto its own
>>> tape?
>>
>> Unless it is an extra parameter it has no basis for doing this.
>> If it is an extra parameter then it is no longer the Linz proof.
>>
>
> So it's impossible to make a Turing machine that writes 12345 onto its
> tape unless 12345 is a parameter?

On 3/8/24 11:08 AM, olcott wrote:
> On 3/8/2024 12:58 PM, immibis wrote:

>>
>> So it's impossible to make a Turing machine that writes 12345 onto its
>> tape unless 12345 is a parameter?
>
> That is a valid point.
> It is impossible to get me to talk about that until
> we first have full closure that the Linz H correctly
> determines the halt status of the Linz Ĥ ⟨Ĥ⟩ when run
> in the Olcott master UTM.
>

In other words you are going to ignore the true facts until someone
agrees to your lies.

Since it has been shown that for the PROPERLY CONSTRUCTED Linz H^ (built
by the semantic definition implemented for Olcott Machines) that Linz H
will NOT give the right answser, I guess you are deciding to DIE being
still known as the idiot.

(It becomes a bit of a Lie to try to refer to Linz's proof with Olcott
Machines since it SPECIFICALLY was talking about Turing Machines)

With the adapted definition of H^ that transforms

H^.q0 (M) <H^> |-> H^.Hq0 (M) (M) <H> to get H's answer to the machine M
and thus for the input of the description of itself it does

H^.q0 (H^) <H^> |-> H^.Hq0 (H^) (H^) <H> which will go to the same H
state as H (H^) (H^) <H> since it is the same algorithm with the same
input, and then Hqy loops forevern and Hqn Halts, we see that H can not
get the right answer.

When we look even farther at your description, we see that H, since its
first parameter doesn't match it given self description, not even a
sub-string of it (since the state number would have gotten remapped), so
H doesn't abort it's simulation.

Also H^.H (H^) (H^) <H> doesn't see a match either, as H^ change the
description of the running machine to match that of the top level H.

So Nobody in this chain will abort their simulatons, and thus end up in
the same case as your old system when H insists on continuing to
simulate until it can actually prove its answer (which it never does)
and thus nothing ever halts.

Thus, you have an eternity to look at the problem until someone will
correctly agree to your incorrect conclusion.

Yes, perhaps with an improperly built H^, H might be able to get the
right answer, but that is the problem with "Proof by example", you need
to look at an infinite number of examples to be exhaustive.

The claim isn't that H gets NO answers right, just that there is at
least one input that it doesn't get right, and it is shown how to build
that for any arbitrary machine that might be claimed to be a Halt
Decider, thus proving it isn't, and since we can do this for ANY
machine, that none are.

On 3/8/24 11:08 AM, olcott wrote:
> On 3/8/2024 12:58 PM, immibis wrote:

>>
>> So it's impossible to make a Turing machine that writes 12345 onto its
>> tape unless 12345 is a parameter?
>
> That is a valid point.
> It is impossible to get me to talk about that until
> we first have full closure that the Linz H correctly
> determines the halt status of the Linz Ĥ ⟨Ĥ⟩ when run
> in the Olcott master UTM.
>

In other words you are going to ignore the true facts until someone
agrees to your lies.

Since it has been shown that for the PROPERLY CONSTRUCTED Linz H^ (built
by the semantic definition implemented for Olcott Machines) that Linz H
will NOT give the right answser, I guess you are deciding to DIE being
still known as the idiot.

(It becomes a bit of a Lie to try to refer to Linz's proof with Olcott
Machines since it SPECIFICALLY was talking about Turing Machines)

With the adapted definition of H^ that transforms

H^.q0 (M) <H^> |-> H^.Hq0 (M) (M) <H> to get H's answer to the machine M
and thus for the input of the description of itself it does

H^.q0 (H^) <H^> |-> H^.Hq0 (H^) (H^) <H> which will go to the same H
state as H (H^) (H^) <H> since it is the same algorithm with the same
input, and then Hqy loops forevern and Hqn Halts, we see that H can not
get the right answer.

When we look even farther at your description, we see that H, since its
first parameter doesn't match it given self description, not even a
sub-string of it (since the state number would have gotten remapped), so
H doesn't abort it's simulation.

Also H^.H (H^) (H^) <H> doesn't see a match either, as H^ change the
description of the running machine to match that of the top level H.

So Nobody in this chain will abort their simulatons, and thus end up in
the same case as your old system when H insists on continuing to
simulate until it can actually prove its answer (which it never does)
and thus nothing ever halts.

Thus, you have an eternity to look at the problem until someone will
correctly agree to your incorrect conclusion.

Yes, perhaps with an improperly built H^, H might be able to get the
right answer, but that is the problem with "Proof by example", you need
to look at an infinite number of examples to be exhaustive.

The claim isn't that H gets NO answers right, just that there is at
least one input that it doesn't get right, and it is shown how to build
that for any arbitrary machine that might be claimed to be a Halt
Decider, thus proving it isn't, and since we can do this for ANY
machine, that none are.

On 3/8/24 8:07 AM, olcott wrote:
> On 3/8/2024 9:07 AM, Mikko wrote:
>> On 2024-03-07 15:32:07 +0000, olcott said:
>>
>>> On 3/7/2024 5:17 AM, Mikko wrote:
>>>> On 2024-03-07 00:12:48 +0000, olcott said:
>>>>
>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>
>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>
>>>>>> What are the exact steps which the exact same program with the
>>>>>> exact same input uses to get two different results?
>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>>> defined to do exactly the same steps as H, which means you failed
>>>>>> to do the Linz procedure.
>>>>>
>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>> Can I continue to simulate my input without ever aborting it?
>>>>
>>>> It is not the same quessstion unless both machines interprete
>>>> the word "I" to doenote the same thing.
>>>>
>>>
>>> They are two different machines that interpret that
>>> I means their own machine address.
>>
>> As the machine address of one machine is not the same as the other
>> they interprete "I" differently. Therefore they interpreter the
>> question differently, i.e., as different qurestions.
>>
>
> My C functions H(D,D) and H1(D,D) can tell if they have been
> called in recursive simulation.

On;y because there simulation model doesn't isolate the machine to
decide from the decider, and thus can't handle all possible inputs.

It also defines itself to not be Turing Complete as we can't make a copy
of H (even though you then do it to make an H1)

>
> Olcott machines provide this same feature to Turing Machines.
> The master UTM appends the TMD to the end of the simulated
> machine's own tape.

Thus making no Olcott Machine a computation of just the original inputs,
as they ALL get the extra data, and you then need to PROVE that they
don't use it to get see that you have the computation you wanted.

>
> Olcott machines are simply reconfigured Turing machines where
> the master UTM appends the TMD to the simulated machines own tape.
>

Right, which gives them no advantage over an actual Turing machine.

They get *A* representation for themselves, which might not actually
match a copy made of them, due to the remapping that might have happened.

On 2024-03-08 16:07:14 +0000, olcott said:

> On 3/8/2024 9:07 AM, Mikko wrote:
>> On 2024-03-07 15:32:07 +0000, olcott said:
>>
>>> On 3/7/2024 5:17 AM, Mikko wrote:
>>>> On 2024-03-07 00:12:48 +0000, olcott said:
>>>>
>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>
>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>
>>>>>> What are the exact steps which the exact same program with the exact
>>>>>> same input uses to get two different results?
>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not defined
>>>>>> to do exactly the same steps as H, which means you failed to do the
>>>>>> Linz procedure.
>>>>>
>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>> Can I continue to simulate my input without ever aborting it?
>>>>
>>>> It is not the same quessstion unless both machines interprete
>>>> the word "I" to doenote the same thing.
>>>>
>>>
>>> They are two different machines that interpret that
>>> I means their own machine address.
>>
>> As the machine address of one machine is not the same as the other
>> they interprete "I" differently. Therefore they interpreter the
>> question differently, i.e., as different qurestions.
>>
>
> My C functions H(D,D) and H1(D,D) can tell if they have been
> called in recursive simulation.
>
> Olcott machines provide this same feature to Turing Machines.
> The master UTM appends the TMD to the end of the simulated
> machine's own tape.
>
> Olcott machines are simply reconfigured Turing machines where
> the master UTM appends the TMD to the simulated machines own tape.

Nice to see that you don't disagree with my observation that the
questions are different.

--
Mikko

On 8/03/24 20:08, olcott wrote:
> On 3/8/2024 12:58 PM, immibis wrote:
>> On 8/03/24 19:12, olcott wrote:
>>>
>>> Unless it is an extra parameter it has no basis for doing this.
>>> If it is an extra parameter then it is no longer the Linz proof.
>>>
>>
>> So it's impossible to make a Turing machine that writes 12345 onto its
>> tape unless 12345 is a parameter?
>
> That is a valid point.
> It is impossible to get me to talk about that until
> we first have full closure that the Linz H correctly
> determines the halt status of the Linz Ĥ ⟨Ĥ⟩ when run
> in the Olcott master UTM.
>

When run in the Olcott master UTM as Olcott machines, the Linz proof
does not work because it is designed for Turing machines. A different
proof works.

On 3/9/2024 7:11 AM, immibis wrote:
> On 8/03/24 20:08, olcott wrote:
>> On 3/8/2024 12:58 PM, immibis wrote:
>>> On 8/03/24 19:12, olcott wrote:
>>>>
>>>> Unless it is an extra parameter it has no basis for doing this.
>>>> If it is an extra parameter then it is no longer the Linz proof.
>>>>
>>>
>>> So it's impossible to make a Turing machine that writes 12345 onto
>>> its tape unless 12345 is a parameter?
>>
>> That is a valid point.
>> It is impossible to get me to talk about that until
>> we first have full closure that the Linz H correctly
>> determines the halt status of the Linz Ĥ ⟨Ĥ⟩ when run
>> in the Olcott master UTM.
>>
>
> When run in the Olcott master UTM as Olcott machines, the Linz proof
> does not work because it is designed for Turing machines. A different
> proof works.

Because Olcott machines are more powerful than Turing Machines they can
correctly determine the halt status of this input: H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>.

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 9/03/24 16:04, olcott wrote:
> On 3/9/2024 7:11 AM, immibis wrote:
>> On 8/03/24 20:08, olcott wrote:
>>> On 3/8/2024 12:58 PM, immibis wrote:
>>>> On 8/03/24 19:12, olcott wrote:
>>>>>
>>>>> Unless it is an extra parameter it has no basis for doing this.
>>>>> If it is an extra parameter then it is no longer the Linz proof.
>>>>>
>>>>
>>>> So it's impossible to make a Turing machine that writes 12345 onto
>>>> its tape unless 12345 is a parameter?
>>>
>>> That is a valid point.
>>> It is impossible to get me to talk about that until
>>> we first have full closure that the Linz H correctly
>>> determines the halt status of the Linz Ĥ ⟨Ĥ⟩ when run
>>> in the Olcott master UTM.
>>>
>>
>> When run in the Olcott master UTM as Olcott machines, the Linz proof
>> does not work because it is designed for Turing machines. A different
>> proof works.
>
> Because Olcott machines are more powerful than Turing Machines they can
> correctly determine the halt status of this input: H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>.
>

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> always calculates the same answer that H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
calculates.

On 3/9/2024 3:02 AM, Mikko wrote:
> On 2024-03-08 16:07:14 +0000, olcott said:
>
>> On 3/8/2024 9:07 AM, Mikko wrote:
>>> On 2024-03-07 15:32:07 +0000, olcott said:
>>>
>>>> On 3/7/2024 5:17 AM, Mikko wrote:
>>>>> On 2024-03-07 00:12:48 +0000, olcott said:
>>>>>
>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>
>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>>
>>>>>>> What are the exact steps which the exact same program with the
>>>>>>> exact same input uses to get two different results?
>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>>>> defined to do exactly the same steps as H, which means you failed
>>>>>>> to do the Linz procedure.
>>>>>>
>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>
>>>>> It is not the same quessstion unless both machines interprete
>>>>> the word "I" to doenote the same thing.
>>>>>
>>>>
>>>> They are two different machines that interpret that
>>>> I means their own machine address.
>>>
>>> As the machine address of one machine is not the same as the other
>>> they interprete "I" differently. Therefore they interpreter the
>>> question differently, i.e., as different qurestions.
>>>
>>
>> My C functions H(D,D) and H1(D,D) can tell if they have been
>> called in recursive simulation.
>>
>> Olcott machines provide this same feature to Turing Machines.
>> The master UTM appends the TMD to the end of the simulated
>> machine's own tape.
>>
>> Olcott machines are simply reconfigured Turing machines where
>> the master UTM appends the TMD to the simulated machines own tape.
>
> Nice to see that you don't disagree with my observation that the
> questions are different.
>

I am working on the computability of the halting problem
(the exact same TMD / input pairs) by a slightly augmented
notion of Turing machines as elaborated below:

Olcott machines are entirely comprised of a UTM + TMD and one
extra step that any UTM could perform, append the TMD to the end
of its own tape.

*Criterion Measure*
*Determine halt status from simulating halt deciders POV*
H is assumed to be a simulating termination analyzer that aborts the
simulation of any input that would cause its own non-termination and
returns NO. Otherwise H always returns YES.

As long as Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ can somehow apply *Criterion Measure*
then H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy is correct by applying this same
*Criterion Measure*

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 3/9/2024 9:33 AM, immibis wrote:
> On 9/03/24 16:04, olcott wrote:
>> On 3/9/2024 7:11 AM, immibis wrote:
>>> On 8/03/24 20:08, olcott wrote:
>>>> On 3/8/2024 12:58 PM, immibis wrote:
>>>>> On 8/03/24 19:12, olcott wrote:
>>>>>>
>>>>>> Unless it is an extra parameter it has no basis for doing this.
>>>>>> If it is an extra parameter then it is no longer the Linz proof.
>>>>>>
>>>>>
>>>>> So it's impossible to make a Turing machine that writes 12345 onto
>>>>> its tape unless 12345 is a parameter?
>>>>
>>>> That is a valid point.
>>>> It is impossible to get me to talk about that until
>>>> we first have full closure that the Linz H correctly
>>>> determines the halt status of the Linz Ĥ ⟨Ĥ⟩ when run
>>>> in the Olcott master UTM.
>>>>
>>>
>>> When run in the Olcott master UTM as Olcott machines, the Linz proof
>>> does not work because it is designed for Turing machines. A different
>>> proof works.
>>
>> Because Olcott machines are more powerful than Turing Machines they
>> can correctly determine the halt status of this input: H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>.
>>
>
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> always calculates the same answer that H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
> calculates.
>

No it does not. Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ has some preceding steps that copy its input
and H ⟨Ĥ⟩ ⟨Ĥ⟩ does not have these steps. Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ can see all of these
steps.

It turns out that this single difference is why Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort
its simulation and H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.

I only created Olcott machines so that it is easy to see how Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
would detect that it must abort its simulation and transition to Ĥ.Hqn.

Turing machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ might still be able to do this thus
nullifying your counter-example.

Your reviews are often quite good. Some of Richard's reviews
were very good and some of them are stuck in circular reasoning
anchored in very persistently false assumptions.

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 3/9/24 7:55 AM, olcott wrote:
> On 3/9/2024 3:02 AM, Mikko wrote:
>> On 2024-03-08 16:07:14 +0000, olcott said:
>>
>>> On 3/8/2024 9:07 AM, Mikko wrote:
>>>> On 2024-03-07 15:32:07 +0000, olcott said:
>>>>
>>>>> On 3/7/2024 5:17 AM, Mikko wrote:
>>>>>> On 2024-03-07 00:12:48 +0000, olcott said:
>>>>>>
>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>>
>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>>>
>>>>>>>> What are the exact steps which the exact same program with the
>>>>>>>> exact same input uses to get two different results?
>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not
>>>>>>>> defined to do exactly the same steps as H, which means you
>>>>>>>> failed to do the Linz procedure.
>>>>>>>
>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>
>>>>>> It is not the same quessstion unless both machines interprete
>>>>>> the word "I" to doenote the same thing.
>>>>>>
>>>>>
>>>>> They are two different machines that interpret that
>>>>> I means their own machine address.
>>>>
>>>> As the machine address of one machine is not the same as the other
>>>> they interprete "I" differently. Therefore they interpreter the
>>>> question differently, i.e., as different qurestions.
>>>>
>>>
>>> My C functions H(D,D) and H1(D,D) can tell if they have been
>>> called in recursive simulation.
>>>
>>> Olcott machines provide this same feature to Turing Machines.
>>> The master UTM appends the TMD to the end of the simulated
>>> machine's own tape.
>>>
>>> Olcott machines are simply reconfigured Turing machines where
>>> the master UTM appends the TMD to the simulated machines own tape.
>>
>> Nice to see that you don't disagree with my observation that the
>> questions are different.
>>
>
> I am working on the computability of the halting problem
> (the exact same TMD / input pairs) by a slightly augmented
> notion of Turing machines as elaborated below:
>
> Olcott machines are entirely comprised of a UTM + TMD and one
> extra step that any UTM could perform, append the TMD to the end
> of its own tape.
>
> *Criterion Measure*
> *Determine halt status from simulating halt deciders POV*
> H is assumed to be a simulating termination analyzer that aborts the
> simulation of any input that would cause its own non-termination and
> returns NO. Otherwise H always returns YES.
>
> As long as Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ can somehow apply *Criterion Measure*
> then H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy is correct by applying this same
> *Criterion Measure*
>

Which just means that you are LYING about working on the Haling Problem.

Since you are NOT computing the HALTING mapping, whatever you do is
irrelvent to the actual Halting Problem.

This means you are just admitting to being a LIAR.

Different Cxriteria, Different Problem.

And, the form of your question show your total IGNORANCE of how
computers work, as "H" having a definitive behavior, means that the
pathological program built on it also has a definitive behavior, and if
an H "thinks" that the input would be non-halting and aborts it
processing and returns 0 and that pathological program then halts when
it is actually run, shows that H was WRONG in its thinking.

If you beleive that its erroneous presumptions allows it to give a wrong
answer, then you do not believe in the concept of Objective Truth.

This has been your problem for year, you don't understand the meaning of
something actually being TRUE, even if you don't see why it is.

On 3/9/24 7:04 AM, olcott wrote:
> On 3/9/2024 7:11 AM, immibis wrote:
>> On 8/03/24 20:08, olcott wrote:
>>> On 3/8/2024 12:58 PM, immibis wrote:
>>>> On 8/03/24 19:12, olcott wrote:
>>>>>
>>>>> Unless it is an extra parameter it has no basis for doing this.
>>>>> If it is an extra parameter then it is no longer the Linz proof.
>>>>>
>>>>
>>>> So it's impossible to make a Turing machine that writes 12345 onto
>>>> its tape unless 12345 is a parameter?
>>>
>>> That is a valid point.
>>> It is impossible to get me to talk about that until
>>> we first have full closure that the Linz H correctly
>>> determines the halt status of the Linz Ĥ ⟨Ĥ⟩ when run
>>> in the Olcott master UTM.
>>>
>>
>> When run in the Olcott master UTM as Olcott machines, the Linz proof
>> does not work because it is designed for Turing machines. A different
>> proof works.
>
> Because Olcott machines are more powerful than Turing Machines they can
> correctly determine the halt status of this input: H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>.
>
>

Nope, Olcott machine are designed to hide that they are using extra data
and can't be confirmed to be the actual required comptation to be a Halt
Decider.

If you want to try to make your FALSE claim, then PUT UP or SHUT UP.

Shot the ACTUAL ALGORITHM (ie HOW the algorithm works) that lets your H
get the right answer, when H^ is designed so that

H^ (H^) <H^> |-> H^.Hq0 (H^) (H^) <H>

What does H (H^) (H^) <H> do?

Go to qy and predict that H^ (H^) <H^> Halts, when it will go to H^qy
and loop forever, or

Go to qn and predict that H^ (H^) <H^> will never halt, when it will
also go to H^qn and HALT.

You are just proving your stupidity.

On 3/9/24 8:15 AM, olcott wrote:
> On 3/9/2024 9:33 AM, immibis wrote:
>> On 9/03/24 16:04, olcott wrote:
>>> On 3/9/2024 7:11 AM, immibis wrote:
>>>> On 8/03/24 20:08, olcott wrote:
>>>>> On 3/8/2024 12:58 PM, immibis wrote:
>>>>>> On 8/03/24 19:12, olcott wrote:
>>>>>>>
>>>>>>> Unless it is an extra parameter it has no basis for doing this.
>>>>>>> If it is an extra parameter then it is no longer the Linz proof.
>>>>>>>
>>>>>>
>>>>>> So it's impossible to make a Turing machine that writes 12345 onto
>>>>>> its tape unless 12345 is a parameter?
>>>>>
>>>>> That is a valid point.
>>>>> It is impossible to get me to talk about that until
>>>>> we first have full closure that the Linz H correctly
>>>>> determines the halt status of the Linz Ĥ ⟨Ĥ⟩ when run
>>>>> in the Olcott master UTM.
>>>>>
>>>>
>>>> When run in the Olcott master UTM as Olcott machines, the Linz proof
>>>> does not work because it is designed for Turing machines. A
>>>> different proof works.
>>>
>>> Because Olcott machines are more powerful than Turing Machines they
>>> can correctly determine the halt status of this input: H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>.
>>>
>>
>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> always calculates the same answer that H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>> calculates.
>>
>
> No it does not. Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ has some preceding steps that copy its input
> and H ⟨Ĥ⟩ ⟨Ĥ⟩ does not have these steps. Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ can see all of these
> steps.

HOW?

The only "memory" in the machine is the tape, and that doesn't have any
of that information on it.

>
> It turns out that this single difference is why Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort
> its simulation and H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.

I.E, if you lie about the system, you can claim anything you want.

You just proved you are totally ignorant about how Turing Machines and
computations work.

This makes you the pathetic ignorant pathoogical lying idiot that you are.

>
> I only created Olcott machines so that it is easy to see how Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
> would detect that it must abort its simulation and transition to Ĥ.Hqn.

Except you don't explain HOW it does that,

Since the Olcott H^.H is pased the context <H> instead of <H^> it has no
way to see what you are claiming.

>
> Turing machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ might still be able to do this thus
> nullifying your counter-example.
>
> Your reviews are often quite good. Some of Richard's reviews
> were very good and some of them are stuck in circular reasoning
> anchored in very persistently false assumptions.
>

You are just proving you are too stupid to understand what yoare talking
about.