On 3/19/22 8:51 PM, olcott wrote:
On 3/19/2022 7:48 PM, Richard Damon wrote:
That is like saying that a car cannot run because it cannot run and
On 3/19/22 8:24 PM, olcott wrote:
On 3/19/2022 7:20 PM, Richard Damon wrote:
On 3/19/22 8:00 PM, olcott wrote:I prove my point and you skip over the proof because you only want
On 3/19/2022 6:57 PM, Richard Damon wrote:
On 3/19/22 7:47 PM, olcott wrote:
Halting problem undecidability and infinitely nested simulation >>>>>>>> (V4)
When a halt decider bases its halt status decision on the
behavior of its simulated input then all of the conventional
halting problem counter example inputs would be determined to be >>>>>>>> non-halting.
A copy of Linz H is embedded at Ĥ.qx as a simulating halt
decider (SHD).
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its
final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never >>>>>>>> reach its final state.
*By these two principles this proof is validated*
(1) A halt decider (because it is a decider) must report on the >>>>>>>> behavior specified by its finite string input. A decider
computes the mapping from its input finite strings to an accept >>>>>>>> or reject state.
(2) The behavior specified by this input is the actual behavior >>>>>>>> of this input when it is correctly simulated by its simulating >>>>>>>> halt decider (SHD) that contains a full UTM.
The key point that that everyone (including Peter Linz) has an >>>>>>>> impossibly difficult time with is that embedded_H can correctly >>>>>>>> transition to Ĥ.qn indicting that its input does not halt.
Everyone (including Peter Linz) incorrectly believes that this >>>>>>>> is contradictory.
Everyone assumes the the behavior of the executed Ĥ applied ⟨Ĥ⟩ >>>>>>>> must be the same as the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H or
it is wrong.
We can easily verify that the correct behavior of Ĥ applied ⟨Ĥ⟩ >>>>>>>> is not the same as the correct behavior as the input ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>> simulated by embedded_H.
No one ever bothers to do this because of their deep religious >>>>>>>> conviction that they must either be the same or be incorrect.
https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
Just more of your Fairy Dust Powered Unicorns that do magic to
make imppssible things happen.
Just more UNSOUND LOGIC.
FAIL.
If you paid very close attention as if the salvation of your soul
depended on the accuracy of your evaluation you would see that I
have been correct all along.
No, you logic in NONSENSE, you assert things without any evidence.
to play head games.
Really??
One BIG lile is:
(2) The behavior specified by this input is the actual behavior of
this input when it is correctly simulated by its simulating halt
decider (SHD) that contains a full UTM.
Because your SHD can't actually correctly simulate as a UTM and abort
it simulation at the same time.
stop running at the same time.
Nope, just shows you still don't understand what a UTM is.
olcott <NoOne@NoWhere.com> writes:
A copy of Linz H ...
Linz is talking about Turing machines but you are not. Your magic PO-machines have the property that "exact copies" (your words) can
behave differently when applied (your word) to the same input.
To address Linz's proof you need to be talking about TMs, not magic PO-machines.
On 3/19/22 9:12 PM, olcott wrote:
On 3/19/2022 8:04 PM, Richard Damon wrote:
On 3/19/22 8:51 PM, olcott wrote:
On 3/19/2022 7:48 PM, Richard Damon wrote:
That is like saying that a car cannot run because it cannot run and
On 3/19/22 8:24 PM, olcott wrote:
On 3/19/2022 7:20 PM, Richard Damon wrote:
On 3/19/22 8:00 PM, olcott wrote:I prove my point and you skip over the proof because you only want >>>>>> to play head games.
On 3/19/2022 6:57 PM, Richard Damon wrote:
On 3/19/22 7:47 PM, olcott wrote:
Halting problem undecidability and infinitely nested
simulation (V4)
When a halt decider bases its halt status decision on the
behavior of its simulated input then all of the conventional >>>>>>>>>> halting problem counter example inputs would be determined to >>>>>>>>>> be non-halting.
A copy of Linz H is embedded at Ĥ.qx as a simulating halt >>>>>>>>>> decider (SHD).
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach
its final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never
reach its final state.
*By these two principles this proof is validated*
(1) A halt decider (because it is a decider) must report on >>>>>>>>>> the behavior specified by its finite string input. A decider >>>>>>>>>> computes the mapping from its input finite strings to an
accept or reject state.
(2) The behavior specified by this input is the actual
behavior of this input when it is correctly simulated by its >>>>>>>>>> simulating halt decider (SHD) that contains a full UTM.
The key point that that everyone (including Peter Linz) has an >>>>>>>>>> impossibly difficult time with is that embedded_H can
correctly transition to Ĥ.qn indicting that its input does not >>>>>>>>>> halt.
Everyone (including Peter Linz) incorrectly believes that this >>>>>>>>>> is contradictory.
Everyone assumes the the behavior of the executed Ĥ applied >>>>>>>>>> ⟨Ĥ⟩ must be the same as the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by
embedded_H or it is wrong.
We can easily verify that the correct behavior of Ĥ applied >>>>>>>>>> ⟨Ĥ⟩ is not the same as the correct behavior as the input ⟨Ĥ⟩
⟨Ĥ⟩ simulated by embedded_H.
No one ever bothers to do this because of their deep religious >>>>>>>>>> conviction that they must either be the same or be incorrect. >>>>>>>>>>
https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
Just more of your Fairy Dust Powered Unicorns that do magic to >>>>>>>>> make imppssible things happen.
Just more UNSOUND LOGIC.
FAIL.
If you paid very close attention as if the salvation of your
soul depended on the accuracy of your evaluation you would see >>>>>>>> that I have been correct all along.
No, you logic in NONSENSE, you assert things without any evidence. >>>>>>>
Really??
One BIG lile is:
(2) The behavior specified by this input is the actual behavior of >>>>>> this input when it is correctly simulated by its simulating halt
decider (SHD) that contains a full UTM.
Because your SHD can't actually correctly simulate as a UTM and
abort it simulation at the same time.
stop running at the same time.
Nope, just shows you still don't understand what a UTM is.
As long as the SHD can correctly simulate enough steps of its input to
correctly detect an infinite behavior pattern then it can correctly
reject its input on this basis because that means that the simulated
input cannot possibly ever reach its own final state which
conclusively proves that it specifies a non-halting sequence of
configurations.
People that are not dumber than a box of rocks will understand that
the above is necessarily correct.
Yes, if it CAN correcly simulate enough states of its input to correctly detect an infinite behavior.
The problem is that this is not guaranteed to exist. So you are just beleiving in Fairy Dust Powered Unicorns to perform their magic.
On 3/19/22 9:00 PM, olcott wrote:
On 3/19/2022 7:56 PM, Richard Damon wrote:
On 3/19/22 8:42 PM, olcott wrote:
On 3/19/2022 7:29 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
A copy of Linz H ...
Linz is talking about Turing machines but you are not. Your magic
PO-machines have the property that "exact copies" (your words) can
behave differently when applied (your word) to the same input.
To address Linz's proof you need to be talking about TMs, not magic
PO-machines.
(1) H and Ĥ aren't exact copies strcmp() proves that they differ by
the appended states. H and Ĥ use strcmp() as part of the decision
criteria.
(2) I made all of this moot months ago by only focusing on the copy
of H that is embedded within Ĥ, so when people bring up H I must
tell this this is off topic.
The key topic now is:
How can embedded_H applied to <Ĥ> <Ĥ> transition to Ĥ.qn causing Ĥ >>>> applied to <Ĥ> to halt WITHOUT FORMING ANY CONTRADICTION ?
Everyone assumes that this is impossible with such deep religious
conviction that when I explain all the details many hundreds of
times no one hears a single word.
Except that you never actually use the right definitions of things or
go into actual proofs.
A proof is any sequence of steps that necessitates a conclusion.
People assume that a proof is far more limited so they ignore my proofs.
But it must START from correct information and uses valid logic to be a
sound proof.
You can 'prove' the earth is flat if you want and don't need to conform
to actual 'facts'
You start with the WRONG definition of Halting
On 3/19/22 9:15 PM, olcott wrote:
On 3/19/2022 8:08 PM, Richard Damon wrote:
On 3/19/22 9:00 PM, olcott wrote:
On 3/19/2022 7:56 PM, Richard Damon wrote:
On 3/19/22 8:42 PM, olcott wrote:
On 3/19/2022 7:29 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
A copy of Linz H ...
Linz is talking about Turing machines but you are not. Your magic >>>>>>> PO-machines have the property that "exact copies" (your words) can >>>>>>> behave differently when applied (your word) to the same input.
To address Linz's proof you need to be talking about TMs, not magic >>>>>>> PO-machines.
(1) H and Ĥ aren't exact copies strcmp() proves that they differ
by the appended states. H and Ĥ use strcmp() as part of the
decision criteria.
(2) I made all of this moot months ago by only focusing on the
copy of H that is embedded within Ĥ, so when people bring up H I
must tell this this is off topic.
The key topic now is:
How can embedded_H applied to <Ĥ> <Ĥ> transition to Ĥ.qn causing Ĥ >>>>>> applied to <Ĥ> to halt WITHOUT FORMING ANY CONTRADICTION ?
Everyone assumes that this is impossible with such deep religious
conviction that when I explain all the details many hundreds of
times no one hears a single word.
Except that you never actually use the right definitions of things
or go into actual proofs.
A proof is any sequence of steps that necessitates a conclusion.
People assume that a proof is far more limited so they ignore my
proofs.
But it must START from correct information and uses valid logic to be
a sound proof.
You can 'prove' the earth is flat if you want and don't need to
conform to actual 'facts'
You start with the WRONG definition of Halting
Halting is reaching a final state, nothing else is halting. As long as
a SHD correctly determines that its simulated input cannot possibly
reach its final state it can correctly reject this input.
Halting is the ACTUAL Turing Machine reaching its final state.
On 3/19/22 9:31 PM, olcott wrote:
On 3/19/2022 8:25 PM, Richard Damon wrote:
On 3/19/22 9:12 PM, olcott wrote:
On 3/19/2022 8:04 PM, Richard Damon wrote:
On 3/19/22 8:51 PM, olcott wrote:
On 3/19/2022 7:48 PM, Richard Damon wrote:
That is like saying that a car cannot run because it cannot run
On 3/19/22 8:24 PM, olcott wrote:
On 3/19/2022 7:20 PM, Richard Damon wrote:
On 3/19/22 8:00 PM, olcott wrote:I prove my point and you skip over the proof because you only
On 3/19/2022 6:57 PM, Richard Damon wrote:
On 3/19/22 7:47 PM, olcott wrote:
Halting problem undecidability and infinitely nested
simulation (V4)
When a halt decider bases its halt status decision on the >>>>>>>>>>>> behavior of its simulated input then all of the conventional >>>>>>>>>>>> halting problem counter example inputs would be determined >>>>>>>>>>>> to be non-halting.
A copy of Linz H is embedded at Ĥ.qx as a simulating halt >>>>>>>>>>>> decider (SHD).
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach
its final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never
reach its final state.
*By these two principles this proof is validated*
(1) A halt decider (because it is a decider) must report on >>>>>>>>>>>> the behavior specified by its finite string input. A decider >>>>>>>>>>>> computes the mapping from its input finite strings to an >>>>>>>>>>>> accept or reject state.
(2) The behavior specified by this input is the actual >>>>>>>>>>>> behavior of this input when it is correctly simulated by its >>>>>>>>>>>> simulating halt decider (SHD) that contains a full UTM. >>>>>>>>>>>>
The key point that that everyone (including Peter Linz) has >>>>>>>>>>>> an impossibly difficult time with is that embedded_H can >>>>>>>>>>>> correctly transition to Ĥ.qn indicting that its input does >>>>>>>>>>>> not halt.
Everyone (including Peter Linz) incorrectly believes that >>>>>>>>>>>> this is contradictory.
Everyone assumes the the behavior of the executed Ĥ applied >>>>>>>>>>>> ⟨Ĥ⟩ must be the same as the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by
embedded_H or it is wrong.
We can easily verify that the correct behavior of Ĥ applied >>>>>>>>>>>> ⟨Ĥ⟩ is not the same as the correct behavior as the input ⟨Ĥ⟩
⟨Ĥ⟩ simulated by embedded_H.
No one ever bothers to do this because of their deep
religious conviction that they must either be the same or be >>>>>>>>>>>> incorrect.
https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
Just more of your Fairy Dust Powered Unicorns that do magic >>>>>>>>>>> to make imppssible things happen.
Just more UNSOUND LOGIC.
FAIL.
If you paid very close attention as if the salvation of your >>>>>>>>>> soul depended on the accuracy of your evaluation you would see >>>>>>>>>> that I have been correct all along.
No, you logic in NONSENSE, you assert things without any evidence. >>>>>>>>>
want to play head games.
Really??
One BIG lile is:
(2) The behavior specified by this input is the actual behavior >>>>>>>> of this input when it is correctly simulated by its simulating >>>>>>>> halt decider (SHD) that contains a full UTM.
Because your SHD can't actually correctly simulate as a UTM and
abort it simulation at the same time.
and stop running at the same time.
Nope, just shows you still don't understand what a UTM is.
As long as the SHD can correctly simulate enough steps of its input
to correctly detect an infinite behavior pattern then it can
correctly reject its input on this basis because that means that the
simulated input cannot possibly ever reach its own final state which
conclusively proves that it specifies a non-halting sequence of
configurations.
People that are not dumber than a box of rocks will understand that
the above is necessarily correct.
Yes, if it CAN correcly simulate enough states of its input to
correctly detect an infinite behavior.
The problem is that this is not guaranteed to exist. So you are just
beleiving in Fairy Dust Powered Unicorns to perform their magic.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
⟨Ĥ4⟩...
You acknowledged that the above sequence proves proves infinite
behavior. Thus you can I can both see that a transition to Ĥ.qn would
be correct.
It is ONLY an infinite sequence if NO embedded_H abort there
simulations,
I'm reposting the following question in this thread at Olcott's
insistence even though it doesn't belong here. The original message can
be seen in its proper context here: <t164qe$59o$2@dont-email.me>
On 2022-03-19 20:47, olcott wrote:
On 3/19/2022 9:38 PM, André G. Isaak wrote:
I changed to a different thread that does not have the lame main
thread name of Comic.
A Turing Machine has no access to *any* information apart from what
is present on its tape. Ĥ (of which your embedded_H is a part) starts
with only a *single* string on its tape.
With what, exactly, do you plan on comparing this string in making
your 'halt status decision'?
You didn't actually answer the above question. What exactly do you plan
on comparing the input to?
André
On 2022-03-20 13:12, olcott wrote:
On 3/20/2022 1:59 PM, André G. Isaak wrote:
I'm reposting the following question in this thread at Olcott's
insistence even though it doesn't belong here. The original message
can be seen in its proper context here: <t164qe$59o$2@dont-email.me>
On 2022-03-19 20:47, olcott wrote:
On 3/19/2022 9:38 PM, André G. Isaak wrote:starts
I changed to a different thread that does not have the lame main
thread name of Comic.
;
A Turing Machine has no access to *any* information apart from what >>> >> is present on its tape. Ĥ (of which your embedded_H is a part)
with only a *single* string on its tape.
;
With what, exactly, do you plan on comparing this string in making
your 'halt status decision'?
You didn't actually answer the above question. What exactly do you
plan on comparing the input to?
André
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
⟨Ĥ4⟩...
Technically the abort criteria exists when embedded_H0 would simulate
⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would otherwise
simulate an exact copy of itself with an exact copy of its inputs.
If embedded_H aborts the simulation of embedded_H0 before embedded_H0
is invoked then not even the first copy does the same thing as
embedded_H and there are no copies besides this first one.
That the infinitely nested simulation criteria is definitively met
conclusively proves that embedded_H can reject its input without
forming the contradiction that Linz claims is formed.
How does any of the above even remotely address the question I asked?
You claimed "strcmp()" played an important role in your halting
decision. (Your exact words were "When strcmp is used as the key element
of a halt status decision then this changes the behavior H relative to embedded_H for the same input")
Putting aside the fact that strcmp() is a C function which has nothing
to do with Turing machines, string comparison requires *two* strings to compare. Ĥ takes a *single* string as its input so there is only one
string on the tape. What do you plan on comparing this string with?
André
On 3/20/22 10:44 AM, olcott wrote:
On 3/20/2022 6:07 AM, Richard Damon wrote:
On 3/19/22 10:17 PM, olcott wrote:
On 3/19/2022 8:50 PM, Richard Damon wrote:
On 3/19/22 9:31 PM, olcott wrote:
On 3/19/2022 8:25 PM, Richard Damon wrote:
On 3/19/22 9:12 PM, olcott wrote:
On 3/19/2022 8:04 PM, Richard Damon wrote:
On 3/19/22 8:51 PM, olcott wrote:
On 3/19/2022 7:48 PM, Richard Damon wrote:
That is like saying that a car cannot run because it cannot >>>>>>>>>> run and stop running at the same time.
On 3/19/22 8:24 PM, olcott wrote:
On 3/19/2022 7:20 PM, Richard Damon wrote:
On 3/19/22 8:00 PM, olcott wrote:I prove my point and you skip over the proof because you >>>>>>>>>>>> only want to play head games.
On 3/19/2022 6:57 PM, Richard Damon wrote:
On 3/19/22 7:47 PM, olcott wrote:
Halting problem undecidability and infinitely nested >>>>>>>>>>>>>>>> simulation (V4)
When a halt decider bases its halt status decision on >>>>>>>>>>>>>>>> the behavior of its simulated input then all of the >>>>>>>>>>>>>>>> conventional halting problem counter example inputs >>>>>>>>>>>>>>>> would be determined to be non-halting.
A copy of Linz H is embedded at Ĥ.qx as a simulating >>>>>>>>>>>>>>>> halt decider (SHD).
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
reach its final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
never reach its final state.
*By these two principles this proof is validated* >>>>>>>>>>>>>>>>
(1) A halt decider (because it is a decider) must report >>>>>>>>>>>>>>>> on the behavior specified by its finite string input. A >>>>>>>>>>>>>>>> decider computes the mapping from its input finite >>>>>>>>>>>>>>>> strings to an accept or reject state.
(2) The behavior specified by this input is the actual >>>>>>>>>>>>>>>> behavior of this input when it is correctly simulated by >>>>>>>>>>>>>>>> its simulating halt decider (SHD) that contains a full UTM. >>>>>>>>>>>>>>>>
The key point that that everyone (including Peter Linz) >>>>>>>>>>>>>>>> has an impossibly difficult time with is that embedded_H >>>>>>>>>>>>>>>> can correctly transition to Ĥ.qn indicting that its >>>>>>>>>>>>>>>> input does not halt.
Everyone (including Peter Linz) incorrectly believes >>>>>>>>>>>>>>>> that this is contradictory.
Everyone assumes the the behavior of the executed Ĥ >>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ must be the same as the input ⟨Ĥ⟩ ⟨Ĥ⟩
simulated by embedded_H or it is wrong.
We can easily verify that the correct behavior of Ĥ >>>>>>>>>>>>>>>> applied ⟨Ĥ⟩ is not the same as the correct behavior as >>>>>>>>>>>>>>>> the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H. >>>>>>>>>>>>>>>>
No one ever bothers to do this because of their deep >>>>>>>>>>>>>>>> religious conviction that they must either be the same >>>>>>>>>>>>>>>> or be incorrect.
https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
Just more of your Fairy Dust Powered Unicorns that do >>>>>>>>>>>>>>> magic to make imppssible things happen.
Just more UNSOUND LOGIC.
FAIL.
If you paid very close attention as if the salvation of >>>>>>>>>>>>>> your soul depended on the accuracy of your evaluation you >>>>>>>>>>>>>> would see that I have been correct all along.
No, you logic in NONSENSE, you assert things without any >>>>>>>>>>>>> evidence.
Really??
One BIG lile is:
Because your SHD can't actually correctly simulate as a UTM >>>>>>>>>>> and abort it simulation at the same time.
(2) The behavior specified by this input is the actual >>>>>>>>>>>> behavior of this input when it is correctly simulated by its >>>>>>>>>>>> simulating halt decider (SHD) that contains a full UTM. >>>>>>>>>>>
Nope, just shows you still don't understand what a UTM is.
As long as the SHD can correctly simulate enough steps of its
input to correctly detect an infinite behavior pattern then it >>>>>>>> can correctly reject its input on this basis because that means >>>>>>>> that the simulated input cannot possibly ever reach its own
final state which conclusively proves that it specifies a
non-halting sequence of configurations.
People that are not dumber than a box of rocks will understand >>>>>>>> that the above is necessarily correct.
Yes, if it CAN correcly simulate enough states of its input to
correctly detect an infinite behavior.
The problem is that this is not guaranteed to exist. So you are
just beleiving in Fairy Dust Powered Unicorns to perform their
magic.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩
⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
⟨Ĥ3⟩ ⟨Ĥ4⟩...
You acknowledged that the above sequence proves proves infinite
behavior. Thus you can I can both see that a transition to Ĥ.qn
would be correct.
It is ONLY an infinite sequence if NO embedded_H abort there
simulations,
This is the part where the label of BRAIN DEAD MORON applies to you.
As long as embedded_H correctly determines that its simulated input
⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly reach its final state embedded_H can >>>> correctly reject this input.
Right, but it hasn't done that, and you seem to be too dumb to
understand why. It has (incorrectly) assumed that the copy of
embedded_H within all the simulated H^s will NEVER abort their
simulations, which they WILL do if we actually ran them, just like
this one is going to do.
FALSE PREMISE, UNSOUND LOGIG, WRONG ANSWER.
Since we can see that the simulated input to embedded_H cannot
possibly reach its final state after three invocations that means
that if embedded_H transitions to Ĥ.qn after three invocations then
we know it would be correct.
No, because when it does that, it breaks its assumption that the
embedded_H in H^s will never abort their simulations. It failed to
notice THEIR abort counter counting.
You forgert that ALL copies of a given Turing Machine, given the same
input, will do the same thing.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
⟨Ĥ4⟩...
Technically the abort criteria exists when embedded_H0 would simulate
⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would otherwise
simulate an exact copy of itself with an exact copy of its inputs.
If embedded_H aborts the simulation of embedded_H0 before embedded_H0
is invoked then not even the first copy does the same thing as
embedded_H and there are no copies besides this first one.
Nope, you still don't understand the the BEHAVIOR represented by the
input is NOT based on what the partial simulator does, but by what the machine represented by the input would actually do, which is the
equivalent of what an ACTUAL UTM (which will NEVER abort its simulation) would do.
The fact that embedded_H never simulated embedded_H0 doesn't mean that
the behavior of <H^0> <H^1> doesn't include its exectution.
Your refusal to see this is just proof that you just don't understand
what Computation Theory and Turing Machines are about.
FAIL.
On 2022-03-20 17:50, olcott wrote:
On 3/20/2022 2:25 PM, André G. Isaak wrote:
On 2022-03-20 13:12, olcott wrote:
On 3/20/2022 1:59 PM, André G. Isaak wrote:
I'm reposting the following question in this thread at Olcott's
insistence even though it doesn't belong here. The original message
can be seen in its proper context here: <t164qe$59o$2@dont-email.me> >>>>>
On 2022-03-19 20:47, olcott wrote:
On 3/19/2022 9:38 PM, André G. Isaak wrote:what
I changed to a different thread that does not have the lame main >>>>> > thread name of Comic.
;
A Turing Machine has no access to *any* information apart from
is present on its tape. Ĥ (of which your embedded_H is a part) >>>>> starts
with only a *single* string on its tape.
;
With what, exactly, do you plan on comparing this string in making >>>>> >> your 'halt status decision'?
You didn't actually answer the above question. What exactly do you
plan on comparing the input to?
André
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩
⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩
⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
⟨Ĥ4⟩...
Technically the abort criteria exists when embedded_H0 would
simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would >>>> otherwise simulate an exact copy of itself with an exact copy of its
inputs.
If embedded_H aborts the simulation of embedded_H0 before
embedded_H0 is invoked then not even the first copy does the same
thing as embedded_H and there are no copies besides this first one.
That the infinitely nested simulation criteria is definitively met
conclusively proves that embedded_H can reject its input without
forming the contradiction that Linz claims is formed.
How does any of the above even remotely address the question I asked?
You claimed "strcmp()" played an important role in your halting
decision. (Your exact words were "When strcmp is used as the key
element of a halt status decision then this changes the behavior H
relative to embedded_H for the same input")
Putting aside the fact that strcmp() is a C function which has
nothing to do with Turing machines, string comparison requires *two*
strings to compare. Ĥ takes a *single* string as its input so there
is only one string on the tape. What do you plan on comparing this
string with?
André
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
⟨Ĥ4⟩...
Because we can tell that all the copies of ⟨Ĥ⟩ are identical to each
other we know that their finite string comparisons would be identical.
You're acting very ELIZA-like here. Instead of answering the question
you are simply repeating earlier material.
The question I asked was *which* strings are being compared?
Because embedded_H is the master UTM all of these finite strings would
be somewhere on its own tape.
embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
modified version of a simulating halt decider.
The top-level embedded_H has an input consisting of two identical copies
of a single string which may or may not be ⟨Ĥ⟩. Please explain which two strings the top-level embedded_H compares and where it gets these
strings from.
We also know that when a function calls a copy of itself with
identical input that this is infinite recursion.
But embedded_H has no way of knowing whether the input it is emulating contains a copy of itself or not, therefore it has no way of recognizing recursion.
On 2022-03-20 19:39, olcott wrote:
On 3/20/2022 8:09 PM, André G. Isaak wrote:
On 2022-03-20 17:50, olcott wrote:
On 3/20/2022 2:25 PM, André G. Isaak wrote:
On 2022-03-20 13:12, olcott wrote:
On 3/20/2022 1:59 PM, André G. Isaak wrote:
I'm reposting the following question in this thread at Olcott's
insistence even though it doesn't belong here. The original
message can be seen in its proper context here:
<t164qe$59o$2@dont-email.me>
On 2022-03-19 20:47, olcott wrote:
On 3/19/2022 9:38 PM, André G. Isaak wrote:from what
I changed to a different thread that does not have the lame main >>>>>>> > thread name of Comic.
;
A Turing Machine has no access to *any* information apart
part) startsis present on its tape. Ĥ (of which your embedded_H is a
with only a *single* string on its tape.
;
With what, exactly, do you plan on comparing this string in >>>>>>> making
your 'halt status decision'?
You didn't actually answer the above question. What exactly do
you plan on comparing the input to?
André
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩
⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
⟨Ĥ3⟩ ⟨Ĥ4⟩...
Technically the abort criteria exists when embedded_H0 would
simulate ⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would >>>>>> otherwise simulate an exact copy of itself with an exact copy of
its inputs.
If embedded_H aborts the simulation of embedded_H0 before
embedded_H0 is invoked then not even the first copy does the same
thing as embedded_H and there are no copies besides this first one. >>>>>>
That the infinitely nested simulation criteria is definitively met >>>>>> conclusively proves that embedded_H can reject its input without
forming the contradiction that Linz claims is formed.
How does any of the above even remotely address the question I asked? >>>>>
You claimed "strcmp()" played an important role in your halting
decision. (Your exact words were "When strcmp is used as the key
element of a halt status decision then this changes the behavior H
relative to embedded_H for the same input")
Putting aside the fact that strcmp() is a C function which has
nothing to do with Turing machines, string comparison requires
*two* strings to compare. Ĥ takes a *single* string as its input so >>>>> there is only one string on the tape. What do you plan on comparing
this string with?
André
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩
⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩
⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
⟨Ĥ4⟩...
Because we can tell that all the copies of ⟨Ĥ⟩ are identical to each >>>> other we know that their finite string comparisons would be identical.
You're acting very ELIZA-like here. Instead of answering the question
you are simply repeating earlier material.
The question I asked was *which* strings are being compared?
Because embedded_H is the master UTM all of these finite strings
would be somewhere on its own tape.
embedded_H isn't a UTM at all, let alone a 'master UTM'. It is a
modified version of a simulating halt decider.
The top-level embedded_H has an input consisting of two identical
copies of a single string which may or may not be ⟨Ĥ⟩. Please explain >>> which two strings the top-level embedded_H compares and where it gets
these strings from.
We also know that when a function calls a copy of itself with
identical input that this is infinite recursion.
But embedded_H has no way of knowing whether the input it is
emulating contains a copy of itself or not, therefore it has no way
of recognizing recursion.
All of these details are moot at this point in the dialogue.
No, they are not moot. They are crucial details since you claim that
'string comparison' is what makes it possible for your embedded_H to recognize infinitely-recursive patterns'.
As long as we ourselves can tell that ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely >> nested simulation to embedded_H then it is necessarily correct for
embedded_H to transition to Ĥ.qn even if it does this on the basis of
a wild guess.
You claim this is infinitely recursive. Purely for sake of argument,
I'll assume this is true. You can recognize this recursion only because
you have a piece of information that embedded_H does not. You are aware
that the string you have given it is a description of Ĥ which contains embedded_H. Your embedded_H, however, has absolutely no way of knowing
this fact.
On 2022-03-20 20:21, olcott wrote:Whether or not it is even possible for embedded_H to recognize the
On 3/20/2022 9:15 PM, André G. Isaak wrote:
On 2022-03-20 20:05, olcott wrote:
This means that embedded_H can correctly reject its input even if it
does so by wild guess.
If a wild guess happens to be 'correct' that doesn't constitute a
valid algorithm.
It does constitute a correct halt decision that refutes Linz.
You not only failed to answer my question but snipped it entirely. I
have restored it for you:
Unless we have mutual agreement step-by-step you have not proven that
you are willing to have an honest dialogue.
You are the one who claimed that your embedded_H can recognize a pattern
of infinite recursion.
You are the one who claimed it did this by string comparison.
If you're not willing to actually defend your claims, how on earth can
we reach mutual agreement? And how does refusing to answer questions constitute 'honest dialogue' on your part?
Unless and until you can answer the following, I reject both of the
above claims.
On 2022-03-20 20:21, olcott wrote:
On 3/20/2022 9:15 PM, André G. Isaak wrote:
On 2022-03-20 20:05, olcott wrote:
This means that embedded_H can correctly reject its input even if it
does so by wild guess.
If a wild guess happens to be 'correct' that doesn't constitute a
valid algorithm.
It does constitute a correct halt decision that refutes Linz.
You not only failed to answer my question but snipped it entirely. I
have restored it for you:
Unless we have mutual agreement step-by-step you have not proven that
you are willing to have an honest dialogue.
You are the one who claimed that your embedded_H can recognize a pattern
of infinite recursion.
You are the one who claimed it did this by string comparison.
If you're not willing to actually defend your claims, how on earth can
we reach mutual agreement? And how does refusing to answer questions constitute 'honest dialogue' on your part?
Unless and until you can answer the following, I reject both of the
above claims.
On 2022-03-20 20:21, olcott wrote:None-the-less
On 3/20/2022 9:15 PM, André G. Isaak wrote:
On 2022-03-20 20:05, olcott wrote:
This means that embedded_H can correctly reject its input even if it
does so by wild guess.
If a wild guess happens to be 'correct' that doesn't constitute a
valid algorithm.
It does constitute a correct halt decision that refutes Linz.
You not only failed to answer my question but snipped it entirely. I
have restored it for you:
Unless we have mutual agreement step-by-step you have not proven that
you are willing to have an honest dialogue.
You are the one who claimed that your embedded_H can recognize a pattern
of infinite recursion.
You are the one who claimed it did this by string comparison.
If you're not willing to actually defend your claims, how on earth can
we reach mutual agreement? And how does refusing to answer questions constitute 'honest dialogue' on your part?
Unless and until you can answer the following, I reject both of the
above claims.
On 2022-03-20 13:12, olcott wrote:
On 3/20/2022 1:59 PM, André G. Isaak wrote:
I'm reposting the following question in this thread at Olcott's
insistence even though it doesn't belong here. The original message
can be seen in its proper context here: <t164qe$59o$2@dont-email.me>
On 2022-03-19 20:47, olcott wrote:
On 3/19/2022 9:38 PM, André G. Isaak wrote:starts
I changed to a different thread that does not have the lame main
thread name of Comic.
;
A Turing Machine has no access to *any* information apart from what >>> >> is present on its tape. Ĥ (of which your embedded_H is a part)
with only a *single* string on its tape.
;
With what, exactly, do you plan on comparing this string in making
your 'halt status decision'?
You didn't actually answer the above question. What exactly do you
plan on comparing the input to?
André
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
⟨Ĥ4⟩...
Technically the abort criteria exists when embedded_H0 would simulate
⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would otherwise
simulate an exact copy of itself with an exact copy of its inputs.
If embedded_H aborts the simulation of embedded_H0 before embedded_H0
is invoked then not even the first copy does the same thing as
embedded_H and there are no copies besides this first one.
That the infinitely nested simulation criteria is definitively met
conclusively proves that embedded_H can reject its input without
forming the contradiction that Linz claims is formed.
How does any of the above even remotely address the question I asked?
You claimed "strcmp()" played an important role in your halting
decision. (Your exact words were "When strcmp is used as the key element
of a halt status decision then this changes the behavior H relative to embedded_H for the same input")
Putting aside the fact that strcmp() is a C function which has nothing
to do with Turing machines, string comparison requires *two* strings to compare. Ĥ takes a *single* string as its input so there is only one
string on the tape. What do you plan on comparing this string with?
André
On Wednesday, 23 March 2022 at 00:57:47 UTC+8, olcott wrote:
On 3/20/2022 2:25 PM, André G. Isaak wrote:
On 2022-03-20 13:12, olcott wrote:
On 3/20/2022 1:59 PM, André G. Isaak wrote:
I'm reposting the following question in this thread at Olcott's
insistence even though it doesn't belong here. The original message
can be seen in its proper context here: <t164qe$59o$2...@dont-email.me> >>>>>
On 2022-03-19 20:47, olcott wrote:
> On 3/19/2022 9:38 PM, André G. Isaak wrote:
> I changed to a different thread that does not have the lame main >>>>> > thread name of Comic.
>
>> A Turing Machine has no access to *any* information apart from what >>>>> >> is present on its tape. Ĥ (of which your embedded_H is a part) >>>>> starts
>> with only a *single* string on its tape.
>>
>> With what, exactly, do you plan on comparing this string in making >>>>> >> your 'halt status decision'?
You didn't actually answer the above question. What exactly do you
plan on comparing the input to?
André
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
⟨Ĥ4⟩...
Technically the abort criteria exists when embedded_H0 would simulate
⟨Ĥ1⟩ ⟨Ĥ2⟩. It is at this point that embedded_H would otherwise >>>> simulate an exact copy of itself with an exact copy of its inputs.
If embedded_H aborts the simulation of embedded_H0 before embedded_H0
is invoked then not even the first copy does the same thing as
embedded_H and there are no copies besides this first one.
That the infinitely nested simulation criteria is definitively met
conclusively proves that embedded_H can reject its input without
forming the contradiction that Linz claims is formed.
How does any of the above even remotely address the question I asked?
You claimed "strcmp()" played an important role in your halting
decision. (Your exact words were "When strcmp is used as the key element >>> of a halt status decision then this changes the behavior H relative to
embedded_H for the same input")
Putting aside the fact that strcmp() is a C function which has nothing
to do with Turing machines, string comparison requires *two* strings to
compare. Ĥ takes a *single* string as its input so there is only one
string on the tape. What do you plan on comparing this string with?
André
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
We can see that an identical finite string of embedded_H continues to be
simulated with identical finite string inputs. **
This tells us that Ĥ applied to ⟨Ĥ⟩ does specify infinitely nested
simulation to the original directly executed embedded_H.
This is all that we need to refute the Linz conclusion that a that a
transition to Ĥ.qn necessarily results in a contradiction.
To prove that the input to embedded_H is decidable we need to know the
algorithm that embedded_H would use. All that this algorithm must do is
recognize the same pattern that we can see. That we can see this pattern
proves that recognizing this pattern is not categorically impossible.
I could not show the details of recognizing this pattern using actual
Turing machines because it is enormously too tedious. Even the details
of calculating the digits of PI would be far too cumbersome for hardly
anyone to understand when these details are actual Turing machine state
transitions.
It doesn't matter what programming language you use, you just do not have a real
H and P but talk that you have.
The rational approach would be to specify the algorithm in some higher
level abstraction such as a RASP machine and then map this higher level
abstraction to a Turing machine description.
** A finite string comparison can also see that these finite string are
identical. All of these finite strings are somewhere on the tape of the
UTM that is a part of the original executed not simulated embedded_H,
thus available to this embedded_H.
THE KEY POINT IS THAT THE LINZ CONCLUSION (THAT A TRANSITION TO Ĥ.QN
DERIVES A CONTRADICTION) IS REFUTED BY WHAT WE ALREADY KNOW.
TO PROVE THAT THE HALTING PROBLEM COUNTER-EXAMPLE INPUTS ARE DECIDABLE
REQUIRES KNOWING THE ALGORITHM BASIS.
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
H is a deterministic system (https://en.wikipedia.org/wiki/Deterministic_system)
No H can correctly decide (halt at y or n state) the test case P:
void P() { > if H(P) { for(;;) {}; }
}
1. You don't have such H.
Where is the claimed H these years? (just talks)
2. You don't even have a correct implement of the P above, neither.
Your version is wrong. the "H(P)" in P is difficult to implement. (no one think you can do it right)
olcott <NoOne@NoWhere.com> writes:
On 3/22/2022 11:19 PM, wij wrote:
All shown to me is that you don't know what undecidability means.
All you have shown is that you haven't bothered to read my paper yet.
You are funny! This from the man who has not even read Linz's proof
despite "working" on the problem for years. (I mean Linz's proper
proof, not the toy one presented as a historical curiosity.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 120:42:33 |
| Calls: | 6,662 |
| Files: | 12,210 |
| Messages: | 5,334,426 |