On 5/27/22 7:21 PM, olcott wrote:
> On 5/27/2022 6:11 PM, Richard Damon wrote:
>> 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.
>>
>
> The ultimate measure of the behavior of an input its its correct
> emulation. If the input to H(P,P) calls H(P,P) then P must actually call
> H(P,P). If the fact that the input calls H(P,P) makes its correct x86
> emulation never reach its "ret" instruction then this is the behavior
> that H must report.
>

Right, its CORRECT emulation (not neccessarily the emulation done by
that machine), which for a Halt Decider is the emulation done by a UTM.

For H(P,P) that is Halting if H(P,P) returns 0.

Until you actually provide a valid different definition, that is the
definition we need to use.

Why do you say that P calling H means it never gets to the ret instruction.

Are you saying that H will NEVER return? Then how does H(P,P) be correct
returning 0 if it never returns?

You have a problem there. Either H(P,P) returns 0, and thus P will halt,
or H(P,P) never returns, making P non-halting, but also making H fail to
answer.

Until you can show that H(P,P) can be an actual computation and do two
different actions on different calls with the same parameter (which
violates one of the first theorem of Computation Theory) you are just
showing that H isn't actually a computation, or is wrong.

People won't just take some handwaving for something like that, it needs
a REAL proof, and probably an actual example, FULLY spelled out and
shown how it executes.

Neither lets it be a counter example.

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