On 3/12/2022 7:03 PM, André G. Isaak wrote:
> On 2022-03-12 17:17, olcott wrote:
>> On 3/12/2022 5:57 PM, André G. Isaak wrote:
>>> On 2022-03-12 16:25, olcott wrote:
>>>> On 3/12/2022 3:33 PM, André G. Isaak wrote:
>>>>> On 2022-03-12 14:14, olcott wrote:
>>>>>> On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>>>>>>>>
>>>>>>>>>>> So you now know that everyone accepts that "deciders compute
>>>>>>>>>>> only a
>>>>>>>>>>> function from input strings to accept/reject states"
>>>>>>>>
>>>>>>>> This is good.
>>>>>>>>
>>>>>>>>> and you also also
>>>>>>>>>>> now know that "deciders /are/ capable of reporting on the
>>>>>>>>>>> behavior of
>>>>>>>>>>> Turing machines".
>>>>>>>>
>>>>>>>> This contradicts the prior sentence:
>>>>>>>> (a) A decider only takes finite string inputs. // prior sentence
>>>>>>>> (b) A decider takes Turing machine (thus non-finite string)
>>>>>>>> inputs. //
>>>>>>>> current sentence
>>>>>>>
>>>>>>> I can't help with your poor comprehension of English.
>>>>>>>
>>>>>>
>>>>>> A decider cannot take a Turing machine as input and you know it.
>>>>>
>>>>> Nowhere does he deny this.
>>>>>
>>>>>> It can only take a finite string that specifies a Turing machine.
>>>>>
>>>>> Right. A finite string THAT SPECIFIES A TURING MACHINE.
>>>>>
>>>>> IOW, it is given a string which provides all of the information
>>>>> necessary to identify some unique Turing Machine. So while a TM
>>>>> cannot take a Turing Machine as an input, it can still answer
>>>>> questions about Turing Machines.
>>>>>
>>>>
>>>> It is not actually answering the question about a Turing machine.
>>>> It is answering the question about the Turing machine specified by
>>>> the finite string, this distinction is crucial, and even Linz missed
>>>> it.
>>>
>>> The Turing Machine specified by the finite string *is* a Turing
>>> Machine, so yes it is answering the question about a Turing Machine.
>
> Can I take your silence here as an acknowledgment that what you had
> written was an error (and a very silly one at that)?
>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> Everyone here (and Linz) believes that the copy of H embedded at
>>>> Ĥ.qx is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. This
>>>> is off by exactly one level of indirection.
>>>
>>> That's exactly what the copy of H embedded at Ĥ.qx is supposed to
>>> report on by the very definition of the problem.
>
> No Comment?
>
>>> A halt decider must, *by definition*, be able to determine the
>>> halting status of *any* arbitrary computation, so if you want to
>>> claim that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a computation different from Ĥ applied to
>>> ⟨Ĥ⟩, then you'd better be able to show how that latter computation is
>>> to be encoded as a finite string.
>>>
>>> So what string, according to you, encodes the computation Ĥ applied
>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate
>>> encodings as strings then they are not, in fact, different
>>> computations at all.
>
> No Comment?
>
> I know you've been asked this question before and have consistently
> ignored it. According to a recent post of yours that constitutes
> justification for a repetitive all-caps temper tantrum!
>
>>>
>>>> No decider is ever supposed to report on the behavior of the
>>>> computation that contains its actual self. Deciders only report on
>>>> the behavior specified by Turing machine descriptions.
>>>
>>> No, it is supposed to report on the halting status of the computation
>>> represented by its input. But nothing in the definition of 'halt
>>> decider' precludes it from being given a description of a computation
>>> which contains its actual self. If it can't answer about that
>>> question, then it isn't meeting the definition of a halt decider
>>> which must be able to answer about *any* computation. And in the Linz
>>> proof this is precisely what the input specifies, your nonsense about
>>> the input being a string rather than an actual Turing Machine
>>> notwithstanding.
>
> Again, is your silence a recognition that you know see your error?
>
>>>>
>>>>> That's a fairly fundamental concept in computational theory which
>>>>> you seem determined to not understand.
>>>>>
>>>>> Turing Machines only deal with strings. This means that a function
>>>>> can only be computed if (as a minimal requirement) the elements of
>>>>> that domain can be ENCODED as strings. If you can encoded elements
>>>>> of some domain as strings, then it might be possible for a TM to
>>>>> compute that function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES
>>>>> STRINGS.
>>>>>
>>>>> Integers are not strings, but many functions from integers to
>>>>> integers are computable by virtue of the fact that it is trivially
>>>>> easy to devise ways of encoding integers as strings.
>>>>>
>>>>> Functions from reals to reals, on the other hand, are not going to
>>>>> be computable precisely because the overwhelming majority of real
>>>>> numbers cannot be encoded as finite strings. A function like y = √x
>>>>> is not computable, but one can compute some function that is
>>>>> "close" to this but that limits the input/output to some arbitary
>>>>> degree of precision.
>>>>>
>>>>> The set of Turing Machines is provably DENUMERABLE. That means that
>>>>> one can encode TMs as finite strings. Which in turn means that a TM
>>>>> *can* answer questions about Turing Machines. They just have to be
>>>>> encoded as finite strings before being given to a Turing Machine.
>>>>>
>>>>> Strings which encode Turing Machines and inputs don't halt anymore
>>>>> than strings which encode integers have sums.
>>>>
>>>> The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>> reaches its final state of ⟨Ĥ⟩.qn in any finite number of correctly
>>>> simulated steps by the copy of H embedded at Ĥ.qx.
>>>
>>> Finite string pairs don't *have* final states.
>>
>> Simulated finite string pairs ⟨Ĥ⟩ ⟨Ĥ⟩ have final states that can
>> either be reached in a finite number of simulated steps or not.
>

I am ignoring all of your other points because this single point is the
crux of the whole issue and all the other points are tangential.

> The *simulation* has states which may include final states. The string
> itself does not.

A BASIC program that is executed in an interpreter is correctly
construed as reaching its final state.

10 PRINT "Hello, World!"
20 END

⟨Ĥ⟩ ⟨Ĥ⟩ is executed within the simulator of the copy of H embedded
within Ĥ. This embedded_H has all of the functionality of a UTM along
with additional functionality.

> But SIMULATOR applied to ⟨Ĥ⟩ ⟨Ĥ⟩ and Ĥ applied to ⟨Ĥ⟩
> are distinct computations which thus must be encodable by distinct
> finite strings.
>
> So are you now attempting to claim that the finite string ⟨Ĥ⟩ ⟨Ĥ⟩ is
> supposed to encode the computation SIMULATOR applied to ⟨Ĥ⟩ ⟨Ĥ⟩?
>
> If so, how do we encode Ĥ applied to ⟨Ĥ⟩ which is the computation that
> is actually of interest to us?
>
> André
>

It is impossible for any decider to correctly report on the behavior of
the computation that contains itself.

--
Copyright 2021 Pete Olcott

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