olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 5:10 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO BE REJECTED: >>>>>>>>many times and got no answer.
Linz and everyone here believes that deciders must base their decision >>>>>>>> on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ over-ruling the >>>>>>>> actual behavior specified by the actual finite string actual input. >>>>>>> Here's that question you would not answer without equivocating, even >>>>>>> after my asking it more than 12 times in a row. André also asked many,
What string must be passed to H so that H can tell us whether or not Ĥ >>>>>>> applied to ⟨Ĥ⟩ halts? Do you reject even the idea that a halt decider
could tell us whether a particular TM does or does not halt when given >>>>>>> some particular input? Isn't that what the theorem is about? (The >>>>>>> answer is, of course, yes.)
DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE DIFFERENT BEHAVIOR. >>>>>>
The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be computationally
equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ yet not the >>>>>> same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.
Failure to answer number one (or 13 if you count my previous attempts). >>>>>
Here's the question in case you missed it:
What string must be passed to H so that H can tell us whether or not Ĥ >>>>> applied to ⟨Ĥ⟩ halts?
I worked out many of the details of this, and can see why you believe
it is an important point, I will not begin to discuss this until after >>>> you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the basis that the >>>> correctly simulated input to embedded_H would never reach its own
final state in any finite number of simulated steps.
Failure to answer number two (well, 14). It's a simple question and
it's central what the halting problem is, but it's also central to why
you are wrong, which is why you know you must avoid answering it.
CORRECT DEFINITION OF HALT DECIDING CRITERIA
...
Failure to answer number three (15 including previous attempts). We all
know why you are avoiding it. Here it is again:
What string must be passed to H so that H can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts?
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 8:52 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 5:10 AM, Ben Bacarisse wrote:...
olcott <NoOne@NoWhere.com> writes:
On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO BE REJECTED: >>>>>>>>>>many times and got no answer.
Linz and everyone here believes that deciders must base their decision
on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ over-ruling the
actual behavior specified by the actual finite string actual input. >>>>>>>>> Here's that question you would not answer without equivocating, even >>>>>>>>> after my asking it more than 12 times in a row. André also asked many,
What string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts? Do you reject even the idea that a halt decider
could tell us whether a particular TM does or does not halt when given
some particular input? Isn't that what the theorem is about? (The >>>>>>>>> answer is, of course, yes.)
DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE DIFFERENT BEHAVIOR. >>>>>>>>
The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be computationally
equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ yet not the
same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.
Failure to answer number one (or 13 if you count my previous attempts). >>>>>>>
Here's the question in case you missed it:
What string must be passed to H so that H can tell us whether or not Ĥ >>>>>>> applied to ⟨Ĥ⟩ halts?
I worked out many of the details of this, and can see why you believe >>>>>> it is an important point, I will not begin to discuss this until after >>>>>> you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the basis that the >>>>>> correctly simulated input to embedded_H would never reach its own
final state in any finite number of simulated steps.
Failure to answer number two (well, 14). It's a simple question and >>>>> it's central what the halting problem is, but it's also central to why >>>>> you are wrong, which is why you know you must avoid answering it.
CORRECT DEFINITION OF HALT DECIDING CRITERIA
Failure to answer number three (15 including previous attempts). We all >>> know why you are avoiding it. Here it is again:
What string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts?
I will not tolerate any additional steps in the dialogue until we
attain mutual agreement on the current steps.
Failure to answer number four (16 including previous attempts). Here it
is again:
What string must be passed to H so that H can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts?
My reviewers must pay the cost of an honest dialogue for any dialogue
to continue.
This is pretty much the best possible outcome for me. No crank has ever admitted that their Big Idea is wrong,
so the best one can hope for is
to show that they won't answer a crucial question. The closest I will
ever get to you admitting you are wrong is your refusal to say what
string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts. The answer is central to what the halting problem is, and it's central to why you are wrong.
A one-way dialogue that only receives denigration and no points of
mutual agreement is not worth the cost of my limited time.
No, it's still two-way. I ask the obvious question that everyone knows
you can't answer, and you reply by refusing to answer it. Of course,
you can make it one-way by not replying, but I dare not hope for such
joyous outcome. It would mean everyone just needs to ask this one
question and all the sub threads would end. That's not going to happen because you are having too much fun -- at least I hope you are having
fun.
No such things as 'UTM mode', a machine either IS or IS NOT a UTM.
A simulating halt decider is in UTM mode while the behavior of its
input remains computationally equivalent to the behavior of this same
input when simulated by a UTM.
GARBAGE. If it is the equivelent behavior of its input, it does not
answer in time for a non-halting input. PERIOD.
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 9:30 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 8:52 AM, Ben Bacarisse wrote:Failure to answer number four (16 including previous attempts). Here it >>> is again:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 5:10 AM, Ben Bacarisse wrote:...
olcott <NoOne@NoWhere.com> writes:
On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO BE REJECTED: >>>>>>>>>>>>Here's that question you would not answer without equivocating, even
Linz and everyone here believes that deciders must base their decision
on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ over-ruling the
actual behavior specified by the actual finite string actual input.
after my asking it more than 12 times in a row. André also asked many,
many times and got no answer.
What string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts? Do you reject even the idea that a halt decider
could tell us whether a particular TM does or does not halt when given
some particular input? Isn't that what the theorem is about? (The >>>>>>>>>>> answer is, of course, yes.)
DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE DIFFERENT BEHAVIOR. >>>>>>>>>>
The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be computationally
equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ yet not the
same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.
Failure to answer number one (or 13 if you count my previous attempts).
Here's the question in case you missed it:
What string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts?
I worked out many of the details of this, and can see why you believe >>>>>>>> it is an important point, I will not begin to discuss this until after >>>>>>>> you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the basis that the >>>>>>>> correctly simulated input to embedded_H would never reach its own >>>>>>>> final state in any finite number of simulated steps.
Failure to answer number two (well, 14). It's a simple question and >>>>>>> it's central what the halting problem is, but it's also central to why >>>>>>> you are wrong, which is why you know you must avoid answering it. >>>>>>>
CORRECT DEFINITION OF HALT DECIDING CRITERIA
Failure to answer number three (15 including previous attempts). We all >>>>> know why you are avoiding it. Here it is again:
What string must be passed to H so that H can tell us whether or not Ĥ >>>>> applied to ⟨Ĥ⟩ halts?
I will not tolerate any additional steps in the dialogue until we
attain mutual agreement on the current steps.
What string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts?
My reviewers must pay the cost of an honest dialogue for any dialogueThis is pretty much the best possible outcome for me. No crank has ever >>> admitted that their Big Idea is wrong,
to continue.
I never admitted that my idea is wrong. I merely will not tolerate a
one-way dialogue that only provides denigration and never achieves any
mutual agreement.
I know.
so the best one can hope for is
to show that they won't answer a crucial question. The closest I will
ever get to you admitting you are wrong is your refusal to say what
string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts. The answer is central to what the halting problem
is, and it's central to why you are wrong.
A one-way dialogue that only receives denigration and no points of
mutual agreement is not worth the cost of my limited time.
No, it's still two-way. I ask the obvious question that everyone knows
you can't answer, and you reply by refusing to answer it. Of course,
My answer to that question is currently incomplete.
After 17 years studying the halting problem, you don't know what string
must be passed to H so that H can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts?
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 10:43 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 9:30 AM, Ben Bacarisse wrote:I know.
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 8:52 AM, Ben Bacarisse wrote:Failure to answer number four (16 including previous attempts). Here it >>>>> is again:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 5:10 AM, Ben Bacarisse wrote:...
olcott <NoOne@NoWhere.com> writes:
On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO BE REJECTED:Here's that question you would not answer without equivocating, even
Linz and everyone here believes that deciders must base their decision
on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ over-ruling the
actual behavior specified by the actual finite string actual input.
after my asking it more than 12 times in a row. André also asked many,
many times and got no answer.
What string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts? Do you reject even the idea that a halt decider
could tell us whether a particular TM does or does not halt when given
some particular input? Isn't that what the theorem is about? (The
answer is, of course, yes.)
DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE DIFFERENT BEHAVIOR.
The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be computationally
equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ yet not the
same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.
Failure to answer number one (or 13 if you count my previous attempts).
Here's the question in case you missed it:
What string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts?
I worked out many of the details of this, and can see why you believe
it is an important point, I will not begin to discuss this until after
you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the basis that the
correctly simulated input to embedded_H would never reach its own >>>>>>>>>> final state in any finite number of simulated steps.
Failure to answer number two (well, 14). It's a simple question and >>>>>>>>> it's central what the halting problem is, but it's also central to why
you are wrong, which is why you know you must avoid answering it. >>>>>>>>>
CORRECT DEFINITION OF HALT DECIDING CRITERIA
Failure to answer number three (15 including previous attempts). We all
know why you are avoiding it. Here it is again:
What string must be passed to H so that H can tell us whether or not Ĥ >>>>>>> applied to ⟨Ĥ⟩ halts?
I will not tolerate any additional steps in the dialogue until we
attain mutual agreement on the current steps.
What string must be passed to H so that H can tell us whether or not Ĥ >>>>> applied to ⟨Ĥ⟩ halts?
My reviewers must pay the cost of an honest dialogue for any dialogue >>>>>> to continue.This is pretty much the best possible outcome for me. No crank has ever >>>>> admitted that their Big Idea is wrong,
I never admitted that my idea is wrong. I merely will not tolerate a
one-way dialogue that only provides denigration and never achieves any >>>> mutual agreement.
After 17 years studying the halting problem, you don't know what stringso the best one can hope for isMy answer to that question is currently incomplete.
to show that they won't answer a crucial question. The closest I will >>>>> ever get to you admitting you are wrong is your refusal to say what
string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts. The answer is central to what the halting problem
is, and it's central to why you are wrong.
A one-way dialogue that only receives denigration and no points of >>>>>> mutual agreement is not worth the cost of my limited time.
No, it's still two-way. I ask the obvious question that everyone knows >>>>> you can't answer, and you reply by refusing to answer it. Of course, >>>>
must be passed to H so that H can tell us whether or not Ĥ applied to
⟨Ĥ⟩ halts?
I abandoned that as a fruitless pursuit because it is not the basis
that Linz uses for his conclusion.
OK. Every now and then I will remind readers that even after 17 years
of study you don't know know what string must be passed to H so that H
can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts.
They will know why you have "abandoned" this point. It's central to why
you are wrong so you must not consider it further!
I will not discuss your question until after we have mutual agreement
on all these points because I will not tolerate a one way dialogue
that only has denigration as feedback.
It's two-way. I ask a simple question: please complete the following
line for me:
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.q?
and you reply without answering it. Why don't you say you don't know
the answer to this question as well? That would complete your admission
of knowing almost nothing about the halting problem.
(It's three times unanswered now.)
On 4/1/22 12:24 PM, olcott wrote:
On 4/1/2022 10:59 AM, Richard Damon wrote:
On 4/1/22 11:39 AM, olcott wrote:
On 4/1/2022 10:26 AM, Richard Damon wrote:
No such things as 'UTM mode', a machine either IS or IS NOT a UTM.
A simulating halt decider is in UTM mode while the behavior of its >>>>>> input remains computationally equivalent to the behavior of this
same input when simulated by a UTM.
GARBAGE. If it is the equivelent behavior of its input, it does not
answer in time for a non-halting input. PERIOD.
We know that the behavior of the simulated input is equivalent to
the behavior of this input simulated by a UTM for every simulated
step while the SHD is in UTM mode.
Confusingly stated.
If the SHD leaves UTM mode, then the simulation by the SHD is NOT a
UTM simulation and will differ from the actual simulation by a UTM.
FACT.
You keep ignoring that the simulated input never reaches its own
simulated final state under any condition.
You keep ignoring that the simulated input never reaches its own
simulated final state under any condition.
You keep ignoring that the simulated input never reaches its own
simulated final state under any condition.
You keep ignoring that the simulated input never reaches its own
simulated final state under any condition.
You keep ignoring that the simulated input never reaches its own
simulated final state under any condition.
YOU keep forgetting that it doesn't matter what an aborted simulation
does, but what a UTM of that input would do.
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 11:38 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 10:43 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
My answer to that question is currently incomplete.
After 17 years studying the halting problem, you don't know what string >>>>> must be passed to H so that H can tell us whether or not Ĥ applied to >>>>> ⟨Ĥ⟩ halts?
I abandoned that as a fruitless pursuit because it is not the basis
that Linz uses for his conclusion.
OK. Every now and then I will remind readers that even after 17 years
of study you don't know know what string must be passed to H so that H
can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts.
They will know why you have "abandoned" this point. It's central to why >>> you are wrong so you must not consider it further!
Because of your question and my independent analysis of its relevance
I have resurrected it again.
What have you resurrected again? The hard struggle to answer this
trivial question: what string must be passed to H so that H can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts?
You certainly haven't answered it yet so I suppose you are still
struggling with it, despite it being the very starting point of the
halting problem: what string we must pass to find out about a TM/input
pair is the very first thing someone working on the halting problem has
to figure out.
Now we have the extra complexity of two
different chains of recursive simulations of halt deciders that must
coordinate with one another.
Do you think you will eventually untangle this complexity so that you
can answer this simple question? 17 years working on the halting
problem is a long time not knowing what strings one passes to a halt decider...
I will not discuss your question until after we have mutual agreementIt's two-way. I ask a simple question: please complete the following
on all these points because I will not tolerate a one way dialogue
that only has denigration as feedback.
line for me:
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.q?
and you reply without answering it. Why don't you say you don't know
the answer to this question as well? That would complete your admission >>> of knowing almost nothing about the halting problem.
(It's three times unanswered now.)
The following conclusively proves that embedded_H correctly determines
the halt status of its input.
Four times unanswered.
Unless and until we have mutual agreement on these key points
(they are the fruition of 17 years worth of work)
we cannot move on to your question.
Nothing is stopping you from answering the question. I'm including "I
don't know" as a possible answer of course.
On 2022-04-01 12:36, olcott wrote:
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
Demanding that people agree with you on specific points isn't how
dialogue actually works.
CORRECT DEFINITION OF HALT DECIDING CRITERIA
I see six statements below, none of which appear to define 'halt
deciding criteria'.
(1) All deciders compute the mapping of their input finite strings to
an accept or reject state.
Sure
(2) The direct execution of a Turing machine is computationally
equivalent to the UTM simulation of its Turing machine description.
I am willing to accept this, though it really should be written more
clearly. The UTM simulation of a computation is equivalent to that computation in some respects but not in others; so you need to better
define what is meant by 'computationally equivalent'.
(3) Halt deciders compute the mapping of their input finite strings to
an accept or reject state on the basis of the actual behavior
specified by their input.
This is horrendously worded. The input to a halt decider doesn't specify behaviour at all.
It is a concatenation of two strings, one which
encodes a TM and the other which encodes an input string. You only get behaviour when you actually apply that Turing Machine to that input
string. You'll almost certainly get people who will agree to this but
only because they interpret it as meaning something reasonable whereas
you interpret it to mean something entirely different. A correct wording would be
Halt deciders compute the mapping of their input string to an accept or reject state based on whether the Turing Machine which is encoded by the first portion of the input string would halt when applied to the string encoded by the second portion of the input string.
Strings don't have behaviours, let alone halting behaviours.
Inputs to simulators don't have behaviours. The simulation does, but the inputs do not, but the halting problem is not concerned with the
behaviour of simulations; only of actual computations. In the case of a
true simulation these should be the same, but your H is not a true
simulator, nor can it act as a proxy for one.
(4) The actual behavior specified by the input is measured by the
behavior of a UTM simulation of this input at the same point in the
execution trace as the simulating halt decider. (defined in (2) above)
This is simply incoherent gibberish. How can a UTM and a halt decider
have a 'same point in the execution trace'
given that they are entirely
different computations with entirely different 'execution traces'?
Simplified Ĥ directly calls H --- infinite loop has been removed.
Why has the infinite loop been removed? What purpose does that serve?
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
In other words every H remains in pure UTM mode until the outermost H
has complete proof that its simulated input would never reach its own
final state.
Turing Machines don't have 'modes' under any standard definition. If you
want to talk about 'modes' you need to define this term.
And your H *never* operates as a UTM so I fail to see how it can ever
operate in 'UTM mode'.
A UTM simulates the execution of each step in the computation which it
is given as an input.
It does *not* look for 'halting patterns' in that input. Any TM which
does look for these is not acting as a UTM. It does *not* make decisions about whether to abort its simulation of its input. Any TM which does
this is *not* acting as a UTM.
So unless you are claiming that your H starts simulating its input
without attempting to identify any halting patterns which might cause it
to abort, it is *never* acting as a UTM.
A simulating halt decider is in UTM mode while the behavior of its
input remains computationally equivalent to the behavior of this same
input when simulated by a UTM.
The above is meaningless. There is no 'UTM mode'.
(5) Linz: computation that halts … the Turing machine will halt
whenever it enters a final state. (Linz:1990:234)
Yes. When a turing machine enters its final state it halts.
When a simulation of a turing machine is aborted, it does not reach a
final state but that has no bearing at all on whether the computation is halting since halting is a property of computations, not of aborted simulations.
On 2022-04-01 13:51, olcott wrote:
On 4/1/2022 2:20 PM, André G. Isaak wrote:
On 2022-04-01 12:36, olcott wrote:
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
But your machine doesn't perform a 'correct simulation' of its input.
I am stopping there because that is the most significant point.
IOW, you cut the final objection I made which points out the fact that
your *entire* claim rests on a petitio. I'll restore it for you.
Claiming that your H can determine that the input is non-halting and
then abort it based on that determination presupposes the existence of a halting decider, which means you are assuming your own conclusion as
part of the assumptions you expect everyone else to agree to. This
assumption is exactly the one that the Linz proof demonstrates is false.
André
On 4/1/22 8:26 PM, olcott wrote:
On 4/1/2022 7:04 PM, Richard Damon wrote:
On 4/1/22 7:05 PM, olcott wrote:
On 4/1/2022 5:45 PM, olcott wrote:
(4) The actual behavior specified by the input is measured by the
behavior of a UTM simulation of this input at the same point in the
execution trace as the simulating halt decider. (defined in (2) above)
Here is where you go off the rails.
The Actual Behavior specified by the input is PRECISELY defined
differently, it is defined as the behavior of the ACTUAL Turing
Machine the input represents applied to the rest of the input.
That lets you move around to different places in the execution trace
besides the actual place where it is actually measured.
How? The Turing Machine/Input Combination defines a PRECISE sequence of states and Tape state that the machine will transition throught.
There is NO ambiquity.
The behavior must be the behavior of the machine being executed right
in the middle of itself, not at its normal beginning.
Nope. The behavior of a Turing Machine is NOT dependent on anything that
is not part of it. PERIOD.
The input provided to the Decider is a Machine Description/Input, and
the decider needs to respond with what that input describes. The
behavior of that input is NOT dependent on the situation the Decider is operating in, because the input is NOT somehow 'injected' into the
execution path the decider is at.
This CAN be replaced with teh UTM simulation of this input, but there
is no 'At the same point in the execution trace' as that is a
meaningless
123456789ABCDEFHIJKLMNOPQRST
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
The behavior of the simulated machine is different behavior when it is
simulated from 12 than when it is simulated from CD.
But you are looking at the wrong machine.
H is being given the input <H^> <H^> and being asked what it does.
That behavior will be identical to the behavior of the above starting at
the begining of the line.
NOTHING is asking H about any behavior starting at 'CD'
The behavior of the 12 execution depends conditionally on the behavior
of H.
Right, so when H as asked to simulate the input, starting at its
beginning, it will need to figure out what will happen at CD to get that answer. Thats H's problem.
The behavior of the CD execution DOES NOT depend conditionally on the
behavior of H because it cannot possibly break out of its infinite
recursion.
There is NO simulation being asked that starts at CD.
On 4/1/22 7:05 PM, olcott wrote:
On 4/1/2022 5:45 PM, olcott wrote:
(4) The actual behavior specified by the input is measured by the
behavior of a UTM simulation of this input at the same point in the
execution trace as the simulating halt decider. (defined in (2) above)
Here is where you go off the rails.
The Actual Behavior specified by the input is PRECISELY defined
differently, it is defined as the behavior of the ACTUAL Turing Machine
the input represents applied to the rest of the input.
This CAN be replaced with teh UTM simulation of this input, but there is
no 'At the same point in the execution trace' as that is a meaningless
On 4/1/22 10:08 PM, olcott wrote:
On 4/1/2022 9:02 PM, Richard Damon wrote:
On 4/1/22 9:52 PM, olcott wrote:
On 4/1/2022 8:40 PM, Richard Damon wrote:
I am not willing to discuss that until we have mutual agreement on
On 4/1/22 9:05 PM, olcott wrote:
On 4/1/2022 7:58 PM, Richard Damon wrote:
On 4/1/22 8:26 PM, olcott wrote:
On 4/1/2022 7:04 PM, Richard Damon wrote:
On 4/1/22 7:05 PM, olcott wrote:That lets you move around to different places in the execution >>>>>>>> trace besides the actual place where it is actually measured.
On 4/1/2022 5:45 PM, olcott wrote:
(4) The actual behavior specified by the input is measured by >>>>>>>>>> the behavior of a UTM simulation of this input at the same >>>>>>>>>> point in the execution trace as the simulating halt decider. >>>>>>>>>> (defined in (2) above)
Here is where you go off the rails.
The Actual Behavior specified by the input is PRECISELY defined >>>>>>>>> differently, it is defined as the behavior of the ACTUAL Turing >>>>>>>>> Machine the input represents applied to the rest of the input. >>>>>>>>
How? The Turing Machine/Input Combination defines a PRECISE
sequence of states and Tape state that the machine will
transition throught.
There is NO ambiquity.
The behavior must be the behavior of the machine being executed >>>>>>>> right in the middle of itself, not at its normal beginning.
Nope. The behavior of a Turing Machine is NOT dependent on
anything that is not part of it. PERIOD.
The input provided to the Decider is a Machine Description/Input, >>>>>>> and the decider needs to respond with what that input describes. >>>>>>> The behavior of that input is NOT dependent on the situation the >>>>>>> Decider is operating in, because the input is NOT somehow
'injected' into the execution path the decider is at.
This CAN be replaced with teh UTM simulation of this input, but >>>>>>>>> there is no 'At the same point in the execution trace' as that >>>>>>>>> is a meaningless
123456789ABCDEFHIJKLMNOPQRST
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
The behavior of the simulated machine is different behavior when >>>>>>>> it is simulated from 12 than when it is simulated from CD.
But you are looking at the wrong machine.
H is being given the input <H^> <H^> and being asked what it does. >>>>>>>
That behavior will be identical to the behavior of the above
starting at the begining of the line.
NOTHING is asking H about any behavior starting at 'CD'
The behavior of the 12 execution depends conditionally on the
behavior of H.
Right, so when H as asked to simulate the input, starting at its >>>>>>> beginning, it will need to figure out what will happen at CD to
get that answer. Thats H's problem.
The behavior of the CD execution DOES NOT depend conditionally >>>>>>>> on the behavior of H because it cannot possibly break out of its >>>>>>>> infinite recursion.
There is NO simulation being asked that starts at CD.
This is the point in the execution trace that you apply the UTM
and it is the wrong place because this simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ has
different behavior at 12 than its does at CD.
THIS ONE HALTS
UTM ⟨Ĥ⟩ ⟨Ĥ⟩
THIS ONE NEVER HALTS
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
Because "Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn" isn't what the input
says, so why do even think this is what is being asked? And what is
wrong with it being different. That just shows your absurdity of
trying to inject the UTM into the calculaton.
Also, Since you just AGREED that UTM ⟨Ĥ⟩ ⟨Ĥ⟩ Halts, and the rule
that you quote is
H ⟨p⟩ ⟨i⟩ ⊢* H.qy iff UTM simulated ⟨p⟩ ⟨i⟩ reaches its final state
H ⟨p⟩ ⟨i⟩ ⊢* H.qn iff UTM simulated ⟨p⟩ ⟨i⟩ would never reach its
final state
That means that H ⟨Ĥ⟩ ⟨Ĥ⟩ was supposed to go to H.qy, Right? >>>>
all the other key points.
Why, because it proves your own logic says your wrong?
I want to lock in 17 years of progress before moving on.
Not much progress if your decider still gives the wrong answer even by
your own definition.
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 7:38 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 1:29 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 11:38 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
I will not discuss your question until after we have mutual agreement >>>>>>>> on all these points because I will not tolerate a one way dialogue >>>>>>>> that only has denigration as feedback.It's two-way. I ask a simple question: please complete the following >>>>>>> line for me:
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.q?
and you reply without answering it. Why don't you say you don't know >>>>>>> the answer to this question as well? That would complete your admission
of knowing almost nothing about the halting problem.
(It's three times unanswered now.)
The following conclusively proves that embedded_H correctly determines >>>>>> the halt status of its input.
Four times unanswered.
Unless and until we have mutual agreement on these key points
(they are the fruition of 17 years worth of work)
we cannot move on to your question.
Nothing is stopping you from answering the question. I'm including "I >>>>> don't know" as a possible answer of course.
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
No it isn't. Not in the passive voice. /You/ may choose not address
these questions
Refusing to address questions stops the dialogue,
The "di" in dialogue means two.
The two of us are exchanging views. You are making unreasonable
demands, and I am asking simple questions that you won't answer. This
is a very informative dialog since it follows the pattern of all crank threads.
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
Here's where we are. After 17 years work on this you can not even say
what string must be passed to H so that H can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts, and you won't say what state H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩
transitions to even though everyone is happy to accept that
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
from which the answer is easily obtained. It would be extraordinary but
we know what's going on...
Could it be that you really don't yet know what string must be passed to
H so that H can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts? No, I don't think so. You know, as does every reader of these posts, that
it's ⟨Ĥ⟩ ⟨Ĥ⟩. And you won't say what state H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to
because you know that qy is impossible (unless your machines are magic)
and that qn is wrong.
So really, to keep this looking like there is something to debate here,
you have to not answer. The game will be up as soon as you do.
---
A correct simulation of a Turing machine description that would
never reach its final state ...
under any conditions what-so-ever
specifies a non-halting sequence of configurations.
---
olcott <NoOne@NoWhere.com> writes:
On 4/2/2022 6:07 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 7:38 PM, Ben Bacarisse wrote:The two of us are exchanging views. You are making unreasonable
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 1:29 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 11:38 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
I will not discuss your question until after we have mutual agreementIt's two-way. I ask a simple question: please complete the following >>>>>>>>> line for me:
on all these points because I will not tolerate a one way dialogue >>>>>>>>>> that only has denigration as feedback.
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.q?
and you reply without answering it. Why don't you say you don't know >>>>>>>>> the answer to this question as well? That would complete your admission
of knowing almost nothing about the halting problem.
(It's three times unanswered now.)
The following conclusively proves that embedded_H correctly determines >>>>>>>> the halt status of its input.
Four times unanswered.
Unless and until we have mutual agreement on these key points
(they are the fruition of 17 years worth of work)
we cannot move on to your question.
Nothing is stopping you from answering the question. I'm including "I >>>>>>> don't know" as a possible answer of course.
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
No it isn't. Not in the passive voice. /You/ may choose not address >>>>> these questions
Refusing to address questions stops the dialogue,
The "di" in dialogue means two.
demands, and I am asking simple questions that you won't answer. This
is a very informative dialog since it follows the pattern of all crank
threads.
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUEHere's where we are. After 17 years work on this you can not even say
what string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts, and you won't say what state H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩
transitions to even though everyone is happy to accept that
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
from which the answer is easily obtained. It would be extraordinary but >>> we know what's going on...
I did figure out the correct analysis of that.
The problem is that the result of the analysis is so counter-intuitive
that you will never pay enough attention to see that it is correct.
Good excuse not to say what string must be passed to H so that H can
tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts and what state H.q0 ⟨Ĥ⟩
⟨Ĥ⟩ transitions to!
Keep not answering. What else can you do?
---
A correct simulation of a Turing machine description that would
never reach its final state ...
under any conditions what-so-ever
specifies a non-halting sequence of configurations.
---
olcott <NoOne@NoWhere.com> writes:
On 4/2/2022 6:07 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 7:38 PM, Ben Bacarisse wrote:The two of us are exchanging views. You are making unreasonable
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 1:29 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/1/2022 11:38 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
I will not discuss your question until after we have mutual agreementIt's two-way. I ask a simple question: please complete the following >>>>>>>>> line for me:
on all these points because I will not tolerate a one way dialogue >>>>>>>>>> that only has denigration as feedback.
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.q?
and you reply without answering it. Why don't you say you don't know >>>>>>>>> the answer to this question as well? That would complete your admission
of knowing almost nothing about the halting problem.
(It's three times unanswered now.)
The following conclusively proves that embedded_H correctly determines >>>>>>>> the halt status of its input.
Four times unanswered.
Unless and until we have mutual agreement on these key points
(they are the fruition of 17 years worth of work)
we cannot move on to your question.
Nothing is stopping you from answering the question. I'm including "I >>>>>>> don't know" as a possible answer of course.
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
No it isn't. Not in the passive voice. /You/ may choose not address >>>>> these questions
Refusing to address questions stops the dialogue,
The "di" in dialogue means two.
demands, and I am asking simple questions that you won't answer. This
is a very informative dialog since it follows the pattern of all crank
threads.
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUEHere's where we are. After 17 years work on this you can not even say
what string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts, and you won't say what state H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩
transitions to even though everyone is happy to accept that
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
from which the answer is easily obtained. It would be extraordinary but >>> we know what's going on...
I did figure out the correct analysis of that.
The problem is that the result of the analysis is so counter-intuitive
that you will never pay enough attention to see that it is correct.
Good excuse not to say what string must be passed to H so that H can
tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts and what state H.q0 ⟨Ĥ⟩
⟨Ĥ⟩ transitions to!
Keep not answering. What else can you do?
On 4/3/2022 9:10 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/2/2022 6:57 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/2/2022 6:07 PM, Ben Bacarisse wrote:
Here's where we are. After 17 years work on this you can not even >>>>>> say
what string must be passed to H so that H can tell us whether or
not Ĥ
applied to ⟨Ĥ⟩ halts, and you won't say what state H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩
transitions to even though everyone is happy to accept that
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
from which the answer is easily obtained. It would be
extraordinary but
we know what's going on...
I did figure out the correct analysis of that.
The problem is that the result of the analysis is so counter-intuitive >>>>> that you will never pay enough attention to see that it is correct.
Good excuse not to say what string must be passed to H so that H can
tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts and what state H.q0 ⟨Ĥ⟩
⟨Ĥ⟩ transitions to!
Keep not answering. What else can you do?
If you want an honest dialogue you will go through the trouble of
working through mutual agreement on my key points...
Mutual agreement on nonsense can never form the basis of any reasonable
discussion.
That you can only dogmatically say that it is nonsense and not point out
any error really seems to prove that you have no idea what I am saying because of your lack of technical skill.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 105:04:17 |
| Calls: | 6,660 |
| Calls today: | 2 |
| Files: | 12,209 |
| Messages: | 5,335,309 |