On 5/27/2022 10:53 AM, Richard Damon wrote:
> On 5/27/22 11:24 AM, olcott wrote:
>> On 5/27/2022 7:50 AM, Richard Damon wrote:
>>> On 5/26/22 11:06 PM, olcott wrote:
>>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>
>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>
>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>> when all I
>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>>> report
>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>>> talking about.
>>>>>>>>>
>>>>>>>> To me, that's what retains the interest.
>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>> wouldn't they?
>>>>>>>>
>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>> program, and
>>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>>> thing must be dismissed.
>>>>>>>>
>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>
>>>>>>> There's no reason at all to think that H is /not/ correct.  But
>>>>>>> since H
>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>> don't see
>>>>>>> what's interesting about it being correct.  Do you really think it's
>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>
>>>>>>
>>>>>> The only reason that you do not see the significance of this is
>>>>>> that the depth of your understanding is learned-by-rote.
>>>>>>
>>>>>> Someone with a deeper understanding would realize that your
>>>>>> interpretation that a halt decider must compute its mapping from a
>>>>>> non-input would understand that this would violate the definition
>>>>>> of a computable function and the definition of a decider.
>>>>>
>>>>> No, it only CAN compute what can be determined by its processing of
>>>>> the input, but a "something" decider MUST compute the "something"
>>>>> mapping defined,
>>>> You just contradicted yourself.
>>>
>>> No, just shows you don't understand English.
>>>
>>> I am pointing out the difference between what something is ABLE to
>>> do, and what it is REQUIRED to do.
>>
>> You are requiring that a decider maps somethings that it does not
>> have, thus making your requirement incorrect. It is like I said give
>> me the $10 from your empty wallet.
>
> But it DOES have the representation of P, so it can map it.
>
The correctly simulated input to H(P,P)==0
The correctly simulated input to H1(P,P)==1

--
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 09:21, olcott wrote:
> On 5/27/2022 2:48 AM, Mikko wrote:
>> On 2022-05-26 13:35:31 +0000, olcott said:
>>
>>> Someone with a deeper understanding would realize that your
>>> interpretation that a halt decider must compute its mapping from a
>>> non-input would understand that this would violate the definition of
>>> a computable function and the definition of a decider.
>>
>> The definition of "decider" does not require much, only that it must halt
>> and indicate the decision. This is not violated by the definition of
>> "halt
>> decider".
>>
>
> 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
>
> P(P) is not in the domain of H because it is not an input to H.

Turing Machines don't have domains. Functions have domains.

A function is computable if it is possible to construct a Turing Machine
which computes that function. You don't seem to grasp what this actually
means.

Turing Machines take a finite string as their input, but very few of the
computations people are interested in computing have finite strings as
their domain. Integers, for example, are *not* finite strings, but many
functions over the domain of integers are perfectly computable.

To construct a turing machine which computes a function, one must first
establish a way of encoding the elements of the domain of that function
as finite strings. The elements themselves do *not* have to be finite
strings. They just need to be encodable as such so they can be passed to
a Turing Machine.

Ben asked you to create a specification for a Turing Machine which
decides whether integers are prime. You failed to be able to do this
very basic task. Part of that specification would have included how
exactly integers (non-strings) are to be encoded as strings so they can
be passed as inputs to the decider. There are many different ways of
doing this but it is perfectly doable.

Similarly, for a halt decider, part of the specification would include
information on exactly how computations (non-strings) can be encoded as
strings so they can be passed to the decider. If you can't figure out a
way of encoding P(P) as a string so that it can be passed to your
decider then either (a) you are incompetent or (b) the halting function
is not computable. Of course, these two options are not mutually exclusive.

You really ought to complete Ben's exercises. You might actually learn
something. I know you are highly adverse to the possibility of learning
things, but you may discover it to be both enlightening and useful.

André

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

On 5/27/22 11:54 AM, olcott wrote:
> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>
>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>> all I
>>>>> thought it worth doing was pointing out that if H(X,Y) does not report
>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>> talking about.
>>>>>
>>>> To me, that's what retains the interest.
>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>> wouldn't they?
>>>>
>>>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>>>> that they are refusing to provide the source, then really the whole
>>>> thing must be dismissed.
>>>>
>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>> reports non-halting, and they can prove that H is correct.
>>> There's no reason at all to think that H is /not/ correct. But since H
>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>> what's interesting about it being correct. Do you really think it's
>>> "deciding" some interesting property of the "input"?
>>>
>> I can't follow all the arguments, and they seem to shift over time.
>> But basically PO is trying to argue that H_Hat is an invalid input,
>> on the analogue that a sentence like "this sentence is false" isn't
>> a valid sentence.
>
> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or the
> current way of saying that input to H(P,P) specifies behavior to H that
> would never reach its under its correct x86 emulation by H.

But the question isn't does *H* reach the final state of the input in
its processing, it is does the computation the input represents reach
its final state.

You are just admitting to trying to answer the WRONG question.

>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> When the above is correctly emulated by H the first seven instructions
> are emulated then P calls H(P,P) which causes H to emulate the first
> seven instructions again. This infinite emulation never stops unless
> aborted. Whether or not it is aborted the emulated P never reaches its
> "ret" instruction thus never halts. The H(P,P)==0 is proved to be correct.
>

But H can't correctly emulate all of the input, and give an answer. That
is your problem

Again, what is your definition of "Correct emulation" here, it seems
different that that which is normally taken

>> He then makes the observation that a simulating halt decider will
>> be thrown into infinitely nested simulations by H_Hat. So its own
>> behaviour is what is problematical, not the "invert the answer"
>> step.
>
> It is that P calls H(P,P) that causes the nested emulation.
> It is not that H(P,P) emulates its input that causes this.
> P specifies infinite emulation to H.

Except P doesn't specify infinite emulation to H if H knowns that H can
abort its emulation.

>
>> I can't quite follow his next step of reasoning, which seems to be
>> that because H aborts itself (the simulated copy of itself which it
>> is running, which in PO's system is the identical same physical
>> machine code), the abort doesn't count as part of the behavior of
>
> H(P,P) does not abort itself it aborts its input which also aborts
> everything that this input invoked.
>

Right, which means that a P that calls this H gets the answer and
returns, showing it is Haling.

This also shows up in a CORRECT emulaton of the input, which H doesn't do.

>> the input. So "Non-halting" is correct even though H_Hat halts.
>
> This input does not halt (meaning that it has reached its "ret"
> instruction) it was aborted because it will never reach its "ret"
> instruction.
>
> _Infinite_Loop()
> [000012c2](01)  55              push ebp
> [000012c3](02)  8bec            mov ebp,esp
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c7](01)  5d              pop ebp
> [000012c8](01)  c3              ret
> Size in bytes:(0007) [000012c8]

Right, THIS input never halts

>
> The exact same process applies to the above _Infinite_Loop()

But P does Halt if correctly emulated, as your traces for H1 show.

>
>> PO will probably come in here as a mischaracterisation of his
>> position.
>>
>> A simulator is a perfectly reasonable program to write, and there are
>> many practical simulators. Adding a bit of simple loop detection to
>> a simulator is also a reasonable thing to do, and might be of practical
>> value. However it's not of much theoretical value, because however
>> complicated you make the loop detection, there will always be some
>> examples of unterminating loops it fails to catch.
>>
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own (x86) source
> and its input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> When I correctly determine the halt status of that input I have refuted
> all of the HP proofs.

Except you didn't. You say P(P) is non-halting when it halts.

You apparently just can't read a requirements document.

H needs to determine if the program its input represent will Halt, not
if its own simulation of that input will halt, because it doesn't
actualy need to do a simulation of the input.

>
>> I'm sceptical that PO's H detects nested simulation rather than
>> recursion,
>> partly because he himself said it was infinite recursion before I pointed
>> out that it was  not, and partly because nested simulation is more
>> challenging to detect, and he hasn't been forthcoming on how it is
>> achieved. But since has hasn't yet made H available, there's no way of
>> knowing.
>>
>
> The nested simulation pattern derives behavior precisely matching
> infinite recursion. If H(P,P) simulates its input (as in nested
> simulation) or directly executes its input (as in infinite recursion)
> the exact same behavior is derived to outside observers:
>
> If the execution trace of function H() called by function P() shows:
> (1) Function H() is called twice in sequence from the same machine
> address of P().
> (2) With the same parameters to H().
> (3) With no conditional branch or indexed jump instructions in P().
> (4) With no function call returns from H() to P().
> then the function call from P() to H() is infinitely recursive.

Nope, not proven.

(3) needs to include ALL the code in the computation P between the
loops, which includes the code in H. There is no exclusion for the
"system code" of H, because the copy of H that P calls is user code.

You just are proving you don't understand how programs work.

Can you provide a reference that states it YOUR way, allowing the
ignoring of the code in H?

I don't think so.

>
>> As for the "H_Hat is a form of invalid speech" argument, I don't really
>> understand the philosophy of maths, but I don't see it myself.
>>
>
> To sum it all up I show how H can treat its pathological input as an
> ordinary input and simply decide that this input never halts.
>

On 5/27/22 12:06 PM, olcott wrote:
> On 5/27/2022 10:53 AM, Richard Damon wrote:
>> On 5/27/22 11:24 AM, olcott wrote:
>>> On 5/27/2022 7:50 AM, Richard Damon wrote:
>>>> On 5/26/22 11:06 PM, olcott wrote:
>>>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>>
>>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>>> when all I
>>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does
>>>>>>>>>> not report
>>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone
>>>>>>>>>> else is
>>>>>>>>>> talking about.
>>>>>>>>>>
>>>>>>>>> To me, that's what retains the interest.
>>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>>> wouldn't they?
>>>>>>>>>
>>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>>> program, and
>>>>>>>>> that they are refusing to provide the source, then really the
>>>>>>>>> whole
>>>>>>>>> thing must be dismissed.
>>>>>>>>>
>>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>>
>>>>>>>> There's no reason at all to think that H is /not/ correct.  But
>>>>>>>> since H
>>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>>> don't see
>>>>>>>> what's interesting about it being correct.  Do you really think
>>>>>>>> it's
>>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>>
>>>>>>>
>>>>>>> The only reason that you do not see the significance of this is
>>>>>>> that the depth of your understanding is learned-by-rote.
>>>>>>>
>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>> interpretation that a halt decider must compute its mapping from
>>>>>>> a non-input would understand that this would violate the
>>>>>>> definition of a computable function and the definition of a decider.
>>>>>>
>>>>>> No, it only CAN compute what can be determined by its processing
>>>>>> of the input, but a "something" decider MUST compute the
>>>>>> "something" mapping defined,
>>>>> You just contradicted yourself.
>>>>
>>>> No, just shows you don't understand English.
>>>>
>>>> I am pointing out the difference between what something is ABLE to
>>>> do, and what it is REQUIRED to do.
>>>
>>> You are requiring that a decider maps somethings that it does not
>>> have, thus making your requirement incorrect. It is like I said give
>>> me the $10 from your empty wallet.
>>
>> But it DOES have the representation of P, so it can map it.
>>
> The correctly simulated input to  H(P,P)==0
> The correctly simulated input to H1(P,P)==1
>

HOW?

It is the same input, so has the same correct simulation.

Do you really expect people to believe that that SAME program, when
simulated by two diffetent "correct" simulators have different behavior?

What definition of "correct" are you using, it must be something besides
matching the actual behavior of the code given to it.

All you have done is proven that you H isn't a computation, and thus not
eligible to be a decider.

FAIL

On 5/27/22 12:04 PM, olcott wrote:
> On 5/27/2022 10:52 AM, Malcolm McLean wrote:
>> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>>> On 5/27/22 11:21 AM, olcott wrote:
>>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>>
>>>>>> Someone with a deeper understanding would realize that your
>>>>>> interpretation that a halt decider must compute its mapping from a
>>>>>> non-input would understand that this would violate the definition of
>>>>>> a computable function and the definition of a decider.
>>>>>
>>>>> The definition of "decider" does not require much, only that it
>>>>> must halt
>>>>> and indicate the decision. This is not violated by the definition of
>>>>> "halt
>>>>> decider".
>>>>>
>>>>
>>>> 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
>>>>
>>>> P(P) is not in the domain of H because it is not an input to H.
>>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>>> argument on that.
>>>
>>> The representation of P, in your case the object code of it. contains
>>> all the data needed to determine the behavior of that computation, and
>>> thus IS in the domain of H.
>>>
>>> In fact, saying that the representation of P(P) is not in the domain of
>>> H is, by itself, enough to prove that H can not be a correct halt
>>> decider.
>>>
>>> You are just digging a deeper hole for yourself.
>>>
>>> You are just proving your ignorance.
>>>
>>> If H claims to be a Halt Decider, then we need to be able to ask it
>>> about any computation, how do we ask it about P(P).
>>>
>>> If we can't, then it isn't one.
>>>
>> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
>> would in fact achieve PO's broader objectives. It wouldn't "solve the
>> halting problem", but it would redefine it for future workers.
>>
>
> Halt decider are required to decide the halt status of any finite
> strings that specify a sequence of configurations.
>
> Halt deciders are not required to decide that halt status of finite
> strings of English poems nor are they required to compute the halt
> status of anything that is not an input finite string.
>
> For example H is not required to compute the halt status of the behavior
> that a person imagines that P(P) has. H(P,P) is only required to compute
> the halt state that its input actually specifies.
>
>> However the question is how to do this in an interesting way. As Ben
>> says,
>> a lot of students, when introduced to this material, say "why not detect
>> the H_Hat(H_Hat) pattern and special case it?". It's a natural reaction.
>> But when you think about it a bit more deeply, you'll see that this
>> strategy
>> doesn't work.
>>
>
> It does work when H is defined to recognize the whole infinite recursion
> pattern. I threw in infinite loops for good measure.
>

Except there is no such universal correct pattern.

This is shown by the fact that H(P.P) says Non-Halting when P(P) Halts,
showing that H was wrong.

On 5/27/2022 11:08 AM, André G. Isaak wrote:
> On 2022-05-27 09:21, olcott wrote:
>> On 5/27/2022 2:48 AM, Mikko wrote:
>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>
>>>> Someone with a deeper understanding would realize that your
>>>> interpretation that a halt decider must compute its mapping from a
>>>> non-input would understand that this would violate the definition of
>>>> a computable function and the definition of a decider.
>>>
>>> The definition of "decider" does not require much, only that it must
>>> halt
>>> and indicate the decision. This is not violated by the definition of
>>> "halt
>>> decider".
>>>
>>
>> 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
>>
>> P(P) is not in the domain of H because it is not an input to H.
>
> Turing Machines don't have domains. Functions have domains.
>

So maybe you will be able to think of the proper way that I can say
this. Computable functions have domains that can only be computed by an
algorithm on the basis of finite strings thus every input that cannot be
encoded as a finite string is necessarily not in the domain of the
computable function.

> A function is computable if it is possible to construct a Turing Machine
> which computes that function. You don't seem to grasp what this actually
> means.
>

When we try to make a computable function that calculates the square
root of a plate of scrambled eggs we find a type mismatch error because
scrambled eggs have no numeric property.

> Turing Machines take a finite string as their input, but very few of the
> computations people are interested in computing have finite strings as
> their domain.

If an input cannot be encoded as a finite string then it is invalid
input to any algorithm.

> Integers, for example, are *not* finite strings, but many
> functions over the domain of integers are perfectly computable.
>
> To construct a turing machine which computes a function, one must first
> establish a way of encoding the elements of the domain of that function
> as finite strings. The elements themselves do *not* have to be finite
> strings. They just need to be encodable as such so they can be passed to
> a Turing Machine.
>

Yes. The sequence of configurations specified by P(P) cannot be encoded
as a finite string input to H.

H(P,P) is only required to map its input to an accept or reject state
based on the actual behavior specified by this actual input.

H is not allowed to consider any behavior besides the actual behavior
actually specified by its actual inputs.

> Ben asked you to create a specification for a Turing Machine which
> decides whether integers are prime. You failed to be able to do this
> very basic task. Part of that specification would have included how
> exactly integers (non-strings) are to be encoded as strings so they can
> be passed as inputs to the decider. There are many different ways of
> doing this but it is perfectly doable.
>

It had a smaller scope then this and I will get back to this soon. I was
too sick last week when my immune system was disabled by chemotherapy.

> Similarly, for a halt decider, part of the specification would include
> information on exactly how computations (non-strings) can be encoded as
> strings so they can be passed to the decider. If you can't figure out a
> way of encoding P(P) as a string so that it can be passed to your
> decider then either (a) you are incompetent or (b) the halting function
> is not computable. Of course, these two options are not mutually exclusive.
>

Or the problem is asking for something like the square root of a plate
of scrambled eggs. This makes the problem specification incorrect.

The set of valid inputs to the algorithm that computes the halt status
of its inputs is the set of sequences of configurations that can be
encoded as finite string inputs to H.

> You really ought to complete Ben's exercises. You might actually learn
> something. I know you are highly adverse to the possibility of learning
> things, but you may discover it to be both enlightening and useful.
>
> 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/2022 12:00 PM, Richard Damon wrote:
>
> On 5/27/22 11:54 AM, olcott wrote:
>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>
>>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>>> all I
>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>> report
>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>> talking about.
>>>>>>
>>>>> To me, that's what retains the interest.
>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>> wouldn't they?
>>>>>
>>>>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>>>>> that they are refusing to provide the source, then really the whole
>>>>> thing must be dismissed.
>>>>>
>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>> reports non-halting, and they can prove that H is correct.
>>>> There's no reason at all to think that H is /not/ correct. But since H
>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>> what's interesting about it being correct. Do you really think it's
>>>> "deciding" some interesting property of the "input"?
>>>>
>>> I can't follow all the arguments, and they seem to shift over time.
>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>> on the analogue that a sentence like "this sentence is false" isn't
>>> a valid sentence.
>>
>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>> the current way of saying that input to H(P,P) specifies behavior to H
>> that would never reach its under its correct x86 emulation by H.
>
> But the question isn't does *H* reach the final state of the input in
> its processing, it is does the computation the input represents reach
> its final state.
>
> You are just admitting to trying to answer the WRONG question.

Does the correct simulation of the input to H(P,P) ever reach its "ret"
instruction? No, therfore non-halting.

>
>>
>> _P()
>> [00001352](01)  55              push ebp
>> [00001353](02)  8bec            mov ebp,esp
>> [00001355](03)  8b4508          mov eax,[ebp+08]
>> [00001358](01)  50              push eax      // push P
>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>> [0000135c](01)  51              push ecx      // push P
>> [0000135d](05)  e840feffff      call 000011a2 // call H
>> [00001362](03)  83c408          add esp,+08
>> [00001365](02)  85c0            test eax,eax
>> [00001367](02)  7402            jz 0000136b
>> [00001369](02)  ebfe            jmp 00001369
>> [0000136b](01)  5d              pop ebp
>> [0000136c](01)  c3              ret
>> Size in bytes:(0027) [0000136c]
>>
>> When the above is correctly emulated by H the first seven instructions
>> are emulated then P calls H(P,P) which causes H to emulate the first
>> seven instructions again. This infinite emulation never stops unless
>> aborted. Whether or not it is aborted the emulated P never reaches its
>> "ret" instruction thus never halts. The H(P,P)==0 is proved to be
>> correct.
>>
>
> But H can't correctly emulate all of the input, and give an answer. That
> is your problem
>

The set of valid inputs to the algorithm that computes the halt status
of its inputs is the set of sequences of configurations that can be
encoded as finite string inputs to H.

--
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/2022 12:03 PM, Richard Damon wrote:
> On 5/27/22 12:06 PM, olcott wrote:
>> On 5/27/2022 10:53 AM, Richard Damon wrote:
>>> On 5/27/22 11:24 AM, olcott wrote:
>>>> On 5/27/2022 7:50 AM, Richard Damon wrote:
>>>>> On 5/26/22 11:06 PM, olcott wrote:
>>>>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>>>
>>>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>>>> when all I
>>>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does
>>>>>>>>>>> not report
>>>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone
>>>>>>>>>>> else is
>>>>>>>>>>> talking about.
>>>>>>>>>>>
>>>>>>>>>> To me, that's what retains the interest.
>>>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H
>>>>>>>>>> such
>>>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>>>> wouldn't they?
>>>>>>>>>>
>>>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>>>> program, and
>>>>>>>>>> that they are refusing to provide the source, then really the
>>>>>>>>>> whole
>>>>>>>>>> thing must be dismissed.
>>>>>>>>>>
>>>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>>>
>>>>>>>>> There's no reason at all to think that H is /not/ correct.  But
>>>>>>>>> since H
>>>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>>>> don't see
>>>>>>>>> what's interesting about it being correct.  Do you really think
>>>>>>>>> it's
>>>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The only reason that you do not see the significance of this is
>>>>>>>> that the depth of your understanding is learned-by-rote.
>>>>>>>>
>>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>>> interpretation that a halt decider must compute its mapping from
>>>>>>>> a non-input would understand that this would violate the
>>>>>>>> definition of a computable function and the definition of a
>>>>>>>> decider.
>>>>>>>
>>>>>>> No, it only CAN compute what can be determined by its processing
>>>>>>> of the input, but a "something" decider MUST compute the
>>>>>>> "something" mapping defined,
>>>>>> You just contradicted yourself.
>>>>>
>>>>> No, just shows you don't understand English.
>>>>>
>>>>> I am pointing out the difference between what something is ABLE to
>>>>> do, and what it is REQUIRED to do.
>>>>
>>>> You are requiring that a decider maps somethings that it does not
>>>> have, thus making your requirement incorrect. It is like I said give
>>>> me the $10 from your empty wallet.
>>>
>>> But it DOES have the representation of P, so it can map it.
>>>
>> The correctly simulated input to  H(P,P)==0
>> The correctly simulated input to H1(P,P)==1
>>
>
> HOW?
>
> It is the same input, so has the same correct simulation.
I know exactly how. When I explain exactly how my reviewers brains
short-circuit and they become utterly confused.

Instead of how we really only need to know that H(P,P)==0 and H1(P,P)==1
is easily verified as correct on the basis of the behavior of the
correct x86 emulation of these inputs.

--
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/2022 12:04 PM, Richard Damon wrote:
> On 5/27/22 12:04 PM, olcott wrote:
>> On 5/27/2022 10:52 AM, Malcolm McLean wrote:
>>> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>>>> On 5/27/22 11:21 AM, olcott wrote:
>>>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>>>
>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>> interpretation that a halt decider must compute its mapping from a
>>>>>>> non-input would understand that this would violate the definition of
>>>>>>> a computable function and the definition of a decider.
>>>>>>
>>>>>> The definition of "decider" does not require much, only that it
>>>>>> must halt
>>>>>> and indicate the decision. This is not violated by the definition of
>>>>>> "halt
>>>>>> decider".
>>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>> P(P) is not in the domain of H because it is not an input to H.
>>>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>>>> argument on that.
>>>>
>>>> The representation of P, in your case the object code of it. contains
>>>> all the data needed to determine the behavior of that computation, and
>>>> thus IS in the domain of H.
>>>>
>>>> In fact, saying that the representation of P(P) is not in the domain of
>>>> H is, by itself, enough to prove that H can not be a correct halt
>>>> decider.
>>>>
>>>> You are just digging a deeper hole for yourself.
>>>>
>>>> You are just proving your ignorance.
>>>>
>>>> If H claims to be a Halt Decider, then we need to be able to ask it
>>>> about any computation, how do we ask it about P(P).
>>>>
>>>> If we can't, then it isn't one.
>>>>
>>> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
>>> would in fact achieve PO's broader objectives. It wouldn't "solve the
>>> halting problem", but it would redefine it for future workers.
>>>
>>
>> Halt decider are required to decide the halt status of any finite
>> strings that specify a sequence of configurations.
>>
>> Halt deciders are not required to decide that halt status of finite
>> strings of English poems nor are they required to compute the halt
>> status of anything that is not an input finite string.
>>
>> For example H is not required to compute the halt status of the
>> behavior that a person imagines that P(P) has. H(P,P) is only required
>> to compute the halt state that its input actually specifies.
>>
>>> However the question is how to do this in an interesting way. As Ben
>>> says,
>>> a lot of students, when introduced to this material, say "why not detect
>>> the H_Hat(H_Hat) pattern and special case it?". It's a natural reaction.
>>> But when you think about it a bit more deeply, you'll see that this
>>> strategy
>>> doesn't work.
>>>
>>
>> It does work when H is defined to recognize the whole infinite
>> recursion pattern. I threw in infinite loops for good measure.
>>
>
> Except there is no such universal correct pattern.
>

H correctly recognizes the only infinite recursion pattern that it needs
to recognize and that is this one:

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own x86 source and
its input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

> This is shown by the fact that H(P.P) says Non-Halting when P(P) Halts,
> showing that H was wrong.

The correct x86 emulation of the input to H(P,P) conclusively proves
that it DOES NOT HALT.

The correct x86 emulation of the input to H1(P,P) conclusively proves
that it HALTS.

When you disagree with this it is just like you are disagreeing with
arithmetic.

--
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 11:09, olcott wrote:
> On 5/27/2022 11:08 AM, André G. Isaak wrote:
>> On 2022-05-27 09:21, olcott wrote:
>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>
>>>>> Someone with a deeper understanding would realize that your
>>>>> interpretation that a halt decider must compute its mapping from a
>>>>> non-input would understand that this would violate the definition
>>>>> of a computable function and the definition of a decider.
>>>>
>>>> The definition of "decider" does not require much, only that it must
>>>> halt
>>>> and indicate the decision. This is not violated by the definition of
>>>> "halt
>>>> decider".
>>>>
>>>
>>> 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
>>>
>>> P(P) is not in the domain of H because it is not an input to H.
>>
>> Turing Machines don't have domains. Functions have domains.
>>
>
> So maybe you will be able to think of the proper way that I can say
> this. Computable functions have domains that can only be computed by an
> algorithm on the basis of finite strings thus every input that cannot be
> encoded as a finite string is necessarily not in the domain of the
> computable function.

That's mangled phrasing. The domain of a function is whatever the domain
of a function is. If you can't encode some element in the domain of a
function as a finite string, that means the function is not computable.
It doesn't mean the element in question ceases to be part of the
function's domain. Not all functions are computable.

>> A function is computable if it is possible to construct a Turing
>> Machine which computes that function. You don't seem to grasp what
>> this actually means.
>>
>
> When we try to make a computable function that calculates the square
> root of a plate of scrambled eggs we find a type mismatch error because
> scrambled eggs have no numeric property.

And this is one of your completely spurious analogies. The domain of the
square root function is the real numbers. Scrambled eggs are not real
numbers. Therefore scrambled eggs are not part of the domain. The domain
of the halting function is computations. P(P) *is* a computation.
Therefore P(P) *is* part of the domain of the halting function. There is
no type mismatch here. So your analogy clearly fails to convey anything
meaningful.

>> Turing Machines take a finite string as their input, but very few of
>> the computations people are interested in computing have finite
>> strings as their domain.
>
> If an input cannot be encoded as a finite string then it is invalid
> input to any algorithm.

An "input" is something that is already encoded as a finite string. It
makes no sense to talk about encoding an input. You encode things as
strings so they can be used as inputs.

>> Integers, for example, are *not* finite strings, but many functions
>> over the domain of integers are perfectly computable.
>>
>> To construct a turing machine which computes a function, one must
>> first establish a way of encoding the elements of the domain of that
>> function as finite strings. The elements themselves do *not* have to
>> be finite strings. They just need to be encodable as such so they can
>> be passed to a Turing Machine.
>>
>
> Yes. The sequence of configurations specified by P(P) cannot be encoded
> as a finite string input to H.

But *why* do you claim it cannot be so encoded?

You clearly believe that UTMs are possible since you love to talk about
them despite having no idea of how they work. UTMs are only possible
because it is possible to encode computations such as P(P) as finite
strings. Similarly, the only reason people can write about TMs at all is
because we can encode them as finite strings (printing presses deal with
strings, not Turing Machines). The source code for your P() is a finite
string.

So why is it possible to encode computations as strings in all these
cases but not when we want to pass them as inputs to your H()?

> H(P,P) is only required to map its input to an accept or reject state
> based on the actual behavior specified by this actual input.
>
> H is not allowed to consider any behavior besides the actual behavior
> actually specified by its actual inputs.

Its actual input is a string. What, in your mind, does it mean for a
string to specify behaviour? For me, it means the string represents
something which actually *has* behaviour such as a computation like
P(P). Clearly you mean something different. But what, exactly?

>> Ben asked you to create a specification for a Turing Machine which
>> decides whether integers are prime. You failed to be able to do this
>> very basic task. Part of that specification would have included how
>> exactly integers (non-strings) are to be encoded as strings so they
>> can be passed as inputs to the decider. There are many different ways
>> of doing this but it is perfectly doable.
>>
>
> It had a smaller scope then this and I will get back to this soon. I was
> too sick last week when my immune system was disabled by chemotherapy.
>
>> Similarly, for a halt decider, part of the specification would include
>> information on exactly how computations (non-strings) can be encoded
>> as strings so they can be passed to the decider. If you can't figure
>> out a way of encoding P(P) as a string so that it can be passed to
>> your decider then either (a) you are incompetent or (b) the halting
>> function is not computable. Of course, these two options are not
>> mutually exclusive.
>>
>
> Or the problem is asking for something like the square root of a plate
> of scrambled eggs. This makes the problem specification incorrect.

As noted above, your analogy is junk.

But here's a question which you might want to consider:

The prime() function maps integers (not finite strings) to boolean
values (again, not finite strings). It is perfectly possible to
construct a TM which computes this function by finding a way to
represent integers as finite strings and boolean values as final states.

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. Can you explain why?

André

> The set of valid inputs to the algorithm that computes the halt status
> of its inputs is the set of sequences of configurations that can be
> encoded as finite string inputs to H.
>
>> You really ought to complete Ben's exercises. You might actually learn
>> something. I know you are highly adverse to the possibility of
>> learning things, but you may discover it to be both enlightening and
>> useful.
>>
>> André
>>
>
>

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

On 2022-05-27 11:20, olcott wrote:
> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>
>> On 5/27/22 11:54 AM, olcott wrote:
>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>
>>>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>>>> all I
>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>> report
>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>> talking about.
>>>>>>>
>>>>>> To me, that's what retains the interest.
>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>> wouldn't they?
>>>>>>
>>>>>> If it turns out that H isn't a Turing machine but a C/x86 program,
>>>>>> and
>>>>>> that they are refusing to provide the source, then really the whole
>>>>>> thing must be dismissed.
>>>>>>
>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>> reports non-halting, and they can prove that H is correct.
>>>>> There's no reason at all to think that H is /not/ correct. But since H
>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>>> what's interesting about it being correct. Do you really think it's
>>>>> "deciding" some interesting property of the "input"?
>>>>>
>>>> I can't follow all the arguments, and they seem to shift over time.
>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>> a valid sentence.
>>>
>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>>> the current way of saying that input to H(P,P) specifies behavior to
>>> H that would never reach its under its correct x86 emulation by H.
>>
>> But the question isn't does *H* reach the final state of the input in
>> its processing, it is does the computation the input represents reach
>> its final state.
>>
>> You are just admitting to trying to answer the WRONG question.
>
> Does the correct simulation of the input to H(P,P) ever reach its "ret"
> instruction? No, therfore non-halting.

The simulation of P(P) by your H() does not reach its RET instruction.
That tells us nothing about whether a correct simulation of P(P) reaches
its RET instruction. You'd have to first prove that your H() actually
performs a correct simulation, and that's not the sort of thing you can
prove using traces. That's why continuing to post the same traces over
and over isn't going to convince anyone of anything.

André

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

On 2022-05-27 15:16:17 +0000, olcott said:

> On 5/27/2022 2:29 AM, Mikko wrote:
>> On 2022-05-27 04:20:41 +0000, olcott said:
>>
>>>> But since H
>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>> what's interesting about it being correct.  Do you really think it's
>>>> "deciding" some interesting property of the "input"?
>>>
>>> That we do not agree on this other point does not imply any
>>> dishonesty on your part.
>>
>> That you don't answer the question is a good reason to suspect
>> dishonesty on your part.
>>
>> Mikko
>>
>
> I never answer questions directly. I always provide all of the reasons
> for the correct answer. The makes it much more difficult to reject what
> I say out-of-hand without review.

You did not answer the above quoted question and you did not provide
any of the reasons for the correct answer.

Mikko

On 5/27/2022 12:57 PM, André G. Isaak wrote:
> On 2022-05-27 11:09, olcott wrote:
>> On 5/27/2022 11:08 AM, André G. Isaak wrote:
>>> On 2022-05-27 09:21, olcott wrote:
>>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>>
>>>>>> Someone with a deeper understanding would realize that your
>>>>>> interpretation that a halt decider must compute its mapping from a
>>>>>> non-input would understand that this would violate the definition
>>>>>> of a computable function and the definition of a decider.
>>>>>
>>>>> The definition of "decider" does not require much, only that it
>>>>> must halt
>>>>> and indicate the decision. This is not violated by the definition
>>>>> of "halt
>>>>> decider".
>>>>>
>>>>
>>>> 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
>>>>
>>>> P(P) is not in the domain of H because it is not an input to H.
>>>
>>> Turing Machines don't have domains. Functions have domains.
>>>
>>
>> So maybe you will be able to think of the proper way that I can say
>> this. Computable functions have domains that can only be computed by
>> an algorithm on the basis of finite strings thus every input that
>> cannot be encoded as a finite string is necessarily not in the domain
>> of the computable function.
>
> That's mangled phrasing. The domain of a function is whatever the domain
> of a function is.

OK how about the square root of a plate of scrambled eggs?

> If you can't encode some element in the domain of a
> function as a finite string, that means the function is not computable.

So the square root of a plate of scrambled eggs is not computable.

> It doesn't mean the element in question ceases to be part of the
> function's domain. Not all functions are computable.
>

Every computation only computes the output that corresponds to an input,
and only has a set of finite strings as inputs.

Anything that is not a finite string input is outside of the scope of
all computable functions.

>>> A function is computable if it is possible to construct a Turing
>>> Machine which computes that function. You don't seem to grasp what
>>> this actually means.
>>>
>>
>> When we try to make a computable function that calculates the square
>> root of a plate of scrambled eggs we find a type mismatch error
>> because scrambled eggs have no numeric property.
>
> And this is one of your completely spurious analogies. The domain of the
> square root function is the real numbers. Scrambled eggs are not real
> numbers. Therefore scrambled eggs are not part of the domain. The domain
> of the halting function is computations. P(P) *is* a computation.

The input to every halt decider is a Turing machine description that
specifies a sequence of configurations. It is never ever an actual
computation itself it is always an encoding.

> Therefore P(P) *is* part of the domain of the halting function. There is
> no type mismatch here. So your analogy clearly fails to convey anything
> meaningful.
>
>>> Turing Machines take a finite string as their input, but very few of
>>> the computations people are interested in computing have finite
>>> strings as their domain.
>>
>> If an input cannot be encoded as a finite string then it is invalid
>> input to any algorithm.
>
> An "input" is something that is already encoded as a finite string. It
> makes no sense to talk about encoding an input. You encode things as
> strings so they can be used as inputs.
>

>>> Integers, for example, are *not* finite strings, but many functions
>>> over the domain of integers are perfectly computable.
>>>
>>> To construct a turing machine which computes a function, one must
>>> first establish a way of encoding the elements of the domain of that
>>> function as finite strings. The elements themselves do *not* have to
>>> be finite strings. They just need to be encodable as such so they can
>>> be passed to a Turing Machine.
>>>
>>
>> Yes. The sequence of configurations specified by P(P) cannot be
>> encoded as a finite string input to H.
>
> But *why* do you claim it cannot be so encoded?

Simply because an easily verified fact conclusively proves that it
cannot be encoded.

Because the actual execution trace of the correct x86 emulation of the
input to H(P,P) never halts whereas

The actual execution trace of the correct x86 emulation of the input to
H1(P,P) halts.

--
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/2022 1:13 PM, Mikko wrote:
> On 2022-05-27 15:16:17 +0000, olcott said:
>
>> On 5/27/2022 2:29 AM, Mikko wrote:
>>> On 2022-05-27 04:20:41 +0000, olcott said:
>>>
>>>>> But since H
>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>>> what's interesting about it being correct.  Do you really think it's
>>>>> "deciding" some interesting property of the "input"?
>>>>
>>>> That we do not agree on this other point does not imply any
>>>> dishonesty on your part.
>>>
>>> That you don't answer the question is a good reason to suspect
>>> dishonesty on your part.
>>>
>>> Mikko
>>>
>>
>> I never answer questions directly. I always provide all of the reasons
>> for the correct answer. The makes it much more difficult to reject
>> what I say out-of-hand without review.
>
> You did not answer the above quoted question and you did not provide
> any of the reasons for the correct answer.
>
> Mikko
>

H(P,P) does correctly decide the halt status of its input thus refuting
the HP proofs that say this cannot be done.

--
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/2022 1:03 PM, André G. Isaak wrote:
> On 2022-05-27 11:20, olcott wrote:
>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>
>>> On 5/27/22 11:54 AM, olcott wrote:
>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>
>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>> when all I
>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>> report
>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>> talking about.
>>>>>>>>
>>>>>>> To me, that's what retains the interest.
>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>> wouldn't they?
>>>>>>>
>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>> program, and
>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>> thing must be dismissed.
>>>>>>>
>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>> There's no reason at all to think that H is /not/ correct. But
>>>>>> since H
>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't
>>>>>> see
>>>>>> what's interesting about it being correct. Do you really think it's
>>>>>> "deciding" some interesting property of the "input"?
>>>>>>
>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>> a valid sentence.
>>>>
>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>>>> the current way of saying that input to H(P,P) specifies behavior to
>>>> H that would never reach its under its correct x86 emulation by H.
>>>
>>> But the question isn't does *H* reach the final state of the input in
>>> its processing, it is does the computation the input represents reach
>>> its final state.
>>>
>>> You are just admitting to trying to answer the WRONG question.
>>
>> Does the correct simulation of the input to H(P,P) ever reach its
>> "ret" instruction? No, therfore non-halting.
>
> The simulation of P(P) by your H() does not reach its RET instruction.

It is also easily proven that H does perform a correct x86 emulation of
its input, hence H(P,P)==0 is proven to be correct.

> That tells us nothing about whether a correct simulation of P(P) reaches
> its RET instruction.

H is correctly forbidden from do this. H1(P,P)==1.
Every halt decider must only compute the halt status based on the actual
behavior that its input actually specifies.

That everyone here disagrees with the x86 language is the same as if
they disagreed with arithmetic, impossibly correct.

> You'd have to first prove that your H() actually
> performs a correct simulation, and that's not the sort of thing you can
> prove using traces.

Actually it can only be proved using traces. As long as P has the
behavior that its x86 source code specifies then its x86 emulation is
conclusively proved to be correct.

> That's why continuing to post the same traces over
> and over isn't going to convince anyone of anything.
>
> 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 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"?

If, further, like almost all real numbers, you can't even talk
about "x", then you certainly can't talk about its "sqrt". But that's
philosophy rather than computing.

[It gets more practically interesting if you introduce functions
that aren't continuous, but there are limits to how many rabbit holes
it's worth chasing down in the present debate.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Goodban

On 5/27/22 1:23 PM, olcott wrote:
> On 5/27/2022 12:03 PM, Richard Damon wrote:
>> On 5/27/22 12:06 PM, olcott wrote:
>>> On 5/27/2022 10:53 AM, Richard Damon wrote:
>>>> On 5/27/22 11:24 AM, olcott wrote:
>>>>> On 5/27/2022 7:50 AM, Richard Damon wrote:
>>>>>> On 5/26/22 11:06 PM, olcott wrote:
>>>>>>> On 5/26/2022 9:50 PM, Richard Damon wrote:
>>>>>>>> On 5/26/22 9:35 AM, olcott wrote:
>>>>>>>>> On 5/26/2022 6:21 AM, Ben wrote:
>>>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>>>>> when all I
>>>>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does
>>>>>>>>>>>> not report
>>>>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone
>>>>>>>>>>>> else is
>>>>>>>>>>>> talking about.
>>>>>>>>>>>>
>>>>>>>>>>> To me, that's what retains the interest.
>>>>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H
>>>>>>>>>>> such
>>>>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>>>>> wouldn't they?
>>>>>>>>>>>
>>>>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>>>>> program, and
>>>>>>>>>>> that they are refusing to provide the source, then really the
>>>>>>>>>>> whole
>>>>>>>>>>> thing must be dismissed.
>>>>>>>>>>>
>>>>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>>>>>
>>>>>>>>>> There's no reason at all to think that H is /not/ correct.
>>>>>>>>>> But since H
>>>>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>>>>> don't see
>>>>>>>>>> what's interesting about it being correct.  Do you really
>>>>>>>>>> think it's
>>>>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The only reason that you do not see the significance of this is
>>>>>>>>> that the depth of your understanding is learned-by-rote.
>>>>>>>>>
>>>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>>>> interpretation that a halt decider must compute its mapping
>>>>>>>>> from a non-input would understand that this would violate the
>>>>>>>>> definition of a computable function and the definition of a
>>>>>>>>> decider.
>>>>>>>>
>>>>>>>> No, it only CAN compute what can be determined by its processing
>>>>>>>> of the input, but a "something" decider MUST compute the
>>>>>>>> "something" mapping defined,
>>>>>>> You just contradicted yourself.
>>>>>>
>>>>>> No, just shows you don't understand English.
>>>>>>
>>>>>> I am pointing out the difference between what something is ABLE to
>>>>>> do, and what it is REQUIRED to do.
>>>>>
>>>>> You are requiring that a decider maps somethings that it does not
>>>>> have, thus making your requirement incorrect. It is like I said
>>>>> give me the $10 from your empty wallet.
>>>>
>>>> But it DOES have the representation of P, so it can map it.
>>>>
>>> The correctly simulated input to  H(P,P)==0
>>> The correctly simulated input to H1(P,P)==1
>>>
>>
>> HOW?
>>
>> It is the same input, so has the same correct simulation.
> I know exactly how. When I explain exactly how my reviewers brains
> short-circuit and they become utterly confused.

In other words, you can't actually explain it.

You apparently THINK you know it, by epistomolgy, you can only know
something that is actually true, and whose truth you can prove.

The fact that you can't make a reasoned argument about the truth of this
statement shows you don't actually know it.

It is a mistaken BELIEF of yours, grounded in your own ignorance of what
Truth actually requires.

>
> Instead of how we really only need to know that H(P,P)==0 and H1(P,P)==1
> is easily verified as correct on the basis of the behavior of the
> correct x86 emulation of these inputs.
>

No, you make this CLAIM, that it totally not backed up by ANY proof,
just CLAIMS, that show you don't understand the maining of the words you
are speaking.

All your arguments have shown is that there are many things you just
don't understand, beginning with most of computation theory, the theory
of how logic works, and even the meaning of Truth and Knowledge itself.

You are just a lying fool who is a legend in his own minds.

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.

(And Newton-Raphson doesn't allow you to compute square roots; it allows
you to compute arbitrarily precise approximations of those roots).

André

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

On 5/27/22 1:28 PM, olcott wrote:
> On 5/27/2022 12:04 PM, Richard Damon wrote:
>> On 5/27/22 12:04 PM, olcott wrote:
>>> On 5/27/2022 10:52 AM, Malcolm McLean wrote:
>>>> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>>>>> On 5/27/22 11:21 AM, olcott wrote:
>>>>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>>>>
>>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>>> interpretation that a halt decider must compute its mapping from a
>>>>>>>> non-input would understand that this would violate the
>>>>>>>> definition of
>>>>>>>> a computable function and the definition of a decider.
>>>>>>>
>>>>>>> The definition of "decider" does not require much, only that it
>>>>>>> must halt
>>>>>>> and indicate the decision. This is not violated by the definition of
>>>>>>> "halt
>>>>>>> decider".
>>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> P(P) is not in the domain of H because it is not an input to H.
>>>>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>>>>> argument on that.
>>>>>
>>>>> The representation of P, in your case the object code of it. contains
>>>>> all the data needed to determine the behavior of that computation, and
>>>>> thus IS in the domain of H.
>>>>>
>>>>> In fact, saying that the representation of P(P) is not in the
>>>>> domain of
>>>>> H is, by itself, enough to prove that H can not be a correct halt
>>>>> decider.
>>>>>
>>>>> You are just digging a deeper hole for yourself.
>>>>>
>>>>> You are just proving your ignorance.
>>>>>
>>>>> If H claims to be a Halt Decider, then we need to be able to ask it
>>>>> about any computation, how do we ask it about P(P).
>>>>>
>>>>> If we can't, then it isn't one.
>>>>>
>>>> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
>>>> would in fact achieve PO's broader objectives. It wouldn't "solve the
>>>> halting problem", but it would redefine it for future workers.
>>>>
>>>
>>> Halt decider are required to decide the halt status of any finite
>>> strings that specify a sequence of configurations.
>>>
>>> Halt deciders are not required to decide that halt status of finite
>>> strings of English poems nor are they required to compute the halt
>>> status of anything that is not an input finite string.
>>>
>>> For example H is not required to compute the halt status of the
>>> behavior that a person imagines that P(P) has. H(P,P) is only
>>> required to compute the halt state that its input actually specifies.
>>>
>>>> However the question is how to do this in an interesting way. As Ben
>>>> says,
>>>> a lot of students, when introduced to this material, say "why not
>>>> detect
>>>> the H_Hat(H_Hat) pattern and special case it?". It's a natural
>>>> reaction.
>>>> But when you think about it a bit more deeply, you'll see that this
>>>> strategy
>>>> doesn't work.
>>>>
>>>
>>> It does work when H is defined to recognize the whole infinite
>>> recursion pattern. I threw in infinite loops for good measure.
>>>
>>
>> Except there is no such universal correct pattern.
>>
>
> H correctly recognizes the only infinite recursion pattern that it needs
> to recognize and that is this one:
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own x86 source and
> its input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem

Except that the pattern isn't correct, as H says P(P) is non-halting
when in fact it is haltimg.

You mind has apparently imploded as it doesn't recognize this error.

>
>
>> This is shown by the fact that H(P.P) says Non-Halting when P(P)
>> Halts, showing that H was wrong.
>
> The correct x86 emulation of the input to H(P,P) conclusively proves
> that it DOES NOT HALT.

DEFINE CORRECT, since by the normal definition of a correct simulation
of that input, one that you have even posted yourself, it shows that it
does halt.

>
> The correct x86 emulation of the input to H1(P,P) conclusively proves
> that it HALTS.

Yes, and since it is the same input, that shows that H's simulation,
which was aborted before it reached its end, was not correct.

>
> When you disagree with this it is just like you are disagreeing with
> arithmetic.
>
>

What, that counting to ten by going 1, 2, 3, 4, 5 ABORT, isn't a correct
counting to 10?

You seem to think it is.

You don't seem to have a proper definition of correct, which isn't
surprising as you don't know what Truth is, and they are tied together.

On 2022-05-27 12:24, olcott wrote:
> On 5/27/2022 12:57 PM, André G. Isaak wrote:
>> On 2022-05-27 11:09, olcott wrote:
>>> On 5/27/2022 11:08 AM, André G. Isaak wrote:
>>>> On 2022-05-27 09:21, olcott wrote:
>>>>> On 5/27/2022 2:48 AM, Mikko wrote:
>>>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>>>
>>>>>>> Someone with a deeper understanding would realize that your
>>>>>>> interpretation that a halt decider must compute its mapping from
>>>>>>> a non-input would understand that this would violate the
>>>>>>> definition of a computable function and the definition of a decider.
>>>>>>
>>>>>> The definition of "decider" does not require much, only that it
>>>>>> must halt
>>>>>> and indicate the decision. This is not violated by the definition
>>>>>> of "halt
>>>>>> decider".
>>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>> P(P) is not in the domain of H because it is not an input to H.
>>>>
>>>> Turing Machines don't have domains. Functions have domains.
>>>>
>>>
>>> So maybe you will be able to think of the proper way that I can say
>>> this. Computable functions have domains that can only be computed by
>>> an algorithm on the basis of finite strings thus every input that
>>> cannot be encoded as a finite string is necessarily not in the domain
>>> of the computable function.
>>
>> That's mangled phrasing. The domain of a function is whatever the
>> domain of a function is.
>
> OK how about the square root of a plate of scrambled eggs?

You really ought to get into the habit of reading a post in its entirety
*before* you begin to respond. I address this silly analogy in the very
post you are responding to.

<remaining rubbish snipped>

André

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

On 5/27/2022 1:37 PM, 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.

Yes I was going to make this same point.
Many of these are not computable because they have no exactly correct
representation as a finite string.

> 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"?
>
>     If, further, like almost all real numbers, you can't even talk
> about "x", then you certainly can't talk about its "sqrt".  But that's
> philosophy rather than computing.
>
>     [It gets more practically interesting if you introduce functions
> that aren't continuous, but there are limits to how many rabbit holes
> it's worth chasing down in the present debate.]
>

--
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 1:20 PM, olcott wrote:
> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>
>> On 5/27/22 11:54 AM, olcott wrote:
>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>
>>>>>>> I admit it's all guesswork though. I seriously lost interest when
>>>>>>> all I
>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>> report
>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>> talking about.
>>>>>>>
>>>>>> To me, that's what retains the interest.
>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>> wouldn't they?
>>>>>>
>>>>>> If it turns out that H isn't a Turing machine but a C/x86 program,
>>>>>> and
>>>>>> that they are refusing to provide the source, then really the whole
>>>>>> thing must be dismissed.
>>>>>>
>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>> reports non-halting, and they can prove that H is correct.
>>>>> There's no reason at all to think that H is /not/ correct. But since H
>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
>>>>> what's interesting about it being correct. Do you really think it's
>>>>> "deciding" some interesting property of the "input"?
>>>>>
>>>> I can't follow all the arguments, and they seem to shift over time.
>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>> a valid sentence.
>>>
>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>>> the current way of saying that input to H(P,P) specifies behavior to
>>> H that would never reach its under its correct x86 emulation by H.
>>
>> But the question isn't does *H* reach the final state of the input in
>> its processing, it is does the computation the input represents reach
>> its final state.
>>
>> You are just admitting to trying to answer the WRONG question.
>
> Does the correct simulation of the input to H(P,P) ever reach its "ret"
> instruction? No, therfore non-halting.
>
>>
>>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> When the above is correctly emulated by H the first seven
>>> instructions are emulated then P calls H(P,P) which causes H to
>>> emulate the first seven instructions again. This infinite emulation
>>> never stops unless aborted. Whether or not it is aborted the emulated
>>> P never reaches its "ret" instruction thus never halts. The H(P,P)==0
>>> is proved to be correct.
>>>
>>
>> But H can't correctly emulate all of the input, and give an answer.
>> That is your problem
>>
>
> The set of valid inputs to the algorithm that computes the halt status
> of its inputs is the set of sequences of configurations that can be
> encoded as finite string inputs to H.
>
>

The input to H is NOT a "sequence of configuratios", but the
representation of an algorithm and its input.

Sounds like your H isn't even close to being a Halt Decider.

Seems like you really don't understand a thing that you are talking
about but just word jumbling from stuff you have read,

H takes in a finite string that represents the compuation it is to
decider on. That exists, as in your example, that string can be the
binary code of ALL the memory that the function P will execute (that is
the code of P, H, and all that H calls). Since you claim this program
exists, there is a finite string that represents it, or you couldn't run it.

H, when it runs, creates a sequence of configurations as it progresses
through its processing, but that sequence isn't the "input" to H, it is
the processing of H.

Since the program P can be fully expressed as a finite string to H, as
can its input (another copy of that exact same input), then H can
definitely be given the string that represent the computation P(P), via
the pointers P and P (with the proper interpretation of those pointers
providing access to all that representation).

This means that you claim that P(P) can't be an input is just FALSE, it
is fully representable to H.

THe problem is that H can't actually compute the needed results, because
it will take an infinite number of steps, which just shows that Halting
is NOT a Computable Funcition, which is exactly what the Theorem says.

You are just proving how stupid you are, and how much your statements
are based on lying.

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.

> (And Newton-Raphson doesn't allow you to compute square roots; it allows
> you to compute arbitrarily precise approximations of those roots).
>
> 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/2022 1:57 PM, Richard Damon wrote:
> On 5/27/22 1:20 PM, olcott wrote:
>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>
>>> On 5/27/22 11:54 AM, olcott wrote:
>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>
>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>> when all I
>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>> report
>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>> talking about.
>>>>>>>>
>>>>>>> To me, that's what retains the interest.
>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>> wouldn't they?
>>>>>>>
>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>> program, and
>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>> thing must be dismissed.
>>>>>>>
>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>> There's no reason at all to think that H is /not/ correct. But
>>>>>> since H
>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I don't
>>>>>> see
>>>>>> what's interesting about it being correct. Do you really think it's
>>>>>> "deciding" some interesting property of the "input"?
>>>>>>
>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>> a valid sentence.
>>>>
>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat) or
>>>> the current way of saying that input to H(P,P) specifies behavior to
>>>> H that would never reach its under its correct x86 emulation by H.
>>>
>>> But the question isn't does *H* reach the final state of the input in
>>> its processing, it is does the computation the input represents reach
>>> its final state.
>>>
>>> You are just admitting to trying to answer the WRONG question.
>>
>> Does the correct simulation of the input to H(P,P) ever reach its
>> "ret" instruction? No, therfore non-halting.
>>
>>>
>>>>
>>>> _P()
>>>> [00001352](01)  55              push ebp
>>>> [00001353](02)  8bec            mov ebp,esp
>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>> [00001358](01)  50              push eax      // push P
>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>> [0000135c](01)  51              push ecx      // push P
>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>> [00001362](03)  83c408          add esp,+08
>>>> [00001365](02)  85c0            test eax,eax
>>>> [00001367](02)  7402            jz 0000136b
>>>> [00001369](02)  ebfe            jmp 00001369
>>>> [0000136b](01)  5d              pop ebp
>>>> [0000136c](01)  c3              ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> When the above is correctly emulated by H the first seven
>>>> instructions are emulated then P calls H(P,P) which causes H to
>>>> emulate the first seven instructions again. This infinite emulation
>>>> never stops unless aborted. Whether or not it is aborted the
>>>> emulated P never reaches its "ret" instruction thus never halts. The
>>>> H(P,P)==0 is proved to be correct.
>>>>
>>>
>>> But H can't correctly emulate all of the input, and give an answer.
>>> That is your problem
>>>
>>
>> The set of valid inputs to the algorithm that computes the halt status
>> of its inputs is the set of sequences of configurations that can be
>> encoded as finite string inputs to H.
>>
>>
>
> The input to H is NOT a "sequence of configuratios", but the
> representation of an algorithm and its input.

The finite string inputs to a halt decider specify (rather then merely
represent) a sequence of configurations that may or may not reach their
own final state.

>
> Sounds like your H isn't even close to being a Halt Decider.
>
> Seems like you really don't understand a thing that you are talking
> about but just word jumbling from stuff you have read,
>
> H takes in a finite string that represents the compuation it is to
> decider on. That exists, as in your example, that string can be the
> binary code of ALL the memory that the function P will execute (that is
> the code of P, H, and all that H calls). Since you claim this program
> exists, there is a finite string that represents it, or you couldn't run
> it.
>
> H, when it runs, creates a sequence of configurations as it progresses
> through its processing, but that sequence isn't the "input" to H, it is
> the processing of H.
>
> Since the program P can be fully expressed as a finite string to H, as
> can its input (another copy of that exact same input), then H can
> definitely be given the string that represent the computation P(P), via
> the pointers P and P (with the proper interpretation of those pointers
> providing access to all that representation).
>
> This means that you claim that P(P) can't be an input is just FALSE, it
> is fully representable to H.
>
> THe problem is that H can't actually compute the needed results, because
> it will take an infinite number of steps, which just shows that Halting
> is NOT a Computable Funcition, which is exactly what the Theorem says.
>
> You are just proving how stupid you are, and how much your statements
> are based on lying.

--
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 2:34 PM, olcott wrote:
> On 5/27/2022 1:03 PM, André G. Isaak wrote:
>> On 2022-05-27 11:20, olcott wrote:
>>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>>
>>>> On 5/27/22 11:54 AM, olcott wrote:
>>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>>>>>>>
>>>>>>>>> I admit it's all guesswork though. I seriously lost interest
>>>>>>>>> when all I
>>>>>>>>> thought it worth doing was pointing out that if H(X,Y) does not
>>>>>>>>> report
>>>>>>>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>>>>>>>> talking about.
>>>>>>>>>
>>>>>>>> To me, that's what retains the interest.
>>>>>>>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>>>>>>>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>>>>>>>> wouldn't they?
>>>>>>>>
>>>>>>>> If it turns out that H isn't a Turing machine but a C/x86
>>>>>>>> program, and
>>>>>>>> that they are refusing to provide the source, then really the whole
>>>>>>>> thing must be dismissed.
>>>>>>>>
>>>>>>>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>>>>>>>> reports non-halting, and they can prove that H is correct.
>>>>>>> There's no reason at all to think that H is /not/ correct. But
>>>>>>> since H
>>>>>>> is not reporting on the halting of a call to H_Hat(H_Hat), I
>>>>>>> don't see
>>>>>>> what's interesting about it being correct. Do you really think it's
>>>>>>> "deciding" some interesting property of the "input"?
>>>>>>>
>>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>>> a valid sentence.
>>>>>
>>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat)
>>>>> or the current way of saying that input to H(P,P) specifies
>>>>> behavior to H that would never reach its under its correct x86
>>>>> emulation by H.
>>>>
>>>> But the question isn't does *H* reach the final state of the input
>>>> in its processing, it is does the computation the input represents
>>>> reach its final state.
>>>>
>>>> You are just admitting to trying to answer the WRONG question.
>>>
>>> Does the correct simulation of the input to H(P,P) ever reach its
>>> "ret" instruction? No, therfore non-halting.
>>
>> The simulation of P(P) by your H() does not reach its RET instruction.
>
> It is also easily proven that H does perform a correct x86 emulation of
> its input, hence H(P,P)==0 is proven to be correct.

HOW?

Remember, correct means matches that actual behavior, and H creates only
a PARTIAL simulation, then gives up.

It then using either an incorrect rules or an incorrect premise to feed
logic for it to decide (incorrectly) to abort.

The CORRECT trace, by H1, shows that H was wrong.

>
>
>> That tells us nothing about whether a correct simulation of P(P)
>> reaches its RET instruction.
>
> H is correctly forbidden from do this. H1(P,P)==1.

WHY?

> Every halt decider must only compute the halt status based on the actual
> behavior that its input actually specifies.

Rigbt, and P,P specifies P(P) which Halts.

Unless you H isn't actually a computation (sometimes H(P,P) is 0 and
sometimes it is an infinite loop) then H is just incorrect. If H isn't a
computation, the your whole argument is a LIE>

>
> That everyone here disagrees with the x86 language is the same as if
> they disagreed with arithmetic, impossibly correct.

Nope, we AGREE with the x86 language, which says the correct simulation
of the input to H(P,P) is exactly what P(P) would do (that is, give the
exact same input to an x86 processor and let it run.

You have to explain how that definition doesn't apply?

>
>> You'd have to first prove that your H() actually performs a correct
>> simulation, and that's not the sort of thing you can prove using traces.
>
> Actually it can only be proved using traces. As long as P has the
> behavior that its x86 source code specifies then its x86 emulation is
> conclusively proved to be correct.

Except your traces don't, since an x86 executing a CALL instruction then
executes the code at the destination of the call, but your traces don't
show that.

Note, x86 at the processor level, doesn't distiguish between User Code
and System Code in a single memory context.

You don't seem to understand that basic fact.

>
>> That's why continuing to post the same traces over and over isn't
>> going to convince anyone of anything.
>>
>> André
>>
>
>