On Saturday, 16 April 2022 at 14:31:29 UTC+1, B.H. wrote:
On Friday, April 15, 2022 at 11:51:24 PM UTC-4, Jeff Barnett wrote:I don't think PO is trolling. He's too persistent for that. And sometimes he makes errors that that make him look foolish, such as saying that a Turing machine needs 1000 states to move the head 1000 steps. That goes against trollish psychology.
There is absolutely no reason to believe that idiot is dying at anYou think there is no such thing as cancer?
accelerated rate. He is a troll who lies about everything if it will
drag a dialogue partner along. But I do believe that he is dying ofWhat's wrong with that, why is that a rule, and even if it is a rule, why is >> it so irritating to you? You would likely be able to generate more threads >> if you didn't look like a cantakerous jerk, although maybe you would prefer >> to do it your way. Your way of acting and presenting yourself, regardless
laughter at all the nonsense threads he can generate and support. It
of what you think inwardly in your mind and don't say, isn't up to me, it is >> your choice.
sure doesn't mean his brain is actually working; it probably isn't andHis brain sounds fine to me.
he is auto deluded or it is and he is an utter fool.
Also, he accepts that P(P) halts and that H(P,P) returns "non-halting". As Ben
says, that's a tough hill to fight on, and the most straightforwards explanation
is that he is telling the truth.
I think he believes he has seen something that no-one else has, and that he can't communicate that to other people here. And I think I know what it is - essentially his "simulating halt decider" can't get the right answer, for a reason that isn't directly related to the so-called "Linz proof". The "infinite
nesting detector" must always detect infinite nesting one step before the simulator it is simulating does the same.
He reasons that therefore the
"simulating halt decider" is making the right call instead of the wrong call, by a step I can't quite follow.
However to explain this to him i too difficult. Some other posters get it.
On Saturday, 16 April 2022 at 15:42:22 UTC+1, olcott wrote:
On 4/16/2022 8:59 AM, Malcolm McLean wrote:You should try to write a few Turing machines, however. An "even/odd" decider shouldn't be too tedious to write. It's hard to present youself as an expert on
On Saturday, 16 April 2022 at 14:31:29 UTC+1, B.H. wrote:My big issue with Turing machines is that none of them can move the tape
On Friday, April 15, 2022 at 11:51:24 PM UTC-4, Jeff Barnett wrote:I don't think PO is trolling. He's too persistent for that. And sometimes he
There is absolutely no reason to believe that idiot is dying at anYou think there is no such thing as cancer?
accelerated rate. He is a troll who lies about everything if it will
drag a dialogue partner along. But I do believe that he is dying ofWhat's wrong with that, why is that a rule, and even if it is a rule, why is
laughter at all the nonsense threads he can generate and support. It
it so irritating to you? You would likely be able to generate more threads >>>> if you didn't look like a cantakerous jerk, although maybe you would prefer
to do it your way. Your way of acting and presenting yourself, regardless >>>> of what you think inwardly in your mind and don't say, isn't up to me, it is
your choice.
sure doesn't mean his brain is actually working; it probably isn't and >>>>> he is auto deluded or it is and he is an utter fool.His brain sounds fine to me.
makes errors that that make him look foolish, such as saying that a Turing >>> machine needs 1000 states to move the head 1000 steps. That goes against >>> trollish psychology.
head more than one position at a time. This makes them intolerably
tedious for expressing any significant algorithm.
Turing machines if you've never constructed one.
Even a UTM, though not a trivial machine, isn't all that complicated. Penrose writes one out in his book "The Emperor's New Mind". I think it occupies about half a page, though expressed very compactly in a binary notation.
But you should write a few simpler machines before considering UTMs, much less a modified UTM.
On Friday, 22 April 2022 at 02:33:17 UTC+1, olcott wrote:
On 4/21/2022 8:23 PM, Ben wrote:In x86 assembly, it is indeed not too difficult to arrange that P(P) has
olcott <No...@NoWhere.com> writes:If the correctly simulated input to H(P,P) specifies a non-halting
On 4/21/2022 6:10 PM, Ben wrote:
Still, I expect there's a few years more chatting to be done before you >>>>> get to an editor's day.People here have gotten the conventional halting problem dogma so
ingrained in their psyche that they believe that even when it is
proven to be a verified fact that the input to H(P,P) specifies a
non-halting sequence of configurations it is somehow incorrect for H
to report this.
H(P,P) == false is wrong because P(P) halts. The problem of exhibiting
an H such that H(X,Y) == false if, and only if, X(Y) does not halt has
not gone away. It's called the halting problem. There are famous
theorems about it. At one time you were interested in addressing it.
sequence of configurations on the basis of its actual behavior then this
actual behavior supersedes and overrules anything any everything else
that disagrees.
You keep maintaining the false assumption that the simulated input to
H(P,P) must be computationally equivalent to the direct execution of
P(P). It is easy to see that they specify a semantically different
sequence of configurations.
With H(P,P) H is called before P(P) is simulated.
With P(P) P is called before H(P,P) is invoked.
one behaviour when called directly, and another when simulated.
However that doesn't seem to be your problem. If it was, then P(P)
and H(P,P) would be consistent, and it would look, superficially, as though you had found a counter-example to Linz's proof. In reality, of course,
some global flag would be buried away in the x86 code, maybe very
cleverly disguised.
P(P) halts, H(P,P) reports "non-halting". So everyone says "what is there to see, clearly H get P(P) wrong, which is exactly what Linz said must happen?". The answer is the execution trace. When you look at that, it does indeed
look as though the program might go on forever, and H is right to describe it as "non-halting".
However the execution trace misses the call to H.
Now plenty of people,
without ever seeing the source for H, have diagnosed what the problem
must be. Somewhere in the call to H, there is a test which breaks the
series of nested simulations.
They're almost certainly right.
It is necessary to examine H to be absolutely
sure. You say that's too much code to reasonably expect anyone to analyse,
and you might well be right on that. So where you go is up to you. I urge to to learn how to write Turing machines. If you are interested in Turing machines,
it's an essential skill.
olcott <NoOne@NoWhere.com> writes:
This is clearer:
With H(P,P) H is invoked before P(P) is simulated.
With P(P) P is invoked before H(P,P) is invoked.
Because H and P are invoked in a different order this changes their
behavior.
Everyone has been quite sure that this is the trick you have been trying
to pull ever since you flatly denied it to Mike Terry more than three
years ago. What's puzzling is why you don't use this trick to have H
return the correct answer!
On 2022-04-22 14:58, olcott wrote:
On 4/22/2022 3:42 PM, André G. Isaak wrote:
On 2022-04-22 14:09, olcott wrote:
On 4/22/2022 2:37 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/21/2022 8:23 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/21/2022 6:10 PM, Ben wrote:
Still, I expect there's a few years more chatting to be done >>>>>>>>> before youPeople here have gotten the conventional halting problem dogma so >>>>>>>> ingrained in their psyche that they believe that even when it is >>>>>>>> proven to be a verified fact that the input to H(P,P) specifies a >>>>>>>> non-halting sequence of configurations it is somehow incorrect >>>>>>>> for H
get to an editor's day.
to report this.
H(P,P) == false is wrong because P(P) halts. The problem of
exhibiting
an H such that H(X,Y) == false if, and only if, X(Y) does not
halt has
not gone away. It's called the halting problem. There are famous >>>>>>> theorems about it. At one time you were interested in addressing >>>>>>> it.
If the correctly simulated input to H(P,P) specifies a non-halting >>>>>> sequence of configurations on the basis of its actual behavior then >>>>>> this actual behavior supersedes and overrules anything any everything >>>>>> else that disagrees.
The halting problem is about H(P,P) being right about P(P), not about >>>>> anything else you might find to waffle about.
The halting problem *is not* about P(P) when P(P) is not
computationally equivalent to the correct simulation of the input to
H(P,P).
This is simply an ignorant statement. Rather, it was initially an
ignorant statement but since there have been many attempts made to
remedy your ignorance, it has since graduated to a
willfully-ignorant-grasping-at-straws-statement.
A halt decider is a Turing Machine which computes the halting
*function*.
The halting function is a mathematical function. it is not defined in
terms of 'inputs' or 'simulators'. It is not defined in terms of halt
deciders at all since a function is logically prior to any algorithm
for computing that function.
The halting *function* is simply a mathematical mapping from
computations to {yes, no} based on whether they halt.
No. A decider computes the mapping from (finite string) inputs to an
accept or reject state.
I was defining the halting *function*. That is an entirely different
animal from a halt *decider*. Do you still not grasp the distinction
between a Turing Machine and the function which it computes?
On 2022-04-22 20:54, olcott wrote:
On 4/22/2022 4:42 PM, André G. Isaak wrote:
On 2022-04-22 14:58, olcott wrote:
On 4/22/2022 3:42 PM, André G. Isaak wrote:
On 2022-04-22 14:09, olcott wrote:
On 4/22/2022 2:37 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/21/2022 8:23 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/21/2022 6:10 PM, Ben wrote:
Still, I expect there's a few years more chatting to be done >>>>>>>>>>> before youPeople here have gotten the conventional halting problem dogma so >>>>>>>>>> ingrained in their psyche that they believe that even when it is >>>>>>>>>> proven to be a verified fact that the input to H(P,P) specifies a >>>>>>>>>> non-halting sequence of configurations it is somehow incorrect >>>>>>>>>> for H
get to an editor's day.
to report this.
H(P,P) == false is wrong because P(P) halts. The problem of >>>>>>>>> exhibiting
an H such that H(X,Y) == false if, and only if, X(Y) does not >>>>>>>>> halt has
not gone away. It's called the halting problem. There are famous >>>>>>>>> theorems about it. At one time you were interested in
addressing it.
If the correctly simulated input to H(P,P) specifies a non-halting >>>>>>>> sequence of configurations on the basis of its actual behavior then >>>>>>>> this actual behavior supersedes and overrules anything any
everything
else that disagrees.
The halting problem is about H(P,P) being right about P(P), not
about
anything else you might find to waffle about.
The halting problem *is not* about P(P) when P(P) is not
computationally equivalent to the correct simulation of the input
to H(P,P).
This is simply an ignorant statement. Rather, it was initially an
ignorant statement but since there have been many attempts made to
remedy your ignorance, it has since graduated to a
willfully-ignorant-grasping-at-straws-statement.
A halt decider is a Turing Machine which computes the halting
*function*.
The halting function is a mathematical function. it is not defined
in terms of 'inputs' or 'simulators'. It is not defined in terms of
halt deciders at all since a function is logically prior to any
algorithm for computing that function.
The halting *function* is simply a mathematical mapping from
computations to {yes, no} based on whether they halt.
No. A decider computes the mapping from (finite string) inputs to an
accept or reject state.
I was defining the halting *function*. That is an entirely different
animal from a halt *decider*. Do you still not grasp the distinction
between a Turing Machine and the function which it computes?
So the halt decider computes the halting *function* on some other
basis than what its input actually specifies (What is it a mind reader?)
You really don't think these things through do you?
The halting *function* is defined entirely independently of any halt
decider or computer program. It maps computations to yes or no based on whether they halt.
Whether it is possible to design a Turing Machine or program which
actually computes this function, or whether it is possible to encode
elements of the domain of the halting function in a way which allows
them to even be passed as inputs to such a Turing Machine or program are entirely separate questions.
André
olcott <NoOne@NoWhere.com> writes:
On 4/22/2022 7:00 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/22/2022 1:49 PM, Ben wrote:Let's imagine we are in PO land... We've finally understood the mistake >>> that everyone else has been making -- it's not about what P(P) does but
olcott <NoOne@NoWhere.com> writes:
It does not matter at all that P(P) halts when we have proven that the >>>>>> input to H(P,P) specifies a non-halting sequence of configurations. >>>>> The halting problem -- a function D such that D(X,Y) returns true iff >>>>> X(Y) halts and false otherwise -- does not go away just because youdecide to address some other question, even if it sounds superficially a >>>>> bit similar.
This is merely a very persistent {learned by rote from the book}
misunderstanding of the actual halting problem definition.
about the actual behavior of the actual input: H(P,P)
int X = sum(3,4); must produce 7 or it is wrong.
No, the answer must be 12. No, sorry, it should be g, surely? Perhaps
you should specify this "addition problem" properly?
that <mindless monotone>the input to H(P,P) specifies non-halting
behaviour</mindless monotone>. We publish. No one cares. We are
surprised; people /still/ want to know if a function call halts or not.
They /still/ want a function D such that D(X,Y) returns true iff X(Y)
halts and false otherwise and our telling them that what matters is that >>> <mindless monotone>the input to H(P,P) specifies non-halting
behaviour</mindless monotone> seems to leave them cold.
Strange, I know, but they seem to want to now of their programs halt,
not if <mindless monotone>the input to H specifies non-halting
behaviour</mindless monotone>. There's no accounting for taste.
No comment on the substantive point, as usual: the problem you are now ignoring -- the halting problem -- does not go away. It's still there,
even in PO land.
Richard Damon <Richard@Damon-Family.org> writes:
On 4/23/22 8:57 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
The following simplifies the syntax for the definition of the LinzOh, no! I thought you'd given up on TMs (you really should).
Turing machine Ĥ.
There is no need for the infinite loop after H.qy because it is never"No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
reached.
times."
What that a mistake? A lie? Poetic license?
The halting criteria has been adapted so that it applies to aNo, you can't alter the "halting criteria". The problem you claim to be >>> addressing is about halting, the criterion for which is not for you to
simulating halt decider (SHD).
alter.
So, from here on, you are not talking about a halt decider as it should
be specified... OK.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
own final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
You are free to use your made-up "altered" halting criterion, but I
would urge you not to use junk notation like ⟨Ĥ.qy⟩. The ⟨⟩s go round
TMs to indicate a string encoding, but Ĥ.qy is a state. But since this >>> is not about a halt decider as specified by the textbooks, it's probably >>> not worth trying to find out what thoughts this poetic use of notation
is meant to conjure up in the reader's mind.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
There is no machine H0 or H1 so there can be no strings ⟨Ĥ0⟩ or ⟨Ĥ1⟩. I
know you are writing a poem here, so I can guess what you want the
reader to think of, but in technical writing one should use notation
constantly and clearly.
I will defined him a bit here, while he isn't being very clear about
his notation (which is normal for him) I think the trailing numbers
are supposed to be "indexes" indicating which of a number of identical
strings we are refering to. In a more expressive notation they would
be subscripts.
Well that's why I wrote that the reader can guess. But the problem goes
much deeper than writing <Ĥ0> rather than <Ĥ>_0. The <> notation is supposed to indicate actual strings on the tape,
but when H is
simulating, and when that simulation is simulating these strings won't
appear anywhere. They simply don't exist on the tape. If PO had
written a UTM, he'd know this.
On 4/26/2022 7:45 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/26/2022 6:50 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/25/2022 8:30 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/25/2022 4:42 PM, Ben wrote:No. Read carefully:
olcott <NoOne@NoWhere.com> writes:
On 4/23/2022 8:43 PM, Ben wrote:No. Ĥ copies its input from the tape to the tape. There's no >>>>>>>> dispute
Richard Damon <Richard@Damon-Family.org> writes:
On 4/23/22 8:57 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
The following simplifies the syntax for the definition of >>>>>>>>>>>>> the LinzOh, no! I thought you'd given up on TMs (you really should). >>>>>>>>>>>>
Turing machine Ĥ.
There is no need for the infinite loop after H.qy because >>>>>>>>>>>>> it is never"No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have
reached.
told you many
times."
What that a mistake? A lie? Poetic license?
The halting criteria has been adapted so that it applies to a >>>>>>>>>>>>> simulating halt decider (SHD).No, you can't alter the "halting criteria". The problem you >>>>>>>>>>>> claim to be
addressing is about halting, the criterion for which is not >>>>>>>>>>>> for you to
alter.
So, from here on, you are not talking about a halt decider >>>>>>>>>>>> as it should
be specified... OK.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach
its own
final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never
reach its
own final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
You are free to use your made-up "altered" halting
criterion, but I
would urge you not to use junk notation like ⟨Ĥ.qy⟩. The >>>>>>>>>>>> ⟨⟩s go round
TMs to indicate a string encoding, but Ĥ.qy is a state. But >>>>>>>>>>>> since this
is not about a halt decider as specified by the textbooks, >>>>>>>>>>>> it's probably
not worth trying to find out what thoughts this poetic use >>>>>>>>>>>> of notation
is meant to conjure up in the reader's mind.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
There is no machine H0 or H1 so there can be no strings ⟨Ĥ0⟩ >>>>>>>>>>>> or ⟨Ĥ1⟩. I
know you are writing a poem here, so I can guess what you >>>>>>>>>>>> want the
reader to think of, but in technical writing one should use >>>>>>>>>>>> notation
constantly and clearly.
I will defined him a bit here, while he isn't being very >>>>>>>>>>> clear about
his notation (which is normal for him) I think the trailing >>>>>>>>>>> numbers
are supposed to be "indexes" indicating which of a number of >>>>>>>>>>> identical
strings we are refering to. In a more expressive notation >>>>>>>>>>> they would
be subscripts.
Well that's why I wrote that the reader can guess. But the >>>>>>>>>> problem goes
much deeper than writing <Ĥ0> rather than <Ĥ>_0. The <> >>>>>>>>>> notation is
supposed to indicate actual strings on the tape,
but when H is
simulating, and when that simulation is simulating these
strings won't
appear anywhere. They simply don't exist on the tape. If PO had >>>>>>>>>> written a UTM, he'd know this.
So when Ĥ copies its input this copied input goes no where?
about that. It's clear as day in every textbook.
You said that it exists NO WHERE !
On 4/23/2022 8:43 PM, Ben wrote:
but when H is simulating, and when that simulation is simulating
these strings won't appear anywhere.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
As soon as the simulated Ĥ copies its input once there are three
copies of this input on the master UTM tape.
I await your E and specification for P and I will then try to explain
why you are wrong about this.
I can't possibly be wrong about this.
Do I take it you won't be holding up your end of the deal then?
I just got out of the hospital. I was there since Tuesday. When you tell
me that you are sure that some black cats are white it is easy to see
that you are incorrect.
I will work through the even/odd example. I am still sick so I will do
it slowly.
olcott <NoOne@NoWhere.com> writes:You have to think it ALL THE WAY THROUGH.
On 4/28/2022 6:41 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/28/2022 1:14 PM, olcott wrote:OK.
On 4/26/2022 7:45 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/26/2022 6:50 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
I just got out of the hospital. I was there since Tuesday. When youOn 4/23/2022 8:43 PM, Ben wrote:
but when H is simulating, and when that simulation is simulating >>>>>>>>>> these strings won't appear anywhere.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
They simply don't exist on the tape.
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
THEY DO EXIST ON THE TAPE SO YOU ARE WRONG
As soon as the simulated Ĥ copies its input once there are three >>>>>>>>> copies of this input on the master UTM tape.
I await your E and specification for P and I will then try to explain >>>>>>>> why you are wrong about this.
I can't possibly be wrong about this.
Do I take it you won't be holding up your end of the deal then?
tell me that you are sure that some black cats are white it is easy
to see that you are incorrect.
I will work through the even/odd example. I am still sick so I will do >>>>> it slowly.
There is no possible way for a computable function to not be a pureA computable function is a mathematical function. The term pure is
function of its arguments because this is a defined to be the meaning
of the term: "computable function".
never applied to mathematical functions since that are all pure.
https://en.wikipedia.org/wiki/Computable_functionThe input is a single string. Always. (Funny that you switch to using
When functions are computed by TM's the "arguments" are a set of
finite strings, that is all that they have to deal with.
the term argument when it's usually called an input, but when it's
usually called an argument you use the term input!)
OK so a halt decider computes the mapping from a TM description and
must ignore its input of this TMD because it cannot deal with more
than one string?
No. Years ago I tried to explain that you need an encoding for a pair
of string, but you never took that on board. I always wrote <[M],I> as
the single string input where [M] is the encoding of TM M and <x,y> is
the encoding of the pair of strings x and y. Both [M] and <x,y> are
just notations for some agreed encoding. Maybe we agree that if x="abc"
and y="010" then <x,y> is the string "abc//010".
Eventually, belatedly, you accepted that you need a notation from a TM's encoding and you chose <M> from, I think, Sipser, but you never agreed
to use a pair notation.
These computationsNever in doubt.
cannot possibly go on any other basis than what these finite strings
specify.
It is very very nutty that Ben, Richard and Andre to all believe thatWe don't. You don't understand (or pretend not to understand) what's
it can have any other basis.
being said.
If I ask you the question: "What time is it?" and by that question I
mean the question: "Where is the nearest Walmart?" as long as you
provided the current time then you are correct.
The question being asked of your H is "does the function pointed to by
the first argument halt when called with the second pointer as it's
argument?". H has access to the full address space of the machine (at
least it does in your x86 model) so there's nothing hidden from H. Your >>> H returns false for H(P,P) which is incorrect because P(P) halts.
Do you not comprehend the idea of computational equivalence, or do you
simply "not believe" that P(P) and the correctly simulated input to
H(P,P) could lack computational equivalence?
I know what the definition of the halting problem is. It's as above.
Your H does not meet the spec.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 102:07:29 |
| Calls: | 6,660 |
| Calls today: | 2 |
| Files: | 12,209 |
| Messages: | 5,334,982 |