On 3/7/2024 12:46 PM, Richard Damon wrote:
> On 3/7/24 10:30 AM, olcott wrote:
>> On 3/7/2024 10:44 AM, immibis wrote:
>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>> immibis <news@immibis.com> writes:
>>>>
>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>> The students I taught seemed to have no problem with this sort of
>>>>>> case
>>>>>> analysis.  But the "assume H does X" argument lead to lots of "but H1
>>>>>> could be better" arguments.
>>>>>
>>>>> They aren't satisfied with "we can do the exact same thing with H1
>>>>> to prove
>>>>> that H1 doesn't work either"?
>>>>
>>>> In the vast majority of cases, yes, but even then there is a logical
>>>> problem with going down that route -- there is no H so there can't
>>>> be an
>>>> H1 that does better.  Once this objection is properly examined, it
>>>> turns
>>>> out to be the argument I ended up preferring anyway.  H isn't a halt
>>>> decider, it's just any old TM and we show it can't be halt decider for
>>>> one reason or another.
>>>>
>>>
>>> Unless your students are extremely pedantic... maybe they are... I
>>> don't see what's illogical with:
>>>
>>> "I think H is a halt decider."
>>> "But it doesn't: see this proof."
>>> "Oh. Well, even though H isn't a halt decider, how do we know there
>>> isn't a program H1 which is a halt decider?"
>>> "The proof would still work for H1, or H2, or any other program you
>>> think is a halt decider."
>>>
>>>
>>
>> It is an easily verified fact that:
>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address 00001422
>> *different machine addresses is the reason for different return values*
>>
>>
>
> Which proves that H1 and H are different computation and thus different
> Turing Machines, so H1 getting the right answer doesn't "fix" H's
> getting the wrong answer.
>

Good catch !!!

For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
its own TMD concatenated to this input to its Boolean result.

Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
concatenated to this input to its Boolean result.

thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
cannot.

> H1^ will confound H1, thus showing it isn't a halt decider either.

--
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/7/24 11:11 AM, olcott wrote:
> On 3/7/2024 12:46 PM, Richard Damon wrote:
>> On 3/7/24 10:30 AM, olcott wrote:
>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>> immibis <news@immibis.com> writes:
>>>>>
>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>> The students I taught seemed to have no problem with this sort of
>>>>>>> case
>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>> "but H1
>>>>>>> could be better" arguments.
>>>>>>
>>>>>> They aren't satisfied with "we can do the exact same thing with H1
>>>>>> to prove
>>>>>> that H1 doesn't work either"?
>>>>>
>>>>> In the vast majority of cases, yes, but even then there is a logical
>>>>> problem with going down that route -- there is no H so there can't
>>>>> be an
>>>>> H1 that does better.  Once this objection is properly examined, it
>>>>> turns
>>>>> out to be the argument I ended up preferring anyway.  H isn't a halt
>>>>> decider, it's just any old TM and we show it can't be halt decider for
>>>>> one reason or another.
>>>>>
>>>>
>>>> Unless your students are extremely pedantic... maybe they are... I
>>>> don't see what's illogical with:
>>>>
>>>> "I think H is a halt decider."
>>>> "But it doesn't: see this proof."
>>>> "Oh. Well, even though H isn't a halt decider, how do we know there
>>>> isn't a program H1 which is a halt decider?"
>>>> "The proof would still work for H1, or H2, or any other program you
>>>> think is a halt decider."
>>>>
>>>>
>>>
>>> It is an easily verified fact that:
>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>> 00001422
>>> *different machine addresses is the reason for different return values*
>>>
>>>
>>
>> Which proves that H1 and H are different computation and thus
>> different Turing Machines, so H1 getting the right answer doesn't
>> "fix" H's getting the wrong answer.
>>
>
> Good catch !!!
>
> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
> its own TMD concatenated to this input to its Boolean result.
>
> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
> concatenated to this input to its Boolean result.
>
> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
> cannot.

Which only indicates that either you built your H^ incorrectly, as H^.H
is supposed to do exactly the same thing as H itself, or if that is
impossible to do, that your modification to Turing Machine rules have
made your system not-Turing Complete, as you are admitting that the is a
Computation that could be made with Turing Machines (H^ from a given H)
that you can't make in Olcott-Machines.

>
>> H1^ will confound H1, thus showing it isn't a halt decider either.
>

On 3/7/2024 1:15 PM, Richard Damon wrote:
> On 3/7/24 11:11 AM, olcott wrote:
>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>> On 3/7/24 10:30 AM, olcott wrote:
>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>> immibis <news@immibis.com> writes:
>>>>>>
>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>> The students I taught seemed to have no problem with this sort
>>>>>>>> of case
>>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>>> "but H1
>>>>>>>> could be better" arguments.
>>>>>>>
>>>>>>> They aren't satisfied with "we can do the exact same thing with
>>>>>>> H1 to prove
>>>>>>> that H1 doesn't work either"?
>>>>>>
>>>>>> In the vast majority of cases, yes, but even then there is a logical
>>>>>> problem with going down that route -- there is no H so there can't
>>>>>> be an
>>>>>> H1 that does better.  Once this objection is properly examined, it
>>>>>> turns
>>>>>> out to be the argument I ended up preferring anyway.  H isn't a halt
>>>>>> decider, it's just any old TM and we show it can't be halt decider
>>>>>> for
>>>>>> one reason or another.
>>>>>>
>>>>>
>>>>> Unless your students are extremely pedantic... maybe they are... I
>>>>> don't see what's illogical with:
>>>>>
>>>>> "I think H is a halt decider."
>>>>> "But it doesn't: see this proof."
>>>>> "Oh. Well, even though H isn't a halt decider, how do we know there
>>>>> isn't a program H1 which is a halt decider?"
>>>>> "The proof would still work for H1, or H2, or any other program you
>>>>> think is a halt decider."
>>>>>
>>>>>
>>>>
>>>> It is an easily verified fact that:
>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>> 00001422
>>>> *different machine addresses is the reason for different return values*
>>>>
>>>>
>>>
>>> Which proves that H1 and H are different computation and thus
>>> different Turing Machines, so H1 getting the right answer doesn't
>>> "fix" H's getting the wrong answer.
>>>
>>
>> Good catch !!!
>>
>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>> its own TMD concatenated to this input to its Boolean result.
>>
>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>> concatenated to this input to its Boolean result.
>>
>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>> cannot.
>
> Which only indicates that either you built your H^ incorrectly, as H^.H
> is supposed to do exactly the same thing as H itself,

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
only if they have the same input.

When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.

> or if that is
> impossible to do, that your modification to Turing Machine rules have
> made your system not-Turing Complete, as you are admitting that the is a
> Computation that could be made with Turing Machines (H^ from a given H)
> that you can't make in Olcott-Machines.
>

You are not evaluating Turing Complete correctly. Olcott machines
exactly compute all of the same decision problems that Turing
machines compute when the Olcott machines ignore their own TMD.

In addition to this it seems that some decision problems that
Turing machines CANNOT compute can be computed by Olcott machines.

>>
>>> H1^ will confound H1, thus showing it isn't a halt decider either.
>>
>

--
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/7/24 11:37 AM, olcott wrote:
> On 3/7/2024 1:15 PM, Richard Damon wrote:
>> On 3/7/24 11:11 AM, olcott wrote:
>>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>>> On 3/7/24 10:30 AM, olcott wrote:
>>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>>> immibis <news@immibis.com> writes:
>>>>>>>
>>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>>> The students I taught seemed to have no problem with this sort
>>>>>>>>> of case
>>>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>>>> "but H1
>>>>>>>>> could be better" arguments.
>>>>>>>>
>>>>>>>> They aren't satisfied with "we can do the exact same thing with
>>>>>>>> H1 to prove
>>>>>>>> that H1 doesn't work either"?
>>>>>>>
>>>>>>> In the vast majority of cases, yes, but even then there is a logical
>>>>>>> problem with going down that route -- there is no H so there
>>>>>>> can't be an
>>>>>>> H1 that does better.  Once this objection is properly examined,
>>>>>>> it turns
>>>>>>> out to be the argument I ended up preferring anyway.  H isn't a halt
>>>>>>> decider, it's just any old TM and we show it can't be halt
>>>>>>> decider for
>>>>>>> one reason or another.
>>>>>>>
>>>>>>
>>>>>> Unless your students are extremely pedantic... maybe they are... I
>>>>>> don't see what's illogical with:
>>>>>>
>>>>>> "I think H is a halt decider."
>>>>>> "But it doesn't: see this proof."
>>>>>> "Oh. Well, even though H isn't a halt decider, how do we know
>>>>>> there isn't a program H1 which is a halt decider?"
>>>>>> "The proof would still work for H1, or H2, or any other program
>>>>>> you think is a halt decider."
>>>>>>
>>>>>>
>>>>>
>>>>> It is an easily verified fact that:
>>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>>> 00001422
>>>>> *different machine addresses is the reason for different return
>>>>> values*
>>>>>
>>>>>
>>>>
>>>> Which proves that H1 and H are different computation and thus
>>>> different Turing Machines, so H1 getting the right answer doesn't
>>>> "fix" H's getting the wrong answer.
>>>>
>>>
>>> Good catch !!!
>>>
>>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>>> its own TMD concatenated to this input to its Boolean result.
>>>
>>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>>> concatenated to this input to its Boolean result.
>>>
>>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> cannot.
>>
>> Which only indicates that either you built your H^ incorrectly, as
>> H^.H is supposed to do exactly the same thing as H itself,
>
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
> only if they have the same input.
>
> When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
> have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
> and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.

And a machone that depends on anythohng other than the description of
the input is provvably NOT a Halt Decider, so you are just admitting
that H isn't a Halt Decider, since for some values of description, it
gives the wrong answer.

>
>> or if that is impossible to do, that your modification to Turing
>> Machine rules have made your system not-Turing Complete, as you are
>> admitting that the is a Computation that could be made with Turing
>> Machines (H^ from a given H) that you can't make in Olcott-Machines.
>>
>
> You are not evaluating Turing Complete correctly. Olcott machines
> exactly compute all of the same decision problems that Turing
> machines compute when the Olcott machines ignore their own TMD.

Right, but if they don't then they can't be said to compute the mapping
that ignores that input.

So, since H doesn't ignore its extra input, it doesn't compute that
mapping called Halting, that isn't dependent on the machine deciding.

>
> In addition to this it seems that some decision problems that
> Turing machines CANNOT compute can be computed by Olcott machines.

Nope. you only think that because you don't understand what a
computation is, and you refuse to learn, making you just a stupid and
ignorant pathological lying idiot.

>
>>>
>>>> H1^ will confound H1, thus showing it isn't a halt decider either.
>>>
>>
>

On 3/7/2024 1:57 PM, Richard Damon wrote:
> On 3/7/24 11:37 AM, olcott wrote:
>> On 3/7/2024 1:15 PM, Richard Damon wrote:
>>> On 3/7/24 11:11 AM, olcott wrote:
>>>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>>>> On 3/7/24 10:30 AM, olcott wrote:
>>>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>>>> immibis <news@immibis.com> writes:
>>>>>>>>
>>>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>>>> The students I taught seemed to have no problem with this sort
>>>>>>>>>> of case
>>>>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>>>>> "but H1
>>>>>>>>>> could be better" arguments.
>>>>>>>>>
>>>>>>>>> They aren't satisfied with "we can do the exact same thing with
>>>>>>>>> H1 to prove
>>>>>>>>> that H1 doesn't work either"?
>>>>>>>>
>>>>>>>> In the vast majority of cases, yes, but even then there is a
>>>>>>>> logical
>>>>>>>> problem with going down that route -- there is no H so there
>>>>>>>> can't be an
>>>>>>>> H1 that does better.  Once this objection is properly examined,
>>>>>>>> it turns
>>>>>>>> out to be the argument I ended up preferring anyway.  H isn't a
>>>>>>>> halt
>>>>>>>> decider, it's just any old TM and we show it can't be halt
>>>>>>>> decider for
>>>>>>>> one reason or another.
>>>>>>>>
>>>>>>>
>>>>>>> Unless your students are extremely pedantic... maybe they are...
>>>>>>> I don't see what's illogical with:
>>>>>>>
>>>>>>> "I think H is a halt decider."
>>>>>>> "But it doesn't: see this proof."
>>>>>>> "Oh. Well, even though H isn't a halt decider, how do we know
>>>>>>> there isn't a program H1 which is a halt decider?"
>>>>>>> "The proof would still work for H1, or H2, or any other program
>>>>>>> you think is a halt decider."
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> It is an easily verified fact that:
>>>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>>>> 00001422
>>>>>> *different machine addresses is the reason for different return
>>>>>> values*
>>>>>>
>>>>>>
>>>>>
>>>>> Which proves that H1 and H are different computation and thus
>>>>> different Turing Machines, so H1 getting the right answer doesn't
>>>>> "fix" H's getting the wrong answer.
>>>>>
>>>>
>>>> Good catch !!!
>>>>
>>>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>>>> its own TMD concatenated to this input to its Boolean result.
>>>>
>>>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>>>> concatenated to this input to its Boolean result.
>>>>
>>>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>>>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> cannot.
>>>
>>> Which only indicates that either you built your H^ incorrectly, as
>>> H^.H is supposed to do exactly the same thing as H itself,
>>
>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
>> only if they have the same input.
>>
>> When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
>> have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>> and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.
>
> And a machone that depends on anythohng other than the description of
> the input is provvably NOT a Halt Decider,

When it correctly determines the actual halt status of an
actual input TMD+Finite_String then it correctly decided
this TMD+Finite_String.

No one can say that it gets the wrong answer when it
gets the right answer.

The most than anyone can say is that this answer may
not be Turing computable.

When an Olcott machine maps TMD+Finite_String+Own_TMD
to a Boolean value then this Olcott machine derives
its output as a pure function of its inputs.

> so you are just admitting
> that H isn't a Halt Decider, since for some values of description, it
> gives the wrong answer.
>
>>
>>> or if that is impossible to do, that your modification to Turing
>>> Machine rules have made your system not-Turing Complete, as you are
>>> admitting that the is a Computation that could be made with Turing
>>> Machines (H^ from a given H) that you can't make in Olcott-Machines.
>>>
>>
>> You are not evaluating Turing Complete correctly. Olcott machines
>> exactly compute all of the same decision problems that Turing
>> machines compute when the Olcott machines ignore their own TMD.
>
> Right, but if they don't then they can't be said to compute the mapping
> that ignores that input.
>
> So, since H doesn't ignore its extra input, it doesn't compute that
> mapping called Halting, that isn't dependent on the machine deciding.

The set of Olcott machines that compute the mapping from
their inputs (ignoring their own TMD) to an output is
exactly the same set as the set of Turing machines that
compute the mapping from their inputs to their own output.

This analysis proves that a subset of Olcott machines
compute the same set as the set of Turing machines.

--
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/7/24 12:18 PM, olcott wrote:
> On 3/7/2024 1:57 PM, Richard Damon wrote:
>> On 3/7/24 11:37 AM, olcott wrote:
>>> On 3/7/2024 1:15 PM, Richard Damon wrote:
>>>> On 3/7/24 11:11 AM, olcott wrote:
>>>>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>>>>> On 3/7/24 10:30 AM, olcott wrote:
>>>>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>>>>> immibis <news@immibis.com> writes:
>>>>>>>>>
>>>>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>>>>> The students I taught seemed to have no problem with this
>>>>>>>>>>> sort of case
>>>>>>>>>>> analysis.  But the "assume H does X" argument lead to lots of
>>>>>>>>>>> "but H1
>>>>>>>>>>> could be better" arguments.
>>>>>>>>>>
>>>>>>>>>> They aren't satisfied with "we can do the exact same thing
>>>>>>>>>> with H1 to prove
>>>>>>>>>> that H1 doesn't work either"?
>>>>>>>>>
>>>>>>>>> In the vast majority of cases, yes, but even then there is a
>>>>>>>>> logical
>>>>>>>>> problem with going down that route -- there is no H so there
>>>>>>>>> can't be an
>>>>>>>>> H1 that does better.  Once this objection is properly examined,
>>>>>>>>> it turns
>>>>>>>>> out to be the argument I ended up preferring anyway.  H isn't a
>>>>>>>>> halt
>>>>>>>>> decider, it's just any old TM and we show it can't be halt
>>>>>>>>> decider for
>>>>>>>>> one reason or another.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Unless your students are extremely pedantic... maybe they are...
>>>>>>>> I don't see what's illogical with:
>>>>>>>>
>>>>>>>> "I think H is a halt decider."
>>>>>>>> "But it doesn't: see this proof."
>>>>>>>> "Oh. Well, even though H isn't a halt decider, how do we know
>>>>>>>> there isn't a program H1 which is a halt decider?"
>>>>>>>> "The proof would still work for H1, or H2, or any other program
>>>>>>>> you think is a halt decider."
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> It is an easily verified fact that:
>>>>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>>>>> 00001422
>>>>>>> *different machine addresses is the reason for different return
>>>>>>> values*
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Which proves that H1 and H are different computation and thus
>>>>>> different Turing Machines, so H1 getting the right answer doesn't
>>>>>> "fix" H's getting the wrong answer.
>>>>>>
>>>>>
>>>>> Good catch !!!
>>>>>
>>>>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>>>>> its own TMD concatenated to this input to its Boolean result.
>>>>>
>>>>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>>>>> concatenated to this input to its Boolean result.
>>>>>
>>>>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>>>>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> cannot.
>>>>
>>>> Which only indicates that either you built your H^ incorrectly, as
>>>> H^.H is supposed to do exactly the same thing as H itself,
>>>
>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> only if they have the same input.
>>>
>>> When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
>>> have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.
>>
>> And a machone that depends on anythohng other than the description of
>> the input is provvably NOT a Halt Decider,
>
> When it correctly determines the actual halt status of an
> actual input TMD+Finite_String then it correctly decided
> this TMD+Finite_String.

And the finite string needs to be EXACTLY the input given to that Turing
Machine that was Described.

>
> No one can say that it gets the wrong answer when it
> gets the right answer.

But if H, given the description of H^ applied to its description says it
doesn't halt, but when H^ is applied to its description it does, then it
was wrong.

If the copy of H inside H^ does give the exact same answer as H did,
then you built H^ wrong, and are lying, or if you can't, you just proved
you system is not Turing Complete, as there is a computation built with
Turing machines that you can not replicate.
>
> The most than anyone can say is that this answer may
> not be Turing computable.

And thus not Computable, as Turing Machine EXACTLY match the ACTUAL
definition of Computable.

>
> When an Olcott machine maps TMD+Finite_String+Own_TMD
> to a Boolean value then this Olcott machine derives
> its output as a pure function of its inputs.

But the WRONG function to be a Halt Decider.

You don't seem to understand that, because you are just too stupid to
understand what a Computation actually is, or what Requirment actually
means.

>
>> so you are just admitting that H isn't a Halt Decider, since for some
>> values of description, it gives the wrong answer.
>>
>>>
>>>> or if that is impossible to do, that your modification to Turing
>>>> Machine rules have made your system not-Turing Complete, as you are
>>>> admitting that the is a Computation that could be made with Turing
>>>> Machines (H^ from a given H) that you can't make in Olcott-Machines.
>>>>
>>>
>>> You are not evaluating Turing Complete correctly. Olcott machines
>>> exactly compute all of the same decision problems that Turing
>>> machines compute when the Olcott machines ignore their own TMD.
>>
>> Right, but if they don't then they can't be said to compute the
>> mapping that ignores that input.
>>
>> So, since H doesn't ignore its extra input, it doesn't compute that
>> mapping called Halting, that isn't dependent on the machine deciding.
>
> The set of Olcott machines that compute the mapping from
> their inputs (ignoring their own TMD) to an output is
> exactly the same set as the set of Turing machines that
> compute the mapping from their inputs to their own output.

Right, and since your Halt Decider isn't in that set.

>
> This analysis proves that a subset of Olcott machines
> compute the same set as the set of Turing machines.
>

But since H is just an Olcott machine, that is claimed to produce a
COmputation, then H^ can include a copy of it in its code to EXACTLY
repoduce its instructions, and the data on the tape that represents it
(remember, H^ know the description of H, so it can include that on the
tape itself).

Since the Master UTM can't tell when H^ transitions into its submachine
H to interfere with that behavior (it is just another set of states
within H^) then that H sub-machine will see EXACTLY the same input, even
the same description of itself, and thus MUST generate exactly the same
output as the actual H run from the master UTM.

The rules you defined do not allow for any limitation in the
manipulation of the Tape within a machine, so H^ can totally reproduce
the environment that the top level H sees, and thus gets the exact same
answer.

On 3/7/2024 2:59 PM, Richard Damon wrote:
> On 3/7/24 12:18 PM, olcott wrote:
>> On 3/7/2024 1:57 PM, Richard Damon wrote:
>>> On 3/7/24 11:37 AM, olcott wrote:
>>>> On 3/7/2024 1:15 PM, Richard Damon wrote:
>>>>> On 3/7/24 11:11 AM, olcott wrote:
>>>>>> On 3/7/2024 12:46 PM, Richard Damon wrote:
>>>>>>> On 3/7/24 10:30 AM, olcott wrote:
>>>>>>>> On 3/7/2024 10:44 AM, immibis wrote:
>>>>>>>>> On 7/03/24 17:16, Ben Bacarisse wrote:
>>>>>>>>>> immibis <news@immibis.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 7/03/24 12:32, Ben Bacarisse wrote:
>>>>>>>>>>>> The students I taught seemed to have no problem with this
>>>>>>>>>>>> sort of case
>>>>>>>>>>>> analysis.  But the "assume H does X" argument lead to lots
>>>>>>>>>>>> of "but H1
>>>>>>>>>>>> could be better" arguments.
>>>>>>>>>>>
>>>>>>>>>>> They aren't satisfied with "we can do the exact same thing
>>>>>>>>>>> with H1 to prove
>>>>>>>>>>> that H1 doesn't work either"?
>>>>>>>>>>
>>>>>>>>>> In the vast majority of cases, yes, but even then there is a
>>>>>>>>>> logical
>>>>>>>>>> problem with going down that route -- there is no H so there
>>>>>>>>>> can't be an
>>>>>>>>>> H1 that does better.  Once this objection is properly
>>>>>>>>>> examined, it turns
>>>>>>>>>> out to be the argument I ended up preferring anyway.  H isn't
>>>>>>>>>> a halt
>>>>>>>>>> decider, it's just any old TM and we show it can't be halt
>>>>>>>>>> decider for
>>>>>>>>>> one reason or another.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Unless your students are extremely pedantic... maybe they
>>>>>>>>> are... I don't see what's illogical with:
>>>>>>>>>
>>>>>>>>> "I think H is a halt decider."
>>>>>>>>> "But it doesn't: see this proof."
>>>>>>>>> "Oh. Well, even though H isn't a halt decider, how do we know
>>>>>>>>> there isn't a program H1 which is a halt decider?"
>>>>>>>>> "The proof would still work for H1, or H2, or any other program
>>>>>>>>> you think is a halt decider."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is an easily verified fact that:
>>>>>>>> H(D,D) Sees that D(D) is calling H(D,D) at machine address 00001522
>>>>>>>> H1(D,D) Sees that D(D) is NOT calling H1(D,D) at machine address
>>>>>>>> 00001422
>>>>>>>> *different machine addresses is the reason for different return
>>>>>>>> values*
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Which proves that H1 and H are different computation and thus
>>>>>>> different Turing Machines, so H1 getting the right answer doesn't
>>>>>>> "fix" H's getting the wrong answer.
>>>>>>>
>>>>>>
>>>>>> Good catch !!!
>>>>>>
>>>>>> For Olcott machines Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with
>>>>>> its own TMD concatenated to this input to its Boolean result.
>>>>>>
>>>>>> Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ would map its input with its own TMD
>>>>>> concatenated to this input to its Boolean result.
>>>>>>
>>>>>> thus finally explaining how Linz H ⟨Ĥ⟩ ⟨Ĥ⟩ can correctly
>>>>>> determine the halt status of its input while Linz Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> cannot.
>>>>>
>>>>> Which only indicates that either you built your H^ incorrectly, as
>>>>> H^.H is supposed to do exactly the same thing as H itself,
>>>>
>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ is supposed to do exactly the same things as H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> only if they have the same input.
>>>>
>>>> When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ are Olcott machines they always
>>>> have an additional input that makes the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> and H ⟨Ĥ⟩ ⟨Ĥ⟩ different.
>>>
>>> And a machone that depends on anythohng other than the description of
>>> the input is provvably NOT a Halt Decider,
>>
>> When it correctly determines the actual halt status of an
>> actual input TMD+Finite_String then it correctly decided
>> this TMD+Finite_String.
>
> And the finite string needs to be EXACTLY the input given to that Turing
> Machine that was Described.
>
>>
>> No one can say that it gets the wrong answer when it
>> gets the right answer.
>
>
> But if H, given the description of H^ applied to its description says it
> doesn't halt, but when H^ is applied to its description it does, then it
> was wrong.
>

New thread has all of the relevant details in one place
[We finally know exactly how H1(D,D) derives a different result than H(D,D)]
This make it much easier for people seeing this for the first time.

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