On 4/6/22 11:55 PM, olcott wrote:
> 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.

H and embedded_H can only differ in their sequence of steps if you are
LYING on what embedded_H is, as we never get to the state that has the
changes made.

That H^ <H^> differs is fine, because it is SUPPOSED to be a differen
machine, but it does need to be RELATED.

>
> 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.

WRONG. Correctly simulating the input to embedded_H will show that it
halts if embedded_H goes to Qn. That is simple to see.

The problem is that embedded_H is NOT the correct simulator if it is the
case that it goes to Qn, and you seem to be stuck on the idea that it is.

>
> 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.
>

IF it did, yes, but it doesn't. That is like saying that if my dog was a
cat, I can prove that cats bark.

You are assuming something that isn't true, which is the definition of
unsound logic, so you answer is unsound, and thus incorrect.

FAIL