On 5/27/22 6:52 PM, olcott wrote:
> On 5/27/2022 5:31 PM, André G. Isaak wrote:
>> On 2022-05-27 16:20, olcott wrote:
>>> On 5/27/2022 5:15 PM, André G. Isaak wrote:
>>>> On 2022-05-27 16:01, olcott wrote:
>>>>> On 5/27/2022 4:34 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 15:27, olcott wrote:
>>>>>>> On 5/27/2022 4:19 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 15:04, olcott wrote:
>>>>>>>>> On 5/27/2022 3:19 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:58, olcott wrote:
>>>>>>>>>>> On 5/27/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/27/22 2:59 PM, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 1:45 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-27 12:37, Andy Walker wrote:
>>>>>>>>>>>>>>> On 27/05/2022 18:57, André G. Isaak wrote:
>>>>>>>>>>>>>>>> The (positive) square root function you talk about maps
>>>>>>>>>>>>>>>> real numbers
>>>>>>>>>>>>>>>> (not scrambled eggs and not finite strings) to real
>>>>>>>>>>>>>>>> numbers (again,
>>>>>>>>>>>>>>>> not finite string). Unlike the prime() function,
>>>>>>>>>>>>>>>> however, the
>>>>>>>>>>>>>>>> positive square root function is NOT computable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      Um.  This is technically true, but [IMO] misleading.
>>>>>>>>>>>>>>> The reason
>>>>>>>>>>>>>>> for the failure is that most [indeed, almost all] real
>>>>>>>>>>>>>>> numbers are not
>>>>>>>>>>>>>>> computable.  But non-computable reals are of [almost] no
>>>>>>>>>>>>>>> interest for
>>>>>>>>>>>>>>> practical applied maths and theoretical physics, and are
>>>>>>>>>>>>>>> the sorts of
>>>>>>>>>>>>>>> object that give maths a bad name in the outside world.
>>>>>>>>>>>>>>> If "x" is a
>>>>>>>>>>>>>>> computable positive real, then "sqrt(x)" is also a
>>>>>>>>>>>>>>> computable real [eg
>>>>>>>>>>>>>>> by using Newton-Raphson], which is all you really have
>>>>>>>>>>>>>>> any right to
>>>>>>>>>>>>>>> expect.  If you can't compute "x", then what does it even
>>>>>>>>>>>>>>> mean to talk
>>>>>>>>>>>>>>> about its "sqrt"?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All I was really trying to get Olcott to see was a case
>>>>>>>>>>>>>> where it really *isn't* possible to encode all elements of
>>>>>>>>>>>>>> the domain or codomain as finite strings, which is rather
>>>>>>>>>>>>>> different from his strange claim that computations like
>>>>>>>>>>>>>> P(P) cannot be encoded as finite strings.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Computations like P(P) can be encoded as finite string
>>>>>>>>>>>>> inputs to H1, they cannot be encoded as finite string
>>>>>>>>>>>>> inputs to H simply because the behavior specified by the
>>>>>>>>>>>>> correctly emulated input to H(P,P) is entirely different
>>>>>>>>>>>>> behavior than the correctly emulated input to H1(P,P).
>>>>>>>>>>>>>
>>>>>>>>>>>>> We don't even need to understand why this is the case we
>>>>>>>>>>>>> only need to understand that it is a verified fact.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If P(P) can't be encoded to give to H, then H fails to be a
>>>>>>>>>>>> (Universal) Halt Decider from the begining, and can't be a
>>>>>>>>>>>> counter example.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not at all. Halt deciders have sequences of configurations
>>>>>>>>>>> encoded as finite strings as the domain of their computable
>>>>>>>>>>> function.
>>>>>>>>>>
>>>>>>>>>> This is an entirely mangled sentence. You really need to go
>>>>>>>>>> back to the basics:
>>>>>>>>>>
>>>>>>>>>> First, a Turing Machine is *NOT* a computable function.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A Turing machine would compute only the inputs to a its
>>>>>>>>> corresponding computable function that can be encoded as finite
>>>>>>>>> strings.
>>>>>>>>
>>>>>>>> Computable functions don't have inputs, they have domains. And
>>>>>>>> *all* of the elements in the domain of a computable function can
>>>>>>>> be encoded as finite string. Otherwise it wouldn't be a
>>>>>>>> computable function.
>>>>>>>>
>>>>>>>
>>>>>>>       Computable functions are the basic objects of study in
>>>>>>> computability theory.
>>>>>>>       Computable functions are the formalized analogue of the
>>>>>>> intuitive notion of
>>>>>>>       algorithms, in the sense that a function is computable if
>>>>>>> there exists an algorithm
>>>>>>>       that can do the job of the function, i.e. given an input of
>>>>>>> the function domain it
>>>>>>>       can return the corresponding output.
>>>>>>>       https://en.wikipedia.org/wiki/Computable_function
>>>>>>> *I am going by the above*
>>>>>>
>>>>>> No. You're going by your *flawed* reading of the above. In the
>>>>>> above paragraph it is the algorithm which has an input,
>>>>>
>>>>> *input of the function domain*
>>>>
>>>> What that means is "input [to the algorithm] of [i.e. taken from]
>>>> the function domain".
>>> Thus mandating a bijection to finite strings.
>>
>> There is no bijection (and bijections hold between things, not to
>> things). Every element of the function's domain can potentially be
>> encoded in an infinite number of different ways. And this has no
>> relevance to the particular confusion of yours that I was pointing out.
>>
>> André
>>
>>
>
> The simpler way around all this is to deduce that set of possible inputs
> to a TM halt decider is the set of Turing machine descriptions.
>
> This is fairly widely known as an aspect of the definition of a halt
> decider.
>

Right, so H can be given the description of ANY Turing Machine (even H^)
and an input for that, and needs to decide what that the Turing Machine
that input describes, applied to that input would do (Halt or Not) and
give the right answer to be correct.

THus H applied to <H^> <H^> has been given a VALID input, and needs to
output if H^ applied to <H^> would halt or not. (here <> means a
description of, being a finite string representation of the machine
within the <>s)