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.

> Second, A function (computable or otherwise) is NOT a Turing Machine.
>
> Third, the domain of a computable function is NOT the same thing as the
> input (or set of possible inputs) to a Turing Machine.
>

A computable function only includes inputs in the domain of the function
that can be encoded as finite strings.

Any inputs that cannot be encoded as finite strings are excluded from
the domain of computable functions.

> Until you actually get clear in your head the difference between a
> Turing Machine and a computable function and how the two are related,
> you really have no business make any claims whatsoever about the halting
> problem. Once you get that distinction straight we can move on to:
>

--
Copyright 2022 Pete Olcott

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

On 5/27/22 5:04 PM, 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.
>
>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>
>> Third, the domain of a computable function is NOT the same thing as
>> the input (or set of possible inputs) to a Turing Machine.
>>
>
> A computable function only includes inputs in the domain of the function
> that can be encoded as finite strings.
>
> Any inputs that cannot be encoded as finite strings are excluded from
> the domain of computable functions.

And P / H^ is encoded as a finite string, so is in the domain of the
function.

(You make it TOO small, but there is a finite string that represents it
as long as H is a proper computation too).

>
>
>> Until you actually get clear in your head the difference between a
>> Turing Machine and a computable function and how the two are related,
>> you really have no business make any claims whatsoever about the
>> halting problem. Once you get that distinction straight we can move on
>> to:
>>
>
>
>

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.

>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>
>> Third, the domain of a computable function is NOT the same thing as
>> the input (or set of possible inputs) to a Turing Machine.
>>
>
> A computable function only includes inputs in the domain of the function
> that can be encoded as finite strings.

Computable functions don't "include" inputs at all. You are writing in
gibberish.

> Any inputs that cannot be encoded as finite strings are excluded from
> the domain of computable functions.

Again, pure gibberish.

You *really* do not understand what terms like 'function', 'domain',
'input', 'logic', 'proof', etc. actually mean. You need to learn the
basic terminology before any sort of meaningful discussion is possible.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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*

>>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>>
>>> Third, the domain of a computable function is NOT the same thing as
>>> the input (or set of possible inputs) to a Turing Machine.
>>>
>>
>> A computable function only includes inputs in the domain of the
>> function that can be encoded as finite strings.
>
> Computable functions don't "include" inputs at all. You are writing in
> gibberish.

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.

>
>> Any inputs that cannot be encoded as finite strings are excluded from
>> the domain of computable functions.
>
> Again, pure gibberish.
>
> You *really* do not understand what terms like 'function', 'domain',
> 'input', 'logic', 'proof', etc. actually mean. You need to learn the
> basic terminology before any sort of meaningful discussion is possible.
>
> André
>

--
Copyright 2022 Pete Olcott

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

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, not the function. Any
arbitrary element of the functions domain can be used as an input to the
algorithm once suitably encoded.

>
>>>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>>>
>>>> Third, the domain of a computable function is NOT the same thing as
>>>> the input (or set of possible inputs) to a Turing Machine.
>>>>
>>>
>>> A computable function only includes inputs in the domain of the
>>> function that can be encoded as finite strings.
>>
>> Computable functions don't "include" inputs at all. You are writing in
>> gibberish.
>
>
>    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.

And where does the above entail that computable functions "include" inputs?

You need to actually understand a paragraph before you can use it to
support a position. To do that you need to know the terminology used in
the paragraph. You're still struggling with the latter so will never get
to the former.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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*

> not the function. Any
> arbitrary element of the functions domain can be used as an input to the
> algorithm once suitably encoded.
>

Sure and if it can't be suitably encoded it is excluded.

P(P) is suitably encoded as the actual machine language of P when
directly executed as P(P) or emulated by H1(P,P).

That its correct x86 emulation by H(P,P) differs from its correct x86
emulation by H1(P,P) is simply an established fact.

H is not supposed to compute the mapping from its input to its accept or
reject state on the basis of what you imagine its behavior should be.

Instead it must compute this mapping on the basis of what its correct
x86 emulation actually is.

>>
>>>>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>>>>
>>>>> Third, the domain of a computable function is NOT the same thing as
>>>>> the input (or set of possible inputs) to a Turing Machine.
>>>>>
>>>>
>>>> A computable function only includes inputs in the domain of the
>>>> function that can be encoded as finite strings.
>>>
>>> Computable functions don't "include" inputs at all. You are writing
>>> in gibberish.
>>
>>
>>     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.
>
> And where does the above entail that computable functions "include" inputs?
>
> You need to actually understand a paragraph before you can use it to
> support a position. To do that you need to know the terminology used in
> the paragraph. You're still struggling with the latter so will never get
> to the former.
>
> André
>

--
Copyright 2022 Pete Olcott

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

On 5/27/22 6:01 PM, 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*
>
>> not the function. Any arbitrary element of the functions domain can be
>> used as an input to the algorithm once suitably encoded.
>>
>
> Sure and if it can't be suitably encoded it is excluded.

Says what?

And H^/P can be suitably encoded, you have shown a suitable encoding of P

>
> P(P) is suitably encoded as the actual machine language of P when
> directly executed as P(P) or emulated by H1(P,P).
>
> That its correct x86 emulation by H(P,P) differs from its correct x86
> emulation by H1(P,P) is simply an established fact.
>

By?

What changed the "Correct x86 emulaton"? Its the same program.

> H is not supposed to compute the mapping from its input to its accept or
> reject state on the basis of what you imagine its behavior should be.

Not "imagined", SPECIFIED.

>
> Instead it must compute this mapping on the basis of what its correct
> x86 emulation actually is.

And has been noted, CORRECT EMULATION shows HALTING.

Only H's INCORRECT (because it is incomplete) emulation shows
not-yet-halted, and its unsound/invalid logic deduced non-halting.

>
>>>
>>>>>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>>>>>
>>>>>> Third, the domain of a computable function is NOT the same thing
>>>>>> as the input (or set of possible inputs) to a Turing Machine.
>>>>>>
>>>>>
>>>>> A computable function only includes inputs in the domain of the
>>>>> function that can be encoded as finite strings.
>>>>
>>>> Computable functions don't "include" inputs at all. You are writing
>>>> in gibberish.
>>>
>>>
>>>     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.
>>
>> And where does the above entail that computable functions "include"
>> inputs?
>>
>> You need to actually understand a paragraph before you can use it to
>> support a position. To do that you need to know the terminology used
>> in the paragraph. You're still struggling with the latter so will
>> never get to the former.
>>
>> André
>>
>
>

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

>> not the function. Any arbitrary element of the functions domain can be
>> used as an input to the algorithm once suitably encoded.
>>
>
> Sure and if it can't be suitably encoded it is excluded.

But if there exist elements of the domain which cannot be suitably
encoded then we aren't dealing with a computable function in the first
place. By specifying that the function is computable it is implied that
*every* element of the domain *can* be suitably encoded.

> P(P) is suitably encoded as the actual machine language of P when
> directly executed as P(P) or emulated by H1(P,P).
>
> That its correct x86 emulation by H(P,P) differs from its correct x86
> emulation by H1(P,P) is simply an established fact.
>
> H is not supposed to compute the mapping from its input to its accept or
> reject state on the basis of what you imagine its behavior should be.
>
> Instead it must compute this mapping on the basis of what its correct
> x86 emulation actually is.

You really need to learn what the halting function (as opposed to a halt
decider -- you consistently confuse the two) actually is. A function
(computable or otherwise) is simply a *fixed* mapping from a domain to a
codomain. Crucially, a function exists *entirely* independently of any
Turing Machine, computer program, or any other type of algorithm.

When we ask whether a function is computable, we're asking whether an
algorithm exists which can compute that function, but the function IS
ALREADY THERE. THE MAPPING ALREADY EXISTS AND IS FIXED. The Mapping is
what it is regardless of which algorithm you use to compute it or
whether such an algorithm exists at all.

So if H(P, P) == false and H1(P, P) == true then either

(a) One of these is wrong, or

(b) H() and H1() are *not* computing the same function which means they
cannot *both* be halt deciders.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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.

--
Copyright 2022 Pete Olcott

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

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é

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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.

--
Copyright 2022 Pete Olcott

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

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)

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

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

On 5/28/2022 11:25 AM, Malcolm McLean wrote:
> On Saturday, 28 May 2022 at 13:18:28 UTC+1, Andy Walker wrote:
>> On 28/05/2022 11:46, Mikko wrote:
>>> On 2022-05-28 08:41:42 +0000, Malcolm McLean said:
>> [... various restrictions ...]
>>>> Now, unless I've nodded, I ought to be able to produce a very simple Turing
>>>> machine which solves the halting problem for this domain.
>>> You must also exclude directly and indirectly recursive functions.
>>> In addition, the loop variable of a for loop must not be modified
>>> in the loop and its address must not be given to a function that
>>> does not promise to regard it as an address to a constant.
>> What the pair of you are saying is, in effect, that there is a
>> significant subset of programs which are guaranteed to halt, and for
>> which the HP is therefore trivial. Such programs even include many of
>> practical [eg engineering] interest. This is true, and uncontroversial.
>> There are also significant subsets of programs which are guaranteed not
>> to halt [at least in normal circumstances and short of hardware failure
>> or intervention]. But, no matter how you slice and dice, there is also
>> a substantial subset of programs whose behaviour cannot be determined
>> by an algorithmic examination of the code [inc input]; and the attack
>> on the HP via emulation and Busy Beavers shows clearly that a lot of
>> /very/ simple programs, and indeed problems, fall into this category.
>> [Not least because a UTM is a very simple program, and any complexity
>> relates to its input, which /could/ be a representation of a UTM and
>> /its/ input, which could be ....]
>>
>> As ever, although the HP is expressed in terms of halting, it
>> equally applies to problems such as "Does my program ever reach line
>> 23?", or "Does it ever produce any output?" or "Does it produce the
>> same output as your program?", which may be of more practical interest.
>> Yes, in line with what Malcolm is proposing, it's possible to produce
>> analysers, perhaps even of commercial interest, which often say useful
>> things about some code; but there are always areas of doubt, and
>> every time you explore one of these another can of worms opens up.
>>
>> A partial answer for practical programming lies in disciplined
>> code, with carefully designed pre- and post-conditions, etc., etc. But
>> that doesn't help with programs written without that discipline, and it
>> doesn't help to solve the Goldbach Conjecture.
>>
> PO seemed to be going down the route of saying that some programs
> are not in the domain of his halt decider. Whilst that prompted ridicule,
> it's not actually an inherently bad approach, depending what you want
> to achieve.

A halt decider must only compute the mapping from its input to an accept
or reject state based on the actual behavior specified by this input.

NON-INPUTS DO NOT COUNT
NON-INPUTS DO NOT COUNT
NON-INPUTS DO NOT COUNT

It is the case that the correct x86 emulation of the input to H(P,P) by
H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
proved to be correct.

--
Copyright 2022 Pete Olcott

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

On 5/28/22 12:31 PM, olcott wrote:
> On 5/28/2022 11:25 AM, Malcolm McLean wrote:
>> On Saturday, 28 May 2022 at 13:18:28 UTC+1, Andy Walker wrote:
>>> On 28/05/2022 11:46, Mikko wrote:
>>>> On 2022-05-28 08:41:42 +0000, Malcolm McLean said:
>>> [... various restrictions ...]
>>>>> Now, unless I've nodded, I ought to be able to produce a very
>>>>> simple Turing
>>>>> machine which solves the halting problem for this domain.
>>>> You must also exclude directly and indirectly recursive functions.
>>>> In addition, the loop variable of a for loop must not be modified
>>>> in the loop and its address must not be given to a function that
>>>> does not promise to regard it as an address to a constant.
>>> What the pair of you are saying is, in effect, that there is a
>>> significant subset of programs which are guaranteed to halt, and for
>>> which the HP is therefore trivial. Such programs even include many of
>>> practical [eg engineering] interest. This is true, and uncontroversial.
>>> There are also significant subsets of programs which are guaranteed not
>>> to halt [at least in normal circumstances and short of hardware failure
>>> or intervention]. But, no matter how you slice and dice, there is also
>>> a substantial subset of programs whose behaviour cannot be determined
>>> by an algorithmic examination of the code [inc input]; and the attack
>>> on the HP via emulation and Busy Beavers shows clearly that a lot of
>>> /very/ simple programs, and indeed problems, fall into this category.
>>> [Not least because a UTM is a very simple program, and any complexity
>>> relates to its input, which /could/ be a representation of a UTM and
>>> /its/ input, which could be ....]
>>>
>>> As ever, although the HP is expressed in terms of halting, it
>>> equally applies to problems such as "Does my program ever reach line
>>> 23?", or "Does it ever produce any output?" or "Does it produce the
>>> same output as your program?", which may be of more practical interest.
>>> Yes, in line with what Malcolm is proposing, it's possible to produce
>>> analysers, perhaps even of commercial interest, which often say useful
>>> things about some code; but there are always areas of doubt, and
>>> every time you explore one of these another can of worms opens up.
>>>
>>> A partial answer for practical programming lies in disciplined
>>> code, with carefully designed pre- and post-conditions, etc., etc. But
>>> that doesn't help with programs written without that discipline, and it
>>> doesn't help to solve the Goldbach Conjecture.
>>>
>> PO seemed to be going down the route of saying that some programs
>> are not in the domain of his halt decider. Whilst that prompted ridicule,
>> it's not actually an inherently bad approach, depending what you want
>> to achieve.
>
>
> A halt decider must only compute the mapping from its input to an accept
> or reject state based on the actual behavior specified by this input.
>
> NON-INPUTS DO NOT COUNT
> NON-INPUTS DO NOT COUNT
> NON-INPUTS DO NOT COUNT
>
> It is the case that the correct x86 emulation of the input to H(P,P) by
> H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
> proved to be correct.
>

And in what way is the "representation" or P/H^ not an input?

The problem is Given a representation, determine the halitng behavior.
Thus the behavior of the machine represented by the input not a
"non-input" but the goal of the decider itself. If it isn't, then it
isn't a Halt Decider.

"The Actual Behavior specified by this input" for H(M,w) is the behavior
of M(w) BY DEFINITION, so this CAN'T be just defined as a "NON-INPUT",
unless you want to just define that Halt Decider just can't exist.

FAIL.