On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote:its final state after n+k steps and Hb accepts <Ha^><Ha^>. Therefore Ha, and subsequently embedded_Ha, does *not* correctly simulate its input.
On 3/31/2022 10:16 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote:
On 3/31/2022 9:34 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott wrote:
On 3/31/2022 9:23 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott wrote:
On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:I worked out many of the details of this, and can see why you believe it
On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
olcott <No...@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?
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.
embedded_Ha, and therefore Ha, is not correct to reject <Ha^><Ha^> because it quits its simulation after n steps which is too soon. When this same input is given to simulating halt decider Hb which simulates for n+k steps, the input does reach
failure.That you can make up some screwy thing that doesn't work says nothingI am only talking about Ĥ applied ⟨Ĥ⟩ and its associated semantics anyI will simply say that I am ignoring another strawman error.
Just saying "strawman" isn't good enough.
change in notation or semantics is off topic.
I am sure that you can make a million halt deciders that don't work they >>>> are all strawman.
So you can't explain why Hb is wrong, and have therefore implicitly admitted it is correct.
So what are you doing to do now that your proof has been refuted?
about my proof. If you were talking about my proof then you have to use
my notation, my semantics and find an error in that.
How exactly is it that Hb "doesn't work"?
When you talk about H / embedded_H that "correctly" reports non-halting for H^, you're talking about an H that aborts it's simulation. That's Ha / embedded_Ha and Ha^ is built from that. What I said still stands. So state why Hb is wrong or admit
embedded_Ha, and therefore Ha, is not correct to reject <Ha^><Ha^>because it quits its simulation after n steps which is too soon. When
On 4/1/22 8:08 AM, olcott wrote:
On 4/1/2022 6:36 AM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote:
On 3/31/2022 10:16 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote:That you can make up some screwy thing that doesn't work says nothing
On 3/31/2022 9:34 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott wrote: >>>>>>>> On 3/31/2022 9:23 PM, Dennis Bush wrote:I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated semantics >>>>>> any
On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott wrote: >>>>>>>>>> On 3/31/2022 3:27 PM, Ben Bacarisse wrote:I will simply say that I am ignoring another strawman error.
olcott <No...@NoWhere.com> writes:I worked out many of the details of this, and can see why you >>>>>>>>>> believe it
On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
olcott <No...@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
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.
equivocating, even
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?
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.
embedded_Ha, and therefore Ha, is not correct to reject
<Ha^><Ha^> because it quits its simulation after n steps which >>>>>>>>> is too soon. When this same input is given to simulating halt >>>>>>>>> decider Hb which simulates for n+k steps, the input does reach >>>>>>>>> its final state after n+k steps and Hb accepts <Ha^><Ha^>.
Therefore Ha, and subsequently embedded_Ha, does *not*
correctly simulate its input.
Just saying "strawman" isn't good enough.
change in notation or semantics is off topic.
I am sure that you can make a million halt deciders that don't
work they
are all strawman.
So you can't explain why Hb is wrong, and have therefore implicitly
admitted it is correct.
So what are you doing to do now that your proof has been refuted?
about my proof. If you were talking about my proof then you have to use >>>> my notation, my semantics and find an error in that.
How exactly is it that Hb "doesn't work"?
When you talk about H / embedded_H that "correctly" reports
non-halting for H^, you're talking about an H that aborts it's
simulation. That's Ha / embedded_Ha and Ha^ is built from that.
What I said still stands. So state why Hb is wrong or admit failure.
On 3/31/2022 9:23 PM, Dennis Bush wrote:
embedded_Ha, and therefore Ha, is not correct to reject <Ha^><Ha^>because it quits its simulation after n steps which is too soon. When
this same input is given to simulating halt decider Hb which simulates
for n+k steps, the input does reach its final state after n+k steps
and Hb accepts <Ha^><Ha^>. Therefore Ha, and subsequently
embedded_Ha, does *not* correctly simulate its input.
It is like I talk about driving my car to show that my car can be
driven so you drive a car into a tree to show that a car cannot be
driven.
Here are the simplified notational conventions and semantics:
(Any attempt to diverge from the specified semantics will be construed
as the strawman error and marked as ignored)
We will just call the halt decider H:
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
Simplified Ĥ directly calls H --- infinite loop has been removed.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
THe problem with your 'simplified' H^ is that a smart H could just
answer by going to Qy and be correct, but since yours doesn't, that
isn't a fatal flaw to your argument.
H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> -> H.Qn only
if UTM simulaton of <p> <i> will never halt, but we show that since UTM simulation of <H^> <H^> is the same as H^ applied to <H^> and that goes
to H.Qn and HALTS, so does the UTM Simulation.
On 4/1/22 9:25 AM, olcott wrote:
On 4/1/2022 7:52 AM, Richard Damon wrote:
On 4/1/22 8:08 AM, olcott wrote:
On 4/1/2022 6:36 AM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote:
On 3/31/2022 10:16 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote: >>>>>>>> On 3/31/2022 9:34 PM, Dennis Bush wrote:to use
On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott wrote: >>>>>>>>>> On 3/31/2022 9:23 PM, Dennis Bush wrote:I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated >>>>>>>> semantics any
Just saying "strawman" isn't good enough.On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 3/31/2022 3:27 PM, Ben Bacarisse wrote:I will simply say that I am ignoring another strawman error. >>>>>>>>>
olcott <No...@NoWhere.com> writes:I worked out many of the details of this, and can see why >>>>>>>>>>>> you believe it
On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
olcott <No...@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?
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.
embedded_Ha, and therefore Ha, is not correct to reject
<Ha^><Ha^> because it quits its simulation after n steps >>>>>>>>>>> which is too soon. When this same input is given to
simulating halt decider Hb which simulates for n+k steps, the >>>>>>>>>>> input does reach its final state after n+k steps and Hb
accepts <Ha^><Ha^>. Therefore Ha, and subsequently
embedded_Ha, does *not* correctly simulate its input.
change in notation or semantics is off topic.
I am sure that you can make a million halt deciders that don't >>>>>>>> work they
are all strawman.
So you can't explain why Hb is wrong, and have therefore
implicitly admitted it is correct.
So what are you doing to do now that your proof has been refuted? >>>>>> That you can make up some screwy thing that doesn't work says nothing >>>>>> about my proof. If you were talking about my proof then you have
my notation, my semantics and find an error in that.
How exactly is it that Hb "doesn't work"?
When you talk about H / embedded_H that "correctly" reports
non-halting for H^, you're talking about an H that aborts it's
simulation. That's Ha / embedded_Ha and Ha^ is built from that.
What I said still stands. So state why Hb is wrong or admit failure. >>>>>
On 3/31/2022 9:23 PM, Dennis Bush wrote:
embedded_Ha, and therefore Ha, is not correct to reject<Ha^><Ha^> because it quits its simulation after n steps which is
too soon. When this same input is given to simulating halt decider
Hb which simulates for n+k steps, the input does reach its final
state after n+k steps and Hb accepts <Ha^><Ha^>. Therefore Ha, and
subsequently embedded_Ha, does *not* correctly simulate its input.
It is like I talk about driving my car to show that my car can be
driven so you drive a car into a tree to show that a car cannot be
driven.
Here are the simplified notational conventions and semantics:
(Any attempt to diverge from the specified semantics will be
construed as the strawman error and marked as ignored)
We will just call the halt decider H:
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
Simplified Ĥ directly calls H --- infinite loop has been removed.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
THe problem with your 'simplified' H^ is that a smart H could just
answer by going to Qy and be correct, but since yours doesn't, that
isn't a fatal flaw to your argument.
H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> -> H.Qn
only if UTM simulaton of <p> <i> will never halt, but we show that
since UTM simulation of <H^> <H^> is the same as H^ applied to <H^>
and that goes to H.Qn and HALTS, so does the UTM Simulation.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
// while every H remains in pure UTM mode
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
No such thing as 'UTM Mode', a machine either is or is not a UTM.
On 4/1/22 10:11 AM, olcott wrote:
On 4/1/2022 9:03 AM, Richard Damon wrote:
On 4/1/22 9:25 AM, olcott wrote:
On 4/1/2022 7:52 AM, Richard Damon wrote:
On 4/1/22 8:08 AM, olcott wrote:
On 4/1/2022 6:36 AM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote: >>>>>>>> On 3/31/2022 10:16 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote: >>>>>>>>>> On 3/31/2022 9:34 PM, Dennis Bush wrote:nothing
On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 3/31/2022 9:23 PM, Dennis Bush wrote:I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated >>>>>>>>>> semantics any
Just saying "strawman" isn't good enough.On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
embedded_Ha, and therefore Ha, is not correct to reject >>>>>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n steps >>>>>>>>>>>>> which is too soon. When this same input is given toolcott <No...@NoWhere.com> writes:I worked out many of the details of this, and can see why >>>>>>>>>>>>>> you believe it
On 3/31/2022 11:09 AM, Ben Bacarisse wrote:Failure to answer number one (or 13 if you count my >>>>>>>>>>>>>>> previous attempts).
olcott <No...@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 Ĥ. >>>>>>>>>>>>>>>
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?
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. >>>>>>>>>>>>>
simulating halt decider Hb which simulates for n+k steps, >>>>>>>>>>>>> the input does reach its final state after n+k steps and Hb >>>>>>>>>>>>> accepts <Ha^><Ha^>. Therefore Ha, and subsequently
embedded_Ha, does *not* correctly simulate its input. >>>>>>>>>>>> I will simply say that I am ignoring another strawman error. >>>>>>>>>>>
change in notation or semantics is off topic.
I am sure that you can make a million halt deciders that don't >>>>>>>>>> work they
are all strawman.
So you can't explain why Hb is wrong, and have therefore
implicitly admitted it is correct.
So what are you doing to do now that your proof has been refuted? >>>>>>>> That you can make up some screwy thing that doesn't work says
about my proof. If you were talking about my proof then you have >>>>>>>> to use
my notation, my semantics and find an error in that.
How exactly is it that Hb "doesn't work"?
When you talk about H / embedded_H that "correctly" reports
non-halting for H^, you're talking about an H that aborts it's
simulation. That's Ha / embedded_Ha and Ha^ is built from that. >>>>>>> What I said still stands. So state why Hb is wrong or admit
failure.
On 3/31/2022 9:23 PM, Dennis Bush wrote:
embedded_Ha, and therefore Ha, is not correct to reject<Ha^><Ha^> because it quits its simulation after n steps which is
too soon. When this same input is given to simulating halt decider >>>>>> Hb which simulates for n+k steps, the input does reach its final
state after n+k steps and Hb accepts <Ha^><Ha^>. Therefore Ha,
and subsequently embedded_Ha, does *not* correctly simulate its
input.
It is like I talk about driving my car to show that my car can be
driven so you drive a car into a tree to show that a car cannot be >>>>>> driven.
Here are the simplified notational conventions and semantics:
(Any attempt to diverge from the specified semantics will be
construed as the strawman error and marked as ignored)
We will just call the halt decider H:
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
Simplified Ĥ directly calls H --- infinite loop has been removed. >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
THe problem with your 'simplified' H^ is that a smart H could just
answer by going to Qy and be correct, but since yours doesn't, that
isn't a fatal flaw to your argument.
H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> -> H.Qn
only if UTM simulaton of <p> <i> will never halt, but we show that
since UTM simulation of <H^> <H^> is the same as H^ applied to <H^>
and that goes to H.Qn and HALTS, so does the UTM Simulation.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
// while every H remains in pure UTM mode
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
No such thing 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.
Nope, just shows you don't understand what a UTM is.
On 4/1/22 11:20 AM, olcott wrote:
On 4/1/2022 9:28 AM, Richard Damon wrote:
On 4/1/22 10:11 AM, olcott wrote:
On 4/1/2022 9:03 AM, Richard Damon wrote:
On 4/1/22 9:25 AM, olcott wrote:
On 4/1/2022 7:52 AM, Richard Damon wrote:
On 4/1/22 8:08 AM, olcott wrote:
On 4/1/2022 6:36 AM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote: >>>>>>>>>> On 3/31/2022 10:16 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 3/31/2022 9:34 PM, Dennis Bush wrote:That you can make up some screwy thing that doesn't work says >>>>>>>>>> nothing
On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott >>>>>>>>>>>>> wrote:I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated >>>>>>>>>>>> semantics any
On 3/31/2022 9:23 PM, Dennis Bush wrote:Just saying "strawman" isn't good enough.
On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott >>>>>>>>>>>>>>> wrote:
On 3/31/2022 3:27 PM, Ben Bacarisse wrote:embedded_Ha, and therefore Ha, is not correct to reject >>>>>>>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n steps >>>>>>>>>>>>>>> which is too soon. When this same input is given to >>>>>>>>>>>>>>> simulating halt decider Hb which simulates for n+k steps, >>>>>>>>>>>>>>> the input does reach its final state after n+k steps and >>>>>>>>>>>>>>> Hb accepts <Ha^><Ha^>. Therefore Ha, and subsequently >>>>>>>>>>>>>>> embedded_Ha, does *not* correctly simulate its input. >>>>>>>>>>>>>> I will simply say that I am ignoring another strawman error. >>>>>>>>>>>>>
olcott <No...@NoWhere.com> writes:I worked out many of the details of this, and can see >>>>>>>>>>>>>>>> why you believe it
On 3/31/2022 11:09 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:Failure to answer number one (or 13 if you count my >>>>>>>>>>>>>>>>> previous attempts).
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 Ĥ. >>>>>>>>>>>>>>>>>
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?
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. >>>>>>>>>>>>>>>
change in notation or semantics is off topic.
I am sure that you can make a million halt deciders that >>>>>>>>>>>> don't work they
are all strawman.
So you can't explain why Hb is wrong, and have therefore >>>>>>>>>>> implicitly admitted it is correct.
So what are you doing to do now that your proof has been >>>>>>>>>>> refuted?
about my proof. If you were talking about my proof then you >>>>>>>>>> have to use
my notation, my semantics and find an error in that.
How exactly is it that Hb "doesn't work"?
When you talk about H / embedded_H that "correctly" reports
non-halting for H^, you're talking about an H that aborts it's >>>>>>>>> simulation. That's Ha / embedded_Ha and Ha^ is built from
that. What I said still stands. So state why Hb is wrong or >>>>>>>>> admit failure.
On 3/31/2022 9:23 PM, Dennis Bush wrote:
embedded_Ha, and therefore Ha, is not correct to reject<Ha^><Ha^> because it quits its simulation after n steps which >>>>>>>> is too soon. When this same input is given to simulating halt
decider Hb which simulates for n+k steps, the input does reach >>>>>>>> its final state after n+k steps and Hb accepts <Ha^><Ha^>.
Therefore Ha, and subsequently embedded_Ha, does *not* correctly >>>>>>>> simulate its input.
It is like I talk about driving my car to show that my car can >>>>>>>> be driven so you drive a car into a tree to show that a car
cannot be driven.
Here are the simplified notational conventions and semantics:
(Any attempt to diverge from the specified semantics will be
construed as the strawman error and marked as ignored)
We will just call the halt decider H:
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
Simplified Ĥ directly calls H --- infinite loop has been removed. >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
THe problem with your 'simplified' H^ is that a smart H could
just answer by going to Qy and be correct, but since yours
doesn't, that isn't a fatal flaw to your argument.
H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> ->
H.Qn only if UTM simulaton of <p> <i> will never halt, but we
show that since UTM simulation of <H^> <H^> is the same as H^
applied to <H^> and that goes to H.Qn and HALTS, so does the UTM >>>>>>> Simulation.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
// while every H remains in pure UTM mode
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
No such thing 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.
Nope, just shows you don't understand what a UTM is.
Any Turing machine can have the full capability of a UTM within it
that it can use to simulate the Turing Machine description of any
halting computation to completion. It can also simulate one single
state transition at a time as a sequence of simulated steps.
Although it is not a UTM the behavior of the simulated input while the
simulating halt decider is in UTM mode is equivalent to its behavior
when simulated by an actual UTM.
Yes, it can use UTM code modified to perform some action.
The final machine is NOT a UTM unless it meets the actual definiton of a
UTM.
Just like you can take a 'street-legal' car, and modify it for some
purpose, and it may no longer be 'street-legal'
If H no longer meets the definition of a UTM, then it isn't a UTM, even
if it used UTM like code to make its decision.
Since H LEAVES UTM mode,
the behavior of the machine it is simulating,
if it contains a copy of H, must be simulated and analyised under the condition of considering that it too will leave UTM mode.
Thus H considering its inputs behavior ONLY under the condition that the input will stay in UTM is UNSOUND LOGIC, based on a FALSE PREMISE.
This is why your whole arguement fails.
YOU ARE JUST WRONG.
FAIL.
On 4/1/22 11:45 AM, olcott wrote:
On 4/1/2022 10:35 AM, Richard Damon wrote:
On 4/1/22 11:20 AM, olcott wrote:
On 4/1/2022 9:28 AM, Richard Damon wrote:
On 4/1/22 10:11 AM, olcott wrote:
On 4/1/2022 9:03 AM, Richard Damon wrote:
On 4/1/22 9:25 AM, olcott wrote:A simulating halt decider is in UTM mode while the behavior of its >>>>>> input remains computationally equivalent to the behavior of this
On 4/1/2022 7:52 AM, Richard Damon wrote:
On 4/1/22 8:08 AM, olcott wrote:
On 4/1/2022 6:36 AM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 3/31/2022 10:16 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott >>>>>>>>>>>>> wrote:That you can make up some screwy thing that doesn't work >>>>>>>>>>>> says nothing
On 3/31/2022 9:34 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott >>>>>>>>>>>>>>> wrote:I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated >>>>>>>>>>>>>> semantics any
On 3/31/2022 9:23 PM, Dennis Bush wrote:
On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott >>>>>>>>>>>>>>>>> wrote:I will simply say that I am ignoring another strawman >>>>>>>>>>>>>>>> error.
On 3/31/2022 3:27 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:embedded_Ha, and therefore Ha, is not correct to reject >>>>>>>>>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n >>>>>>>>>>>>>>>>> steps which is too soon. When this same input is given >>>>>>>>>>>>>>>>> to simulating halt decider Hb which simulates for n+k >>>>>>>>>>>>>>>>> steps, the input does reach its final state after n+k >>>>>>>>>>>>>>>>> steps and Hb accepts <Ha^><Ha^>. Therefore Ha, and >>>>>>>>>>>>>>>>> subsequently embedded_Ha, does *not* correctly simulate >>>>>>>>>>>>>>>>> its input.
I worked out many of the details of this, and can see >>>>>>>>>>>>>>>>>> why you believe it
On 3/31/2022 11:09 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:Failure to answer number one (or 13 if you count my >>>>>>>>>>>>>>>>>>> previous attempts).
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 Ĥ. >>>>>>>>>>>>>>>>>>>
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?
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. >>>>>>>>>>>>>>>>>
Just saying "strawman" isn't good enough.
change in notation or semantics is off topic.
I am sure that you can make a million halt deciders that >>>>>>>>>>>>>> don't work they
are all strawman.
So you can't explain why Hb is wrong, and have therefore >>>>>>>>>>>>> implicitly admitted it is correct.
So what are you doing to do now that your proof has been >>>>>>>>>>>>> refuted?
about my proof. If you were talking about my proof then you >>>>>>>>>>>> have to use
my notation, my semantics and find an error in that.
How exactly is it that Hb "doesn't work"?
When you talk about H / embedded_H that "correctly" reports >>>>>>>>>>> non-halting for H^, you're talking about an H that aborts >>>>>>>>>>> it's simulation. That's Ha / embedded_Ha and Ha^ is built >>>>>>>>>>> from that. What I said still stands. So state why Hb is >>>>>>>>>>> wrong or admit failure.
On 3/31/2022 9:23 PM, Dennis Bush wrote:
embedded_Ha, and therefore Ha, is not correct to reject >>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n steps which >>>>>>>>>> is too soon. When this same input is given to simulating halt >>>>>>>>>> decider Hb which simulates for n+k steps, the input does reach >>>>>>>>>> its final state after n+k steps and Hb accepts <Ha^><Ha^>. >>>>>>>>>> Therefore Ha, and subsequently embedded_Ha, does *not*correctly simulate its input.
It is like I talk about driving my car to show that my car can >>>>>>>>>> be driven so you drive a car into a tree to show that a car >>>>>>>>>> cannot be driven.
Here are the simplified notational conventions and semantics: >>>>>>>>>> (Any attempt to diverge from the specified semantics will be >>>>>>>>>> construed as the strawman error and marked as ignored)
We will just call the halt decider H:
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
Simplified Ĥ directly calls H --- infinite loop has been removed. >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
THe problem with your 'simplified' H^ is that a smart H could >>>>>>>>> just answer by going to Qy and be correct, but since yours
doesn't, that isn't a fatal flaw to your argument.
H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> -> >>>>>>>>> H.Qn only if UTM simulaton of <p> <i> will never halt, but we >>>>>>>>> show that since UTM simulation of <H^> <H^> is the same as H^ >>>>>>>>> applied to <H^> and that goes to H.Qn and HALTS, so does the >>>>>>>>> UTM Simulation.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
// while every H remains in pure UTM mode
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
No such thing as 'UTM Mode', a machine either is or is not a UTM. >>>>>>
same input when simulated by a UTM.
Nope, just shows you don't understand what a UTM is.
Any Turing machine can have the full capability of a UTM within it
that it can use to simulate the Turing Machine description of any
halting computation to completion. It can also simulate one single
state transition at a time as a sequence of simulated steps.
Although it is not a UTM the behavior of the simulated input while
the simulating halt decider is in UTM mode is equivalent to its
behavior when simulated by an actual UTM.
Yes, it can use UTM code modified to perform some action.
The final machine is NOT a UTM unless it meets the actual definiton
of a UTM.
Just like you can take a 'street-legal' car, and modify it for some
purpose, and it may no longer be 'street-legal'
If H no longer meets the definition of a UTM, then it isn't a UTM,
even if it used UTM like code to make its decision.
Since H LEAVES UTM mode,
It does not always level UTM mode.
Some inputs specify halting computations.
But not this case.
Yes, there are cases where it won't leave UTM mode, and for those it
doesn't need to consider that case, but if it will leave UTM mode, it
needs to consider that.
In particular, any input it wants to call non-halting, it MUST consider
that it WILL leave UTM mode.
For H <H^> <H^> we have established that H MUST leave UTM mode or it
fails to be a decider.
You are just going to your Red Herring Strawman.
the behavior of the machine it is simulating, if it contains a copy
of H, must be simulated and analyised under the condition of
considering that it too will leave UTM mode.
When H rejects its input this means that the simulated input would
never reach its own final state under any condition: aborted or
infinitely simulated.
Nope. If H -> Qn, then the CORRECT simulation (by a REAL UTM) of <H^>
<H^> Halts, BECAUSE H^ applied to <H^> halts, because it sees its copy
of H -> Qn.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 107:39:59 |
| Calls: | 6,662 |
| Calls today: | 4 |
| Files: | 12,209 |
| Messages: | 5,335,499 |