On 8/29/21 12:00 AM, olcott wrote:
On 8/28/2021 7:07 PM, Richard Damon wrote:
On 8/28/21 7:51 PM, olcott wrote:
I will take this to mean that you already know that
That P(P) of main() halts does not contradict H(P,P)==0.
The only way that I can know that my words are clear enough to escalate >>>> to the next level of actual computer scientist review when I mostly only >>>> have God damned liars for reviewers is that their "rebuttals" become
ridiculously lame.
WRONG.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
H0((u32)Infinite_Loop);
Infinite_Loop();
}
It is dead obvious that the first line of main() has different behavior
than the second line of main() even though the same function with the
same empty arguments is simulated / executed in both cases.
From this we can deduce that every input that never halts will have
different behavior when simulated by a simulating halt decider that
recognizes its infinite behavior pattern than it would when directly
executed.
I am going to stop here to see if this much is understood.
And who ever said that the computation of H(P,I) was the same as the computation P(I). Only you seem to argue that strawmand.
The point everyone is making is that the answer that H(P,I) needs to correspond to the actual behavor of P(I).
If P(I) Halts, then H(P,I) needs to return 1.
If P(I) doesn't ever Halt, then H(P,I) needs to return 0.
Since Infinite_Loop() never Hals, H(Infinite_Loop, 0) should return 0.
Since H^(H^) DOES Halt, H(H^,H^) must return 1 to be right, but it
returns 0.
Note, a PARTIAL simulation may be finite when the machine is being
simulated is infinite, because a partial simulation (like used by a
smulating halt decider) doesn't fully repoduce the machine like a PURE simulation needs to.
But, this does NOT mean that every simulation that a simulating halt
decider aborts would be infinite if not aborted. The fact that this
simulator aborted the simulation doesn't affact what the machine would
do if run by itself.
I think the one key thing you keep on missing is when you start to argue about the H^ machine is that when you look at varying the definition of
H, to see what answer is right, you need to decide what problem you are
going to be looking at. If you want to see if the answer H gave was
right for a given H/H^ pair, than when you change H, you must not change
the version of H that H^ is using. Thus we can replace the top level H
with a UTM, but leave the H in H^ to still have its abort in it, to see
that this H^ does Halt. (Which it does as long as H(H^,H^) returns 0)
When you want to try to see if you can find an H that gives the right
answer, then you do need to change the H that is inside H^, and you then
need to compare the results of H(H^,H^) to what H^(H^) does.
You will find two major cases for H. There are H's that don't abort the simulation of H^, these Hn, fail to decide on Hn(Hn^,Hn^) so are wrong,
and it doesn't matter that Hn^(Hn^) doesn't halt.
The second case are Ha's that do abort the simulation of Ha^ and say it
is non-halting. For all of these Ha's, we find that Ha^(H^) will be
halting, and thus Ha was wrong.
You keep on trying to do logic where you look at Hn(Ha^,Ha^) or
Ha(Hn^,Hn^) and in both of these cases, the H can give the right answer,
but the problem isn't in the right form to be a counter. You need to get
the decider to decide correctly on the ^ construction of itself, not
some other version of the decider.
On 2021-08-30 21:20, olcott wrote:
On 8/30/2021 10:04 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 8/30/2021 9:17 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 8/29/2021 7:00 PM, Ben Bacarisse wrote:Dodge, dodge, dodge! All the questions you have been asked pertain >>>>> directly to the nonsense you post.
olcott <NoOne@NoWhere.com> writes:
On 8/29/2021 11:19 AM, Ben Bacarisse wrote:No answer, as expected.
olcott <NoOne@NoWhere.com> writes:
On 8/29/2021 10:20 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
The fact that the P(P) of main() halts does not contradict >>>>>>>>>>>> the fact
that H(P,P) of main() correctly decides that its input never >>>>>>>>>>>> halts
because these are two entirely different computations.
What arguments must be passed to H for it to report on the >>>>>>>>>>> halting
computation P(P) "of main()"?
That is already answered in the part that you snipped.
No it was not. And if I am wrong, show the world that I am >>>>>>>>> wrong by
writing them again here. It can be no more that two simple C >>>>>>>>> expressions.
It is as I have said an airtight proof, notwithstanding false
assumptions to the contrary.
You can try to point to an actual error in the proof as itsNo answer, as expected.
stands and
everyone that sufficiently understands the material will see your >>>>>>>> mistake.
It is the case that H(P,P) is a computation that never halts unless >>>>>>>> its simulation is aborted. It is the case that every computation >>>>>>>> thatNo answer, as expected.
never halts unless is simulation is aborted is a non halting
computation.
There is nothing besides carefully crafted double-talk that goes >>>>>>>> against this.No answer, as expected.
I will only answer questions that directly pertain to the points that >>>>>> I made and will ignore dishonest dodges that attempt to change the >>>>>> subject away from the points that I made.
I am only discussing that
H(P,P)==0 is correct is a necessary consequence of its two premises.
You seem to forget that I agree. H(P,P)==0 is correct given the
criteria you have invented.
{H(P,P)==0 is correct} means that the input to H(P,P) is correctly
decided as never halting.
H(P, P) is required to answer the question Does P(P) halt"
It is *specifically* being asked about the behaviour of int main() {
P(P); }
It is *not* being asked about the behaviour of P(P) "under the dominion
of a halt decider" (whatever that may mean) nor about any computation
other than int main() { P(P); }. This follows directly from how the
halting problem is *defined*.
since int main() { P(P); } halts, if your H(P, P) returns any answer
other than 'true', it is wrong by the very definition of the problem.
You can argue all you want that it is right about some *other* question,
or about some computation *other* than int main() { P(P); }, but then it isn't answering the halting problem. It is answering something else, and unless you can provide some reason why anyone should care about that
other problem I assure you no one will.
André
On 2021-08-30 22:31, olcott wrote:In computability theory, the halting problem is the
On 8/30/2021 11:19 PM, André G. Isaak wrote:
On 2021-08-30 22:00, olcott wrote:
On 8/30/2021 10:35 PM, André G. Isaak wrote:
On 2021-08-30 21:20, olcott wrote:
On 8/30/2021 10:04 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 8/30/2021 9:17 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 8/29/2021 7:00 PM, Ben Bacarisse wrote:Dodge, dodge, dodge! All the questions you have been asked >>>>>>>>> pertain
olcott <NoOne@NoWhere.com> writes:
On 8/29/2021 11:19 AM, Ben Bacarisse wrote:No answer, as expected.
olcott <NoOne@NoWhere.com> writes:
On 8/29/2021 10:20 AM, Ben Bacarisse wrote:No it was not. And if I am wrong, show the world that I am >>>>>>>>>>>>> wrong by
olcott <NoOne@NoWhere.com> writes:
The fact that the P(P) of main() halts does not >>>>>>>>>>>>>>>> contradict the factWhat arguments must be passed to H for it to report on >>>>>>>>>>>>>>> the halting
that H(P,P) of main() correctly decides that its input >>>>>>>>>>>>>>>> never halts
because these are two entirely different computations. >>>>>>>>>>>>>>>
computation P(P) "of main()"?
That is already answered in the part that you snipped. >>>>>>>>>>>>>
writing them again here. It can be no more that two simple C >>>>>>>>>>>>> expressions.
It is as I have said an airtight proof, notwithstanding false >>>>>>>>>>>> assumptions to the contrary.
You can try to point to an actual error in the proof as its >>>>>>>>>>>> stands andNo answer, as expected.
everyone that sufficiently understands the material will see >>>>>>>>>>>> your
mistake.
It is the case that H(P,P) is a computation that never halts >>>>>>>>>>>> unlessNo answer, as expected.
its simulation is aborted. It is the case that every
computation that
never halts unless is simulation is aborted is a non halting >>>>>>>>>>>> computation.
There is nothing besides carefully crafted double-talk that >>>>>>>>>>>> goesNo answer, as expected.
against this.
I will only answer questions that directly pertain to the
points that
I made and will ignore dishonest dodges that attempt to change >>>>>>>>>> the
subject away from the points that I made.
directly to the nonsense you post.
I am only discussing that
H(P,P)==0 is correct is a necessary consequence of its two
premises.
You seem to forget that I agree. H(P,P)==0 is correct given the >>>>>>> criteria you have invented.
{H(P,P)==0 is correct} means that the input to H(P,P) is correctly >>>>>> decided as never halting.
H(P, P) is required to answer the question Does P(P) halt"
It is *specifically* being asked about the behaviour of int main()
{ P(P); }
It is *not* being asked about the behaviour of P(P) "under the
dominion of a halt decider" (whatever that may mean) nor about any
computation other than int main() { P(P); }. This follows directly
from how the halting problem is *defined*.
In computability theory, the halting problem is the
problem of determining, from a description of an
arbitrary computer program and an input, whether the
program will finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
No that is not true. The halting problem is always about program
descriptions not running programs. This means that it is always
about the input to the halt decider not the direct execution of the
program.
The *input* to the decider is a program description. But the question
the halt decider is expected to answer is about the *actual* program
which that description describes.
In other words whether or not the the pure simulation of this
description halts on its input.
No. The question is whether the *actual* computation described by the
input halts.
A pure simulation would have identical halting behaviour as the actual computation, but the question isn't about simulations. It's about actual computations. It isn't about what happens inside some decider; it's
about actual computations.
And since you claim that it has a *different* halting behaviour inside
your halt decider, you aren't dealing with a pure simulation but
something else. The correct answer to the question does P(P) halt is determined by the *actual* computation and *nothing* else.
If the input to the halt decider never halts unless the halt decider
aborts its simulation of this input then its input never halts.
If P(P) halts, but the "simulation of P(P)" does not, then either
your simulator is broken or whatever is being simulated by the
decider *isn't* the the program which which was actually described by
its input. It is therefore answering about the *wrong* program.
André
Like I said H(P,P)==0 is correct as a logical consequence of its two
premises and its two premises are true. There is no escape from this.
You still haven't given your two premises.
But it is entirely irrelevant anyways. As I said, the correct answer to
the question does P(P) halt is determined by the *actual* computation
and nothing else.
It is not possible to prove that H(P,P)==0 given that this doesn't match
the behaviour of the actual computation.
If you want to claim that it is the correct answer to the question 'does
P(P) 'under the dominion' of a simulating halt decider halt?' you can do
that to your heart's content.
But that *isn't* the question which the halting problem asks, nor is it
a question that anyone gives a damn about. It's basically just nonsense.
André
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 366 |
Nodes: | 16 (2 / 14) |
Uptime: | 04:08:04 |
Calls: | 7,812 |
Files: | 12,924 |
Messages: | 5,749,468 |