Re: Linz's proofs. --- Good catch !

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