On 4/6/2022 10:27 PM, Dennis Bush wrote:
> On Wednesday, April 6, 2022 at 10:55:06 PM UTC-4, olcott wrote:
>> On 4/6/2022 9:45 PM, Dennis Bush wrote:
>>> On Wednesday, April 6, 2022 at 10:40:15 PM UTC-4, olcott wrote:
>>>> On 4/6/2022 9:26 PM, Dennis Bush wrote:
>>>>> On Wednesday, April 6, 2022 at 10:15:18 PM UTC-4, olcott wrote:
>>>>>> On 4/6/2022 9:12 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, April 6, 2022 at 10:10:45 PM UTC-4, olcott wrote:
>>>>>>>> On 4/6/2022 9:03 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-04-06 19:47, olcott wrote:
>>>>>>>>>> On 4/6/2022 8:41 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-04-06 19:25, olcott wrote:
>>>>>>>>>>>> On 4/6/2022 8:17 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-04-06 19:10, olcott wrote:
>>>>>>>>>>>>>> On 4/6/2022 7:50 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But, now that we've got that out of the way, here's a simple
>>>>>>>>>>>>>>> question for you: If you want your evenness decider to decide
>>>>>>>>>>>>>>> whether seven is even, which string would you pass to it? [yes, I
>>>>>>>>>>>>>>> know this is trivially obvious, just humour me]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 111[]
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm assuming that you're using [] to indicate a blank.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Presumably your E would *reject* this string since seven is an odd
>>>>>>>>>>>>> number rather than an even one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But notice that in the above case your Turing Machine is rejecting
>>>>>>>>>>>>> a finite string "111␣" based on the fact that the *integer* seven,
>>>>>>>>>>>>> which is neither an input nor a finite string, is not even.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So your decider is mapping from a finite string (its input) to
>>>>>>>>>>>>> reject/accept based on something which is a "non-input non-finite
>>>>>>>>>>>>> string" (to use an expression you've often used).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That seems totally incoherent.
>>>>>>>>>>>>
>>>>>>>>>>>> The TM maps its input finite string to its reject state based on a
>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But 'evenness' is not a property of strings; it is a property of
>>>>>>>>>>> numbers, and strings are not numbers.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It can be correctly construed as the property of the string.
>>>>>>>>>
>>>>>>>>> Not by any normal definition.
>>>>>>>>>
>>>>>>>>> A string is an *uninterpreted* sequence of symbols.
>>>>>>>>>
>>>>>>>>>>> Your decider bases its decision on a property of the string (is the
>>>>>>>>>>> final digit 0?), but that property only corresponds to evenness by
>>>>>>>>>>> virtue of the encoding you have chosen.
>>>>>>>>>>>
>>>>>>>>>>> A decider which uses a unary representation (which would be slightly
>>>>>>>>>>> simpler than your binary one) couldn't just look at a single digit. Nor
>>>>>>>>>>
>>>>>>>>>> Thus not actually simpler.
>>>>>>>>>
>>>>>>>>> If you actually attempted to write the two versions of E, you'd discover
>>>>>>>>> that you are simply wrong in this assessment. The fact that you don't
>>>>>>>>> realize this is merely a testament to the fact that you really don't
>>>>>>>>> understand how Turing Machines work. At all.
>>>>>>>>>
>>>>>>>>>>> could one that used trinary representation (which would be only
>>>>>>>>>>> slightly more complex than your binary one).
>>>>>>>>>>>
>>>>>>>>>>> What makes all three of these valid evenness deciders is that they
>>>>>>>>>>> conform to the specification of an evenness decider:
>>>>>>>>>>>
>>>>>>>>>>> E.q0 S ⊦* E.qy if the *number* represented by the string S is even
>>>>>>>>>>> E.q0 S ⊦* E.qn otherwise.
>>>>>>>>>>>
>>>>>>>>>>> Yes, the TM maps a finite string to an accept/reject state, but this
>>>>>>>>>>> mapping is based on the property of the *number* which that string
>>>>>>>>>>> encodes. That number is not an input, but because it can be encoded
>>>>>>>>>>> as a string we can still legitimately expect a Turing Machine to
>>>>>>>>>>> answer questions about that number.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It can be construed as a property of the string.
>>>>>>>>>
>>>>>>>>> No. It cannot be. Properties of a string would include things like
>>>>>>>>> 'length', 'number of distinct symbols', 'is it a palindrome?', etc.
>>>>>>>>> Evenness is not one of those properties.
>>>>>>>>>
>>>>>>>>>>> Talking about a finite string as being even or odd is completely
>>>>>>>>>>> meaningless. Only numbers can be even or odd. Yet there is no problem
>>>>>>>>>>> in constructing such a decider.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The string has the "even binary integer" property.
>>>>>>>>>
>>>>>>>>> No. As soon as you start assigning numerical values to a string (or even
>>>>>>>>> to the individual symbols of a string) you are no longer treating it
>>>>>>>>> purely as a string. You are considering the information which is encoded
>>>>>>>>> in that string, which is a separate matter.
>>>>>>>>>
>>>>>>>> The all has to do with mathematicaly fomrmalizing semantic meanings.
>>>>>>>> Finite strings can have semantic properties.
>>>>>>>
>>>>>>> And just like the meaning assigned to the string "111␣" is the number 7, the meaning assigned to the string <H^><H^> is the turing machine H^ applied to <H^>.
>>>>>> Yes.
>>>>>
>>>>> Ah, so you're finally agreeing that the input <H^><H^> represents H^ applied to <H^>, and that therefore H applied to <H^><H^> is supposed determine if H^ applied to <H^> halts?
>>>> It represents a sequence of configurations.
>>>
>>> And that sequence of configurations is H^ applied to <H^> as per the stipulative definition of a halt decider:
>> The actual sequence of configurations specified by these three is not
>> the same thus the behavior can vary.
>>
>> H ⟨Ĥ⟩ ⟨Ĥ⟩
>> Ĥ ⟨Ĥ⟩
>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> You can simply assume that they must be the same, yet when you list them
>> you can see that they are not the same.
>
> By definition the input to H and embedded_H is the representation of Ĥ ⟨Ĥ⟩

None-the-less the above three are not the same sequence of steps and
this directly causes a significant difference in their behavior.

It is simpler to understand that this is the only thing that matters:

It is the case that the correctly simulated input to embedded_H can
never possibly reach its own final state under any condition at all.
Therefore embedded_H is necessarily correct to reject its input.

Even if you simply assume that it is not true:

You can verify the correctness of my reasoning by simply seeing what
this would prove if it was true. If embedded_H correctly decides ⟨Ĥ⟩ ⟨Ĥ⟩
then it refutes what Linz said was impossible.

--
Copyright 2022 Pete Olcott

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