On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
On 5/27/22 11:21 AM, olcott wrote:But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
On 5/27/2022 2:48 AM, Mikko wrote:Wrong. IF that is true the a UTM can't exist, but you are baisng your
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.
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.
would in fact achieve PO's broader objectives. It wouldn't "solve the
halting problem", but it would redefine it for future workers.
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.
On Thursday, 26 May 2022 at 12:21:07 UTC+1, Ben wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:I can't follow all the arguments, and they seem to shift over time.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:There's no reason at all to think that H is /not/ correct. But since H
To me, that's what retains the interest.
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.
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.
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"?
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.
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.
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
the input. So "Non-halting" is correct even though H_Hat halts.
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.
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.
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.
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:I can't follow all the arguments, and they seem to shift over time.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:There's no reason at all to think that H is /not/ correct. But since H
To me, that's what retains the interest.
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.
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.
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"?
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.
_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.
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.
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.
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]
The exact same process applies to the above _Infinite_Loop()
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.
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.
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/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:But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
On 5/27/2022 2:48 AM, Mikko wrote:Wrong. IF that is true the a UTM can't exist, but you are baisng your
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.
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.
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.
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:But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
On 5/27/2022 2:48 AM, Mikko wrote:Wrong. IF that is true the a UTM can't exist, but you are baisng your
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.
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.
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/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:I can't follow all the arguments, and they seem to shift over time.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote: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
To me, that's what retains the interest.
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.
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.
"deciding" some interesting property of the "input"?
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
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:I can't follow all the arguments, and they seem to shift over time.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote: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
To me, that's what retains the interest.
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.
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.
"deciding" some interesting property of the "input"?
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.
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:I can't follow all the arguments, and they seem to shift over time.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:There's no reason at all to think that H is /not/ correct. But
To me, that's what retains the interest.
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.
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.
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"?
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é
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:But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
On 5/27/2022 2:48 AM, Mikko wrote:Wrong. IF that is true the a UTM can't exist, but you are baisng your >>>>> argument on that.
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.
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.
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.
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:I can't follow all the arguments, and they seem to shift over time.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote: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
To me, that's what retains the interest.
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.
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.
"deciding" some interesting property of the "input"?
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.
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:I can't follow all the arguments, and they seem to shift over time.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:There's no reason at all to think that H is /not/ correct. But
To me, that's what retains the interest.
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.
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.
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"?
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:57 PM, Richard Damon wrote:
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.
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: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.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:There's no reason at all to think that H is /not/ correct. But
To me, that's what retains the interest.
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.
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.
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"?
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é
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like 'represent', 'specify', or 'sequence of configurations' mean. Richard is perfectly correct. You, as usual, are not.
Perhaps you can explain your own idiosyncratic usage of these terms.
André
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: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.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:There's no reason at all to think that H is /not/ correct. But
To me, that's what retains the interest.
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.
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.
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"?
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.
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like 'represent',
'specify', or 'sequence of configurations' mean. Richard is perfectly
correct. You, as usual, are not.
The distinction that I make between represent and specify is that the
x86 source-code for P represents P(P) whereas the actual correct x86 emulation of the input to H(P,P) specifies the actual behavior of this
input. This is not the same behavior as the behavior specified by P(P).
A sequence of configurations means a list of x86 program steps executed
or emulated in the order that their source-code specifies.
Likewise with a TM or the UTM simulation of a TM description specifies a sequence of state transitions.
This is more general than a computation in that every computation must
reach its own final state.
On 5/27/2022 2:54 PM, Richard Damon wrote:
On 5/27/22 3:01 PM, olcott wrote:
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: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.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:There's no reason at all to think that H is /not/ correct. But >>>>>>>>> since H
To me, that's what retains the interest.
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.
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.
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"?
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.
And there is no requirement that a finite string representation yields
a finite sequence of configuarions for that machine.
There is a requirement that a finite string specifies a sequence of configurations for the machine.
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like 'represent',
'specify', or 'sequence of configurations' mean. Richard is perfectly
correct. You, as usual, are not.
The distinction that I make between represent and specify is that the
x86 source-code for P represents P(P) whereas the actual correct x86
emulation of the input to H(P,P) specifies the actual behavior of this
input. This is not the same behavior as the behavior specified by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies.
Likewise with a TM or the UTM simulation of a TM description specifies
a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its input.
It is not given a sequence of state transitions. It is given a
representation of a computation.
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like 'represent',
'specify', or 'sequence of configurations' mean. Richard is
perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that the
x86 source-code for P represents P(P) whereas the actual correct x86
emulation of the input to H(P,P) specifies the actual behavior of
this input. This is not the same behavior as the behavior specified
by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies.
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its input.
It is not given a sequence of state transitions. It is given a
representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of configurations.
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like 'represent',
'specify', or 'sequence of configurations' mean. Richard is
perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that the
x86 source-code for P represents P(P) whereas the actual correct x86
emulation of the input to H(P,P) specifies the actual behavior of
this input. This is not the same behavior as the behavior specified
by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies.
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its input.
It is not given a sequence of state transitions. It is given a
representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of configurations.
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like 'represent',
'specify', or 'sequence of configurations' mean. Richard is
perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that
the x86 source-code for P represents P(P) whereas the actual correct
x86 emulation of the input to H(P,P) specifies the actual behavior
of this input. This is not the same behavior as the behavior
specified by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies.
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is given a
representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of configurations.
A TM description and a sequence of configurations are entirely different things (and the former certainly does not 'specify' the latter). It's
given either one or the other. Make up your mind.
André
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like 'represent',
'specify', or 'sequence of configurations' mean. Richard is
perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that
the x86 source-code for P represents P(P) whereas the actual correct
x86 emulation of the input to H(P,P) specifies the actual behavior
of this input. This is not the same behavior as the behavior
specified by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies.
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is given a
representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of configurations.
A TM description and a sequence of configurations are entirely different things (and the former certainly does not 'specify' the latter). It's
given either one or the other. Make up your mind.
André
On 5/27/22 5:21 PM, André G. Isaak wrote:
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
Well, a TM description, and a description of an input to that TM, does specify a "sequence of configurations" based on what running that TM on
that input would do.
On 5/27/2022 4:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean.
Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that
the x86 source-code for P represents P(P) whereas the actual
correct x86 emulation of the input to H(P,P) specifies the actual
behavior of this input. This is not the same behavior as the
behavior specified by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies.
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is given
a representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
_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]
So then the above x86 code may specify a game of tic-tac-toe and there
is no possible way to determine that it does not because the x86 source
code of a function has nothing to do with the sequence of steps of its correct simulation.
On 5/27/2022 4:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean.
Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that
the x86 source-code for P represents P(P) whereas the actual
correct x86 emulation of the input to H(P,P) specifies the actual
behavior of this input. This is not the same behavior as the
behavior specified by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies.
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is given
a representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
_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]
So then the above x86 code may specify a game of tic-tac-toe and there
is no possible way to determine that it does not because the x86 source
code of a function has nothing to do with the sequence of steps of its correct simulation.
On 2022-05-27 15:31, olcott wrote:
On 5/27/2022 4:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean.
Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that
the x86 source-code for P represents P(P) whereas the actual
correct x86 emulation of the input to H(P,P) specifies the actual
behavior of this input. This is not the same behavior as the
behavior specified by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies. >>>>>>
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is given
a representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
_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]
So then the above x86 code may specify a game of tic-tac-toe and there
is no possible way to determine that it does not because the x86
source code of a function has nothing to do with the sequence of steps
of its correct simulation.
That is not a sequence of configurations. It is a piece of assembly code which represents a subroutine which is an infinite loop. The sequence of configurations would look something like this:
[000012c2](01) 55 push ebp
[000012c3](02) 8bec mov ebp,esp
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
[000012c5](02) ebfe jmp 000012c5
etc.
There's no way the above sequence of configurations could be given to a
halt decider as an input because it is not finite. You can only give it
the representation of the subroutine which is finite.
André
On 2022-05-27 15:32, Richard Damon wrote:
On 5/27/22 5:21 PM, André G. Isaak wrote:
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
Well, a TM description, and a description of an input to that TM, does
specify a "sequence of configurations" based on what running that TM
on that input would do.
A TM description and the description of an input to that TM can be used
to *derive* a sequence of configurations, but they don't specify such a sequence.
André
On 2022-05-27 15:32, Richard Damon wrote:
On 5/27/22 5:21 PM, André G. Isaak wrote:
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
Well, a TM description, and a description of an input to that TM, does
specify a "sequence of configurations" based on what running that TM
on that input would do.
A TM description and the description of an input to that TM can be used
to *derive* a sequence of configurations, but they don't specify such a sequence.
André
On 5/27/2022 4:41 PM, André G. Isaak wrote:
On 2022-05-27 15:31, olcott wrote:
On 5/27/2022 4:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean.
Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that >>>>>>> the x86 source-code for P represents P(P) whereas the actual
correct x86 emulation of the input to H(P,P) specifies the actual >>>>>>> behavior of this input. This is not the same behavior as the
behavior specified by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies. >>>>>>>
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is
given a representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
_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]
So then the above x86 code may specify a game of tic-tac-toe and
there is no possible way to determine that it does not because the
x86 source code of a function has nothing to do with the sequence of
steps of its correct simulation.
That is not a sequence of configurations. It is a piece of assembly
code which represents a subroutine which is an infinite loop. The
sequence of configurations would look something like this:
Yes that code specifies this sequence.
On 2022-05-27 16:13, olcott wrote:
On 5/27/2022 4:41 PM, André G. Isaak wrote:
On 2022-05-27 15:31, olcott wrote:
On 5/27/2022 4:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean. >>>>>>>>> Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is
that the x86 source-code for P represents P(P) whereas the
actual correct x86 emulation of the input to H(P,P) specifies
the actual behavior of this input. This is not the same behavior >>>>>>>> as the behavior specified by P(P).
A sequence of configurations means a list of x86 program steps >>>>>>>> executed or emulated in the order that their source-code specifies. >>>>>>>>
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is
given a representation of a computation.
No it is not and you know that it is not. A halt decider is given
a finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
_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]
So then the above x86 code may specify a game of tic-tac-toe and
there is no possible way to determine that it does not because the
x86 source code of a function has nothing to do with the sequence of
steps of its correct simulation.
That is not a sequence of configurations. It is a piece of assembly
code which represents a subroutine which is an infinite loop. The
sequence of configurations would look something like this:
Yes that code specifies this sequence.
No, it does not. What you have above only generates the following *only*
if you (a) interpret it as representing x86 instructions and (b)
actually execute it on an x86 or some appropriate emulator.
You keep claiming that the input to the decider is a sequence of configurations, but that's just plain wrong.
It is something which H
might possibly *use* to derive such a sequence but only when interpreted
in an appropriate way and only given an appropriate algorithm for doing so.
Just because you can get from A to B doesn't mean it is accurate to
refer to A as B.
André
On 5/27/2022 5:26 PM, André G. Isaak wrote:
On 2022-05-27 16:13, olcott wrote:
On 5/27/2022 4:41 PM, André G. Isaak wrote:
On 2022-05-27 15:31, olcott wrote:
On 5/27/2022 4:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean. >>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is >>>>>>>>> that the x86 source-code for P represents P(P) whereas the
actual correct x86 emulation of the input to H(P,P) specifies >>>>>>>>> the actual behavior of this input. This is not the same
behavior as the behavior specified by P(P).
A sequence of configurations means a list of x86 program steps >>>>>>>>> executed or emulated in the order that their source-code
specifies.
Likewise with a TM or the UTM simulation of a TM description >>>>>>>>> specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its >>>>>>>> input. It is not given a sequence of state transitions. It is
given a representation of a computation.
No it is not and you know that it is not. A halt decider is given >>>>>>> a finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
_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]
So then the above x86 code may specify a game of tic-tac-toe and
there is no possible way to determine that it does not because the
x86 source code of a function has nothing to do with the sequence
of steps of its correct simulation.
That is not a sequence of configurations. It is a piece of assembly
code which represents a subroutine which is an infinite loop. The
sequence of configurations would look something like this:
Yes that code specifies this sequence.
No, it does not. What you have above only generates the following
*only* if you (a) interpret it as representing x86 instructions and
(b) actually execute it on an x86 or some appropriate emulator.
Because no one in their right mind would think of doing it otherwise
those ridiculously self-evident facts need not be stated.
If it was not for communication context then every single rule of
grammar would have to be repeated with every sentence and every
definition of every work would have to be repeated over and over.
You keep claiming that the input to the decider is a sequence of
configurations, but that's just plain wrong.
The input to a decider
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations
Did you notice that I said SPECFIES this time ???
It is something which H might possibly *use* to derive such a sequence
but only when interpreted in an appropriate way and only given an
appropriate algorithm for doing so.
<sarcasm>
Yes and because it has not been explicitly specified maybe I am talking
about space aliens that are going to invade the Earth in a space alien language that closely resembles a discussion on halt deciders in English?
Since I did not explicitly specify that I am talking in English and not
space alien you have no sufficient basis to have any idea what my words actually mean.
</sarcasm>
Just because you can get from A to B doesn't mean it is accurate to
refer to A as B.
André
On 5/27/22 6:42 PM, olcott wrote:
On 5/27/2022 5:26 PM, André G. Isaak wrote:
On 2022-05-27 16:13, olcott wrote:
On 5/27/2022 4:41 PM, André G. Isaak wrote:
On 2022-05-27 15:31, olcott wrote:
On 5/27/2022 4:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean. >>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is >>>>>>>>>> that the x86 source-code for P represents P(P) whereas the >>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies >>>>>>>>>> the actual behavior of this input. This is not the same
behavior as the behavior specified by P(P).
A sequence of configurations means a list of x86 program steps >>>>>>>>>> executed or emulated in the order that their source-code
specifies.
Likewise with a TM or the UTM simulation of a TM description >>>>>>>>>> specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its >>>>>>>>> input. It is not given a sequence of state transitions. It is >>>>>>>>> given a representation of a computation.
No it is not and you know that it is not. A halt decider is
given a finite string TM description that specifies a sequence >>>>>>>> of configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the >>>>>>> latter). It's given either one or the other. Make up your mind.
André
_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]
So then the above x86 code may specify a game of tic-tac-toe and
there is no possible way to determine that it does not because the >>>>>> x86 source code of a function has nothing to do with the sequence
of steps of its correct simulation.
That is not a sequence of configurations. It is a piece of assembly
code which represents a subroutine which is an infinite loop. The
sequence of configurations would look something like this:
Yes that code specifies this sequence.
No, it does not. What you have above only generates the following
*only* if you (a) interpret it as representing x86 instructions and
(b) actually execute it on an x86 or some appropriate emulator.
Because no one in their right mind would think of doing it otherwise
those ridiculously self-evident facts need not be stated.
If it was not for communication context then every single rule of
grammar would have to be repeated with every sentence and every
definition of every work would have to be repeated over and over.
You keep claiming that the input to the decider is a sequence of
configurations, but that's just plain wrong.
The input to a decider
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations
Did you notice that I said SPECFIES this time ???
It is something which H might possibly *use* to derive such a
sequence but only when interpreted in an appropriate way and only
given an appropriate algorithm for doing so.
<sarcasm>
Yes and because it has not been explicitly specified maybe I am
talking about space aliens that are going to invade the Earth in a
space alien language that closely resembles a discussion on halt
deciders in English?
Since I did not explicitly specify that I am talking in English and
not space alien you have no sufficient basis to have any idea what my
words actually mean.
</sarcasm>
Just because you can get from A to B doesn't mean it is accurate to
refer to A as B.
André
I think what Andre is pointing out is that the string itself doesn't
generate the sequence of states, but only when interpreted as
representing the computation that it is supposed to.
On 5/27/2022 6:18 PM, Richard Damon wrote:
On 5/27/22 6:42 PM, olcott wrote:Yes and according the his reasoning I must endlessly repeat that every sentence is written in English and not some space alien language that
On 5/27/2022 5:26 PM, André G. Isaak wrote:
On 2022-05-27 16:13, olcott wrote:
On 5/27/2022 4:41 PM, André G. Isaak wrote:
On 2022-05-27 15:31, olcott wrote:
On 5/27/2022 4:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like >>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' >>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not. >>>>>>>>>>>>
The distinction that I make between represent and specify is >>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the >>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies >>>>>>>>>>> the actual behavior of this input. This is not the same
behavior as the behavior specified by P(P).
A sequence of configurations means a list of x86 program >>>>>>>>>>> steps executed or emulated in the order that their
source-code specifies.
Likewise with a TM or the UTM simulation of a TM description >>>>>>>>>>> specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as >>>>>>>>>> its input. It is not given a sequence of state transitions. It >>>>>>>>>> is given a representation of a computation.
No it is not and you know that it is not. A halt decider is
given a finite string TM description that specifies a sequence >>>>>>>>> of configurations.
A TM description and a sequence of configurations are entirely >>>>>>>> different things (and the former certainly does not 'specify'
the latter). It's given either one or the other. Make up your mind. >>>>>>>>
André
_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]
So then the above x86 code may specify a game of tic-tac-toe and >>>>>>> there is no possible way to determine that it does not because
the x86 source code of a function has nothing to do with the
sequence of steps of its correct simulation.
That is not a sequence of configurations. It is a piece of
assembly code which represents a subroutine which is an infinite
loop. The sequence of configurations would look something like this: >>>>>>
Yes that code specifies this sequence.
No, it does not. What you have above only generates the following
*only* if you (a) interpret it as representing x86 instructions and
(b) actually execute it on an x86 or some appropriate emulator.
Because no one in their right mind would think of doing it otherwise
those ridiculously self-evident facts need not be stated.
If it was not for communication context then every single rule of
grammar would have to be repeated with every sentence and every
definition of every work would have to be repeated over and over.
You keep claiming that the input to the decider is a sequence of
configurations, but that's just plain wrong.
The input to a decider
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations
Did you notice that I said SPECFIES this time ???
It is something which H might possibly *use* to derive such a
sequence but only when interpreted in an appropriate way and only
given an appropriate algorithm for doing so.
<sarcasm>
Yes and because it has not been explicitly specified maybe I am
talking about space aliens that are going to invade the Earth in a
space alien language that closely resembles a discussion on halt
deciders in English?
Since I did not explicitly specify that I am talking in English and
not space alien you have no sufficient basis to have any idea what my
words actually mean.
</sarcasm>
Just because you can get from A to B doesn't mean it is accurate to
refer to A as B.
André
I think what Andre is pointing out is that the string itself doesn't
generate the sequence of states, but only when interpreted as
representing the computation that it is supposed to.
looks just like English.
It would never ever occur to anyone that x86 source code must be
interpreted by an x86 emulator because nearly everyone would naturally
assume that x86 source-code is one of the ingredients to a milkshake.
On 27/05/2022 22:32, Richard Damon wrote:
On 5/27/22 5:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean.
Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that
the x86 source-code for P represents P(P) whereas the actual
correct x86 emulation of the input to H(P,P) specifies the actual
behavior of this input. This is not the same behavior as the
behavior specified by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies. >>>>>>
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is given
a representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
Well, a TM description, and a description of an input to that TM, does
specify a "sequence of configurations" based on what running that TM
on that input would do.
"Specify" is not the word I'd use. (If I write a shopping list I
specify what I'm going to get when I go shopping: one loaf of bread and
4oz jar of strawberry jam. I don't write various clues which can
together be used to generate what I want by applying some algorithm.)
For your scenario, "determine" seems accurate. But PO also says that
P(P) "specifies non-halting behaviour", and that computation halts. I
think that this use just means "matches PO's abort test".
The sequence of configurations may be finite (if the TM would halt on
that input) or it might be infinite (if the TM would not halt on that
input), but ANY TM description + an input generates such an output.
Just to add more room for misunderstanding, I believe Linz actually
defines "computation" as meaning your sequence of configurations, while
some define it as the combination (P,I) (which together determine Linz's calculation...). Now, anyone for "...on the basis of.."?
Mike.
On 5/28/2022 7:22 PM, Mike Terry wrote:
On 27/05/2022 22:32, Richard Damon wrote:
On 5/27/22 5:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean.
Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that >>>>>>> the x86 source-code for P represents P(P) whereas the actual
correct x86 emulation of the input to H(P,P) specifies the actual >>>>>>> behavior of this input. This is not the same behavior as the
behavior specified by P(P).
A sequence of configurations means a list of x86 program steps
executed or emulated in the order that their source-code specifies. >>>>>>>
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is
given a representation of a computation.
No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
Well, a TM description, and a description of an input to that TM,
does specify a "sequence of configurations" based on what running
that TM on that input would do.
"Specify" is not the word I'd use. (If I write a shopping list I
specify what I'm going to get when I go shopping: one loaf of bread
and 4oz jar of strawberry jam. I don't write various clues which can
together be used to generate what I want by applying some algorithm.)
For your scenario, "determine" seems accurate. But PO also says that
P(P) "specifies non-halting behaviour", and that computation halts. I
think that this use just means "matches PO's abort test".
I never said that: "P(P) specifies non-halting behaviour".
Your term "determine" is better than my term "specify".
The input to H(P,P) determines the sequence of x86 instructions of the correct x86 emulation of P by H. This sequence never reaches the "ret" instruction of P.
The input to H1(P,P) determines the sequence of x86 instructions of the correct x86 emulation of P by H1. This sequence reaches the "ret"
instruction of P and halts.
This latter sequence of x86 instructions of P is identical to the
sequence specified by P(P).
The sequence of configurations may be finite (if the TM would halt on
that input) or it might be infinite (if the TM would not halt on that
input), but ANY TM description + an input generates such an output.
Just to add more room for misunderstanding, I believe Linz actually
defines "computation" as meaning your sequence of configurations,
while some define it as the combination (P,I) (which together
determine Linz's calculation...). Now, anyone for "...on the basis
of.."?
Mike.
On Sunday, 29 May 2022 at 03:43:14 UTC+1, olcott wrote:
On 5/28/2022 7:22 PM, Mike Terry wrote:In Linz's system, a Turing machine which is purportedly a halt decider reads the description of another machine, together with the input to that
On 27/05/2022 22:32, Richard Damon wrote:I never said that: "P(P) specifies non-halting behaviour".
On 5/27/22 5:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean. >>>>>>>>> Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that >>>>>>>> the x86 source-code for P represents P(P) whereas the actual
correct x86 emulation of the input to H(P,P) specifies the actual >>>>>>>> behavior of this input. This is not the same behavior as the
behavior specified by P(P).
A sequence of configurations means a list of x86 program steps >>>>>>>> executed or emulated in the order that their source-code specifies. >>>>>>>>
Likewise with a TM or the UTM simulation of a TM description
specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its
input. It is not given a sequence of state transitions. It is given >>>>>>> a representation of a computation.
No it is not and you know that it is not. A halt decider is given a >>>>>> finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
Well, a TM description, and a description of an input to that TM, does >>>> specify a "sequence of configurations" based on what running that TM
on that input would do.
"Specify" is not the word I'd use. (If I write a shopping list I
specify what I'm going to get when I go shopping: one loaf of bread and
4oz jar of strawberry jam. I don't write various clues which can
together be used to generate what I want by applying some algorithm.)
For your scenario, "determine" seems accurate. But PO also says that
P(P) "specifies non-halting behaviour", and that computation halts. I
think that this use just means "matches PO's abort test".
Your term "determine" is better than my term "specify".
machine.
In PO's system, a fucntion works on the physical machine code which is the "machine" under test. The most important difference is that there is no dustinction between H and the representation of H embedded in H_Hat.
They are the identical transistors that hold the machine code of H.
This isn't really important, but it means that terminology can get confused.
On 5/29/2022 4:34 AM, Malcolm McLean wrote:
On Sunday, 29 May 2022 at 03:43:14 UTC+1, olcott wrote:
On 5/28/2022 7:22 PM, Mike Terry wrote:In Linz's system, a Turing machine which is purportedly a halt decider
On 27/05/2022 22:32, Richard Damon wrote:I never said that: "P(P) specifies non-halting behaviour".
On 5/27/22 5:21 PM, André G. Isaak wrote:
On 2022-05-27 14:38, olcott wrote:
On 5/27/2022 3:06 PM, André G. Isaak wrote:
On 2022-05-27 13:41, olcott wrote:
On 5/27/2022 2:10 PM, André G. Isaak wrote:
On 2022-05-27 13:01, olcott wrote:
On 5/27/2022 1:57 PM, Richard Damon wrote:
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.
I really don't think you have any idea what terms like
'represent', 'specify', or 'sequence of configurations' mean. >>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
The distinction that I make between represent and specify is that >>>>>>>>> the x86 source-code for P represents P(P) whereas the actual >>>>>>>>> correct x86 emulation of the input to H(P,P) specifies the actual >>>>>>>>> behavior of this input. This is not the same behavior as the >>>>>>>>> behavior specified by P(P).
A sequence of configurations means a list of x86 program steps >>>>>>>>> executed or emulated in the order that their source-code
specifies.
Likewise with a TM or the UTM simulation of a TM description >>>>>>>>> specifies a sequence of state transitions.
And this decidedly is *not* what a halt decider is given as its >>>>>>>> input. It is not given a sequence of state transitions. It is given >>>>>>>> a representation of a computation.
No it is not and you know that it is not. A halt decider is given a >>>>>>> finite string TM description that specifies a sequence of
configurations.
A TM description and a sequence of configurations are entirely
different things (and the former certainly does not 'specify' the
latter). It's given either one or the other. Make up your mind.
André
Well, a TM description, and a description of an input to that TM, does >>>>> specify a "sequence of configurations" based on what running that TM >>>>> on that input would do.
"Specify" is not the word I'd use. (If I write a shopping list I
specify what I'm going to get when I go shopping: one loaf of bread and >>>> 4oz jar of strawberry jam. I don't write various clues which can
together be used to generate what I want by applying some algorithm.)
For your scenario, "determine" seems accurate. But PO also says that >>>> P(P) "specifies non-halting behaviour", and that computation halts. I >>>> think that this use just means "matches PO's abort test".
Your term "determine" is better than my term "specify".
reads
the description of another machine, together with the input to that
machine.
In PO's system, a fucntion works on the physical machine code which is
the
"machine" under test. The most important difference is that there is no
dustinction between H and the representation of H embedded in H_Hat.
They are the identical transistors that hold the machine code of H.
This isn't really important, but it means that terminology can get
confused.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final
state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
Makes the behavior of the emulated input to H(P,P) the same as the
behavior of the simulated input to H ⟨Ĥ⟩ ⟨Ĥ⟩.
Halting problem undecidability and infinitely nested simulation (V5) https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
On 29/05/2022 22:56, André G. Isaak wrote:
On 2022-05-29 15:41, olcott wrote:
On 5/29/2022 4:30 PM, André G. Isaak wrote:
On 2022-05-29 15:16, olcott wrote:
On 5/29/2022 4:00 PM, André G. Isaak wrote:
On 2022-05-29 14:35, olcott wrote:
On 5/29/2022 2:58 PM, André G. Isaak wrote:
On 2022-05-29 13:26, olcott wrote:
Agree. I think PO probably can't understand the proper
definition of halting. That definition doesn't involve any >>>>>>>>>> UTMs or emulation - it's just a mathematical definition, first >>>>>>>>>> of the computation steps, then of halting in terms of there >>>>>>>>>> being an n such that computation step n is a final state of >>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
replace it with something he thinks he /can/ understand:
something more concrete - a simulation run in some "actual >>>>>>>>>> machine" processing a TM description and tape description!
HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
Every decider computes the mapping from its input finite
string(s) to an accept or reject state based on a semantic or >>>>>>>>> syntactic property of this finite string.
Finite strings don't have semantic properties.
In computability theory, Rice's theorem states that all
non-trivial semantic properties of programs are undecidable.
And how 'bout them Mets?
A semantic property is one about the program's behavior (for
instance, does the program terminate for all inputs),
https://en.wikipedia.org/wiki/Rice%27s_theorem
In formal semantics this would be the semantic property of a
finite string.
No, it would be a semantic property of the program. That program
might be *represented* as a string, but the string itself has no
semantic properties.
The semantic property of the string when it is interpreted as the
description of a program.
WHOOOSH!
As soon you you add 'when it is interpreted as...' you are no longer
talking about the string but the thing which the string represents.
Yes. The string has no semantics on its own.
The input to H(P,P) determines (Mike's word) an execution trace of
x86 instructions when correctly emulated by H.
The input to H1(P,P) determines (Mike's word) an execution trace of
x86 instructions when correctly emulated by H1.
And neither of those sentences make any sense. Replacing 'specifies'
with 'determines' doesn't make things any clearer. You need to
actually DEFINE your terms.
These execution traces are not the same.Which means at least one of the above programs is *not* interpreting
its input in the correct way, i.e. in the way which the specification
of a halt decider demands.
Hows about...
Computation P(P) goes through a sequence of steps, which for
illustration I'll just refer to as <a> <b> ... <z> with <z> being the
final (RET) step where the computation halts. Now, H and H1 calculate
these steps ["emulate their input"] something like this:
H1 H
---- ----
<a> <a> // P(P) very first state!
<b> <b>
<c> <c>
<d> <d>
<e> <e>
<f> <f>
<g> <g>
<h> <h>
<i> <i>
<j> <j>
<k> <k>
<l> <l> // no divergence so far!
<m> <m>
<n> <n>
<o> <o>
<p> <p>
<q> <q>
<r> <r> // H spots some pattern and stops simulating
<s>
<t>
<u>
<v>
<w>
<x>
<y>
<z> // P(P) final state - it halts!
So in PO language "the input to H(P,P)" is (P,P), and this determines
the steps of the computation P(P) which are being calculated by the
emulator in H, which calculates <a>...<r> then stops calculating because
it spotted some pattern. [in PO terms, <a>...<r> are the x86
instructions or their trace entries].
"the input to H1(P,P)" is also (P,P), and this determines the steps of
the computation P(P) which are being calculated by the emulator in H1,
which calculates <a>...<r>...<z> then stops because final state [ret instruction] is reached.
PO might try to deny that H1 calculates the same steps as H from <a> to
<r>, or might agree. I don't think PO really understands what's
happening in his own program. :)
In PO language, perhaps, BOTH the above are "correct emulations" because
the sequence of "x86 instruction transitions" <a> --> <b> etc. is
correct on a step-by-step basis. (That would be consistent with his
claim repeated 1000 times, that we can check the emulation is correct by comparing the machine code listings and verifying that emulation is
[doing each instruction correctly].)
H's decision to stop emulating is not (IMO) part of the emulation
itself. (How could it be? but probably that's just a matter of agreeing
the terms we're using.)
Anyhow, he who would argue with PO would do well to pin PO down on his strange choice of phrases to avoid weeks or months of
miscommunications. And you have to start by discovering /something/ you agree on... Just demanding he "defines all his terms" won't get far as
he can't "define" anything properly. :)
Mike.
André G. Isaak <agisaak@gm.invalid> writes:
On 2022-05-29 15:16, olcott wrote:
On 5/29/2022 4:00 PM, André G. Isaak wrote:
On 2022-05-29 14:35, olcott wrote:The semantic property of the string when it is interpreted as the
On 5/29/2022 2:58 PM, André G. Isaak wrote:
On 2022-05-29 13:26, olcott wrote:
Agree. I think PO probably can't understand the proper definition of halting. That definition doesn't involve any UTMs or emulation
- it's just a mathematical definition, first of the computation steps, then of halting in terms of there being an n such that
computation step n is a final state of the TM. That's TOO ABSTRACT for PO, so all he can do is replace it with something he
thinks he /can/ understand: something more concrete - a simulation run in some "actual machine" processing a TM description and tape
description!
HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
Every decider computes the mapping from its input finite string(s) to an accept or reject state based on a semantic or syntactic
property of this finite string.
Finite strings don't have semantic properties.
In computability theory, Rice's theorem states that all non-trivial semantic properties of programs are undecidable.
And how 'bout them Mets?
A semantic property is one about the program's behavior (for instance, does the program terminate for all inputs),
https://en.wikipedia.org/wiki/Rice%27s_theorem
In formal semantics this would be the semantic property of a finite string.
No, it would be a semantic property of the program. That program might be *represented* as a string, but the string itself has no semantic
properties.
description of a program.
WHOOOSH!
As soon you you add 'when it is interpreted as...' you are no longer
talking about the string but the thing which the string represents.
One of the most frustrating things about talking to PO is that he drags
the discussion down to his level. Precisely stated, Rice's theorem is
not about strings or semantics. These terms just cover the discussion
in a sort of intellectual molasses. Rice's theorem is about subsets of
ℕ and partial recursive functions that enumerate them. It is sharp and precise and involves no questions of interpretation and semantics does
not come into it. All of the wriggle and waffle room PO gives himself
comes from operating at the level of "The Ladybird Book of
Computability".
I know you know this, but I can't help noticing how effectively PO's
lack of knowledge and understanding ends up handicapping everyone else
rather then him.
On 5/29/2022 6:24 PM, Mike Terry wrote:
On 29/05/2022 22:56, André G. Isaak wrote:
On 2022-05-29 15:41, olcott wrote:
On 5/29/2022 4:30 PM, André G. Isaak wrote:
On 2022-05-29 15:16, olcott wrote:
On 5/29/2022 4:00 PM, André G. Isaak wrote:
On 2022-05-29 14:35, olcott wrote:
On 5/29/2022 2:58 PM, André G. Isaak wrote:
On 2022-05-29 13:26, olcott wrote:
Agree. I think PO probably can't understand the proper >>>>>>>>>>> definition of halting. That definition doesn't involve any >>>>>>>>>>> UTMs or emulation - it's just a mathematical definition, >>>>>>>>>>> first of the computation steps, then of halting in terms of >>>>>>>>>>> there being an n such that computation step n is a final >>>>>>>>>>> state of the TM. That's TOO ABSTRACT for PO, so all he can >>>>>>>>>>> do is replace it with something he thinks he /can/
understand: something more concrete - a simulation run in >>>>>>>>>>> some "actual machine" processing a TM description and tape >>>>>>>>>>> description!
HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
Every decider computes the mapping from its input finite
string(s) to an accept or reject state based on a semantic or >>>>>>>>>> syntactic property of this finite string.
Finite strings don't have semantic properties.
In computability theory, Rice's theorem states that all
non-trivial semantic properties of programs are undecidable.
And how 'bout them Mets?
A semantic property is one about the program's behavior (for
instance, does the program terminate for all inputs),
https://en.wikipedia.org/wiki/Rice%27s_theorem
In formal semantics this would be the semantic property of a
finite string.
No, it would be a semantic property of the program. That program >>>>>>> might be *represented* as a string, but the string itself has no >>>>>>> semantic properties.
The semantic property of the string when it is interpreted as the
description of a program.
WHOOOSH!
As soon you you add 'when it is interpreted as...' you are no
longer talking about the string but the thing which the string
represents.
Yes. The string has no semantics on its own.
The input to H(P,P) determines (Mike's word) an execution trace of
x86 instructions when correctly emulated by H.
The input to H1(P,P) determines (Mike's word) an execution trace of
x86 instructions when correctly emulated by H1.
And neither of those sentences make any sense. Replacing 'specifies'
with 'determines' doesn't make things any clearer. You need to
actually DEFINE your terms.
These execution traces are not the same.Which means at least one of the above programs is *not* interpreting
its input in the correct way, i.e. in the way which the specification
of a halt decider demands.
Hows about...
Computation P(P) goes through a sequence of steps, which for
illustration I'll just refer to as <a> <b> ... <z> with <z> being the
final (RET) step where the computation halts. Now, H and H1 calculate
these steps ["emulate their input"] something like this:
H1 H
---- ----
<a> <a> // P(P) very first state!
<b> <b>
<c> <c>
<d> <d>
<e> <e>
<f> <f>
<g> <g>
<h> <h>
<i> <i>
<j> <j>
<k> <k>
<l> <l> // no divergence so far!
<m> <m>
<n> <n>
<o> <o>
<p> <p>
<q> <q>
<r> <r> // H spots some pattern and stops simulating
<s>
<t>
<u>
<v>
<w>
<x>
<y>
<z> // P(P) final state - it halts! >>
So in PO language "the input to H(P,P)" is (P,P), and this determines
the steps of the computation P(P) which are being calculated by the
emulator in H, which calculates <a>...<r> then stops calculating
because it spotted some pattern. [in PO terms, <a>...<r> are the x86
instructions or their trace entries].
"the input to H1(P,P)" is also (P,P), and this determines the steps of
the computation P(P) which are being calculated by the emulator in H1,
which calculates <a>...<r>...<z> then stops because final state [ret
instruction] is reached.
PO might try to deny that H1 calculates the same steps as H from <a>
to <r>, or might agree. I don't think PO really understands what's
happening in his own program. :)
In PO language, perhaps, BOTH the above are "correct emulations"
because the sequence of "x86 instruction transitions" <a> --> <b> etc.
is correct on a step-by-step basis. (That would be consistent with
his claim repeated 1000 times, that we can check the emulation is
correct by comparing the machine code listings and verifying that
emulation is [doing each instruction correctly].)
H's decision to stop emulating is not (IMO) part of the emulation
itself. (How could it be? but probably that's just a matter of
agreeing the terms we're using.)
Anyhow, he who would argue with PO would do well to pin PO down on his
strange choice of phrases to avoid weeks or months of
miscommunications. And you have to start by discovering /something/
you agree on... Just demanding he "defines all his terms" won't get
far as he can't "define" anything properly. :)
Mike.
The input to H1(P,P) halts.
In this same computation the input to H(P,P)
would never reach its "ret" instruction in 1 to ∞ emulated steps.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[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]
_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P [0000137a](05) 6852130000 push 00001352 // push P [0000137f](05) e81efcffff call 00000fa2 // call H1 [00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423
[0000138d](05) e8e0f0ffff call 00000472
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= ...[00001372][0010229e][00000000] 55 push ebp ...[00001373][0010229e][00000000] 8bec mov ebp,esp ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efcffff call 00000fa2 // call H1
Begin Local Halt Decider Simulation Execution Trace Stored at:212352 H1_Root:1
...[00001352][0021233e][00212342] 55 push ebp ...[00001353][0021233e][00212342] 8bec mov ebp,esp ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08] ...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
Begin Local Halt Decider Simulation Execution Trace Stored at:25cd7a ...[00001352][0025cd66][0025cd6a] 55 push ebp ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08] ...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
...[00001352][002a778e][002a7792] 55 push ebp ...[00001353][002a778e][002a7792] 8bec mov ebp,esp ...[00001355][002a778e][002a7792] 8b4508 mov eax,[ebp+08] ...[00001358][002a778a][00001352] 50 push eax // push P
...[00001359][002a778a][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][002a7786][00001352] 51 push ecx // push P
...[0000135d][002a7782][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped ...[00001362][0021233e][00212342] 83c408 add esp,+08 ...[00001365][0021233e][00212342] 85c0 test eax,eax ...[00001367][0021233e][00212342] 7402 jz 0000136b ...[0000136b][00212342][0000107a] 5d pop ebp ...[0000136c][00212346][00001352] c3 ret ...[00001384][0010229e][00000000] 83c408 add esp,+08 ...[00001387][0010229a][00000001] 50 push eax ...[00001388][00102296][00000423] 6823040000 push 00000423 ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 Input_Halts = 1
...[00001392][0010229e][00000000] 83c408 add esp,+08 ...[00001395][0010229e][00000000] 33c0 xor eax,eax ...[00001397][001022a2][00100000] 5d pop ebp ...[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(398230) = 5,944 pages
void H_Hat(u32 P)
{
u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
H_Hat((u32)H_Hat);
}
_H_Hat()
[00000b98](01) 55 push ebp
[00000b99](02) 8bec mov ebp,esp
[00000b9c](03) 8b4508 mov eax,[ebp+08]
[00000b9f](01) 50 push eax
[00000ba0](03) 8b4d08 mov ecx,[ebp+08]
[00000ba3](01) 51 push ecx
[00000ba4](05) e88ffdffff call 00000938
[00000ba9](03) 83c408 add esp,+08
[00000bac](03) 8945fc mov [ebp-04],eax
[00000baf](04) 837dfc00 cmp dword [ebp-04],+00
[00000bb3](02) 7402 jz 00000bb7
[00000bb5](02) ebfe jmp 00000bb5
[00000bb7](02) 8be5 mov esp,ebp
[00000bb9](01) 5d pop ebp
[00000bba](01) c3 ret
Size in bytes:(0035) [00000bba]
_main()
[00000bc8](01) 55 push ebp
[00000bc9](02) 8bec mov ebp,esp
[00000bcb](05) 68980b0000 push 00000b98
[00000bd0](05) e8c3ffffff call 00000b98
[00000bd5](03) 83c404 add esp,+04
[00000bd8](02) 33c0 xor eax,eax
[00000bda](01) 5d pop ebp
[00000bdb](01) c3 ret
Size in bytes:(0020) [00000bdb]
===============================
...[00000bc8][001015d4][00000000](01) 55 push ebp ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98 ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98 ...[00000b98][001015c8][001015d4](01) 55 push ebp ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp ...[00000b9b][001015c4][00000000](01) 51 push ecx ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][001015c0][00000b98](01) 50 push eax ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][001015bc][00000b98](01) 51 push ecx ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
Begin Local Halt Decider Simulation at Machine Address:b98 ...[00000b98][00211674][00211678](01) 55 push ebp ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp ...[00000b9b][00211670][00201644](01) 51 push ecx ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0021166c][00000b98](01) 50 push eax ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][00211668][00000b98](01) 51 push ecx ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938 ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp ...[00000b9b][0025c098][0024c06c](01) 51 push ecx ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08] ...[00000b9f][0025c094][00000b98](01) 50 push eax ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08] ...[00000ba3][0025c090][00000b98](01) 51 push ecx ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08 ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00 ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7 ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp ...[00000bba][001015d0][00000b98](01) c3 ret ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04 ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax ...[00000bda][001015d8][00100000](01) 5d pop ebp ...[00000bdb][001015dc][00000098](01) c3 ret
Number_of_User_Instructions(39)
Number of Instructions Executed(26567)
On 5/29/2022 6:52 PM, Ben wrote:
André G. Isaak <agisaak@gm.invalid> writes:
On 2022-05-29 15:16, olcott wrote:
On 5/29/2022 4:00 PM, André G. Isaak wrote:
On 2022-05-29 14:35, olcott wrote:The semantic property of the string when it is interpreted as the
On 5/29/2022 2:58 PM, André G. Isaak wrote:
On 2022-05-29 13:26, olcott wrote:
Agree. I think PO probably can't understand the proper
definition of halting. That definition doesn't involve any >>>>>>>>> UTMs or emulation
- it's just a mathematical definition, first of the computation >>>>>>>>> steps, then of halting in terms of there being an n such that >>>>>>>>> computation step n is a final state of the TM. That's TOO
ABSTRACT for PO, so all he can do is replace it with something he >>>>>>>>> thinks he /can/ understand: something more concrete - a
simulation run in some "actual machine" processing a TM
description and tape
description!
HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
Every decider computes the mapping from its input finite
string(s) to an accept or reject state based on a semantic or
syntactic
property of this finite string.
Finite strings don't have semantic properties.
In computability theory, Rice's theorem states that all
non-trivial semantic properties of programs are undecidable.
And how 'bout them Mets?
A semantic property is one about the program's behavior (for
instance, does the program terminate for all inputs),
https://en.wikipedia.org/wiki/Rice%27s_theorem
In formal semantics this would be the semantic property of a
finite string.
No, it would be a semantic property of the program. That program
might be *represented* as a string, but the string itself has no
semantic
properties.
description of a program.
WHOOOSH!
As soon you you add 'when it is interpreted as...' you are no longer
talking about the string but the thing which the string represents.
One of the most frustrating things about talking to PO is that he drags
the discussion down to his level. Precisely stated, Rice's theorem is
not about strings or semantics. These terms just cover the discussion
in a sort of intellectual molasses. Rice's theorem is about subsets of
ℕ and partial recursive functions that enumerate them. It is sharp and >> precise and involves no questions of interpretation and semantics does
not come into it. All of the wriggle and waffle room PO gives himself
comes from operating at the level of "The Ladybird Book of
Computability".
I know you know this, but I can't help noticing how effectively PO's
lack of knowledge and understanding ends up handicapping everyone else
rather then him.
I prove that I am correct thus there is either some disconnect in the relationship to the other proof or my reasoning can be adapted to the
other proof.
It is true that H(P,P)==0
It is true that P forms the required HP proof relationship to H.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
Therefore it is true that I have refuted the HP proofs by making the undecidable input decidable.
Halting problem undecidability and infinitely nested simulation (V5) https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 113:11:54 |
| Calls: | 6,662 |
| Files: | 12,209 |
| Messages: | 5,336,103 |