olcott <NoOne@NoWhere.com> writes:
On 11/2/2021 8:19 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 11/1/2021 5:38 PM, Ben Bacarisse wrote:H(P,P) == false is wrong if P(P) halts.
olcott <NoOne@NoWhere.com> writes:
To which you replied (but have for some reason cut from this post)|| Here's the key question: do you still assert that H(P,P) == false is >>>>>>> || the "correct" answer even though P(P) halts?
H(P,P) should report on whether P(P) halts. Stating that the wrong| Yes that is the correct answer even though P(P) halts.
H(P,P) reports that its input never halts.
answer is the right one is not how mathematics is done.
H1(P,P) is computationally equivalent to P(P).
H(P,P) is not computationally equivalent to P(P).
The input to H(P,P) really does never halt this has been conclusively
proven.
P(P) halts. H(P,P) == false is the wrong answer if P(P) halts.
That you keep ignoring the verified fact that the input to H(P,P) has
been totally proven to never reaches its final state sure seems to be
an irrational break from reality to me.
You want me to get sucked into discussing your other errors, but really
only one counts: H(P,P) == false is the wrong answer if P(P) halts.
On 11/2/2021 3:04 PM, André G. Isaak wrote:
On 2021-11-02 11:32, olcott wrote:
On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
As long as H(P,P)==0 is correct none of my other "errors" are of any >>>>>>> consequence what-so-ever.
That's why I said one error really count: H(P,P)==0 is not correct >>>>>> because P(P) halts. How is it that you can keep ignoring this?
It is a verified fact that for every possible (abort / do not abort) >>>>> behavior of every possible encoding of simulating halt decider H that >>>>> the input to H(P,P) never reaches its final state.
H(P,P)==0 is wrong because P(P) halts. You keep trying to explain some >>>> other decision problem that you think H is getting right. For the
halting problem -- the one you've been "studying" for more than 14
years
-- H(P,P)==0 is only correct if P(P) does not halt and you've told us
that is does.
It is like I am telling there are no integers between 1 and 2 and you >>>>> just don't believe it.
No, its like you are tell me that H(P,P)==false is the right answer
from
a halt decider when P(P) is a halting computation. In fact it's very >>>> much like that. Almost exactly like that in fact.
It seems to be intuitively true that H(P,P) should report that its
input halts because P(P) halts.
No. I have no intuition about what you even mean because inputs don't >>>> do anything. What is true by definition (no intuition required) is
that
H(P,P) should be false only if P(P) does not halt.
This intuition
I don't have that intuition. What "the input" does is meaningless.
Every halt decider is ONLY tasked with determining the behavior of
its input. That you say otherwise is very stupid.
Why don't you go back and reread definition of Halt Decider given in
12.1 in Linz.
Let w_M be a string that describes a Turing machine M, and let w be a
string in M’s alphabet. A solution of the halting problem is a Turing
machine H, which for any w_M and w performs the computation:
q_0 w_M w ⊢* x_1 q_y x_2 if M applied to w halts, and
q_0 w_M w ⊢* x_1 q_n x_2 if M applied to w does not halt
The input to this machine is w_M plus the input string w. The
conditions specified to the two final states make no mention
whatsoever of w_M. They talk about *M* applied to w.
By saying it that way people can be confused (the same way that Linz
himself was confused) into believing that the question is about whether
or not the halt decider itself at Ĥ.qx halts.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The behavior of the input to the halt decider after Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ has nothing to do with whether or not the halt decider itself halts.
On 2021-11-02 14:24, olcott wrote:
On 11/2/2021 3:04 PM, André G. Isaak wrote:
On 2021-11-02 11:32, olcott wrote:
On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
As long as H(P,P)==0 is correct none of my other "errors" are of >>>>>>>> any
consequence what-so-ever.
That's why I said one error really count: H(P,P)==0 is not correct >>>>>>> because P(P) halts. How is it that you can keep ignoring this?
It is a verified fact that for every possible (abort / do not abort) >>>>>> behavior of every possible encoding of simulating halt decider H that >>>>>> the input to H(P,P) never reaches its final state.
H(P,P)==0 is wrong because P(P) halts. You keep trying to explain
some
other decision problem that you think H is getting right. For the
halting problem -- the one you've been "studying" for more than 14
years
-- H(P,P)==0 is only correct if P(P) does not halt and you've told us >>>>> that is does.
It is like I am telling there are no integers between 1 and 2 and you >>>>>> just don't believe it.
No, its like you are tell me that H(P,P)==false is the right answer
from
a halt decider when P(P) is a halting computation. In fact it's very >>>>> much like that. Almost exactly like that in fact.
It seems to be intuitively true that H(P,P) should report that its >>>>>> input halts because P(P) halts.
No. I have no intuition about what you even mean because inputs don't >>>>> do anything. What is true by definition (no intuition required) is >>>>> that
H(P,P) should be false only if P(P) does not halt.
This intuition
I don't have that intuition. What "the input" does is meaningless.
Every halt decider is ONLY tasked with determining the behavior of
its input. That you say otherwise is very stupid.
Why don't you go back and reread definition of Halt Decider given in
12.1 in Linz.
Let w_M be a string that describes a Turing machine M, and let w be a
string in M’s alphabet. A solution of the halting problem is a Turing
machine H, which for any w_M and w performs the computation:
q_0 w_M w ⊢* x_1 q_y x_2 if M applied to w halts, and
q_0 w_M w ⊢* x_1 q_n x_2 if M applied to w does not halt
The input to this machine is w_M plus the input string w. The
conditions specified to the two final states make no mention
whatsoever of w_M. They talk about *M* applied to w.
By saying it that way people can be confused (the same way that Linz
Saying it that way is how halt decider is *defined*. Not just by Linz,
but by *everyone* who has ever discussed this problem.
If you want to discuss the halting problem, this is the definition you
must use.
On 2021-11-02 11:32, olcott wrote:
On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
As long as H(P,P)==0 is correct none of my other "errors" are of any >>>>>> consequence what-so-ever.
That's why I said one error really count: H(P,P)==0 is not correct
because P(P) halts. How is it that you can keep ignoring this?
It is a verified fact that for every possible (abort / do not abort)
behavior of every possible encoding of simulating halt decider H that
the input to H(P,P) never reaches its final state.
H(P,P)==0 is wrong because P(P) halts. You keep trying to explain some >>> other decision problem that you think H is getting right. For the
halting problem -- the one you've been "studying" for more than 14 years >>> -- H(P,P)==0 is only correct if P(P) does not halt and you've told us
that is does.
It is like I am telling there are no integers between 1 and 2 and you
just don't believe it.
No, its like you are tell me that H(P,P)==false is the right answer from >>> a halt decider when P(P) is a halting computation. In fact it's very
much like that. Almost exactly like that in fact.
It seems to be intuitively true that H(P,P) should report that its
input halts because P(P) halts.
No. I have no intuition about what you even mean because inputs don't
do anything. What is true by definition (no intuition required) is that >>> H(P,P) should be false only if P(P) does not halt.
This intuition
I don't have that intuition. What "the input" does is meaningless.
Every halt decider is ONLY tasked with determining the behavior of its
input. That you say otherwise is very stupid.
Why don't you go back and reread definition of Halt Decider given in
12.1 in Linz.
Let w_M be a string that describes a Turing machine M, and let w be a
string in M’s alphabet. A solution of the halting problem is a Turing machine H, which for any w_M and w performs the computation:
q_0 w_M w ⊢* x_1 q_y x_2 if M applied to w halts, and
q_0 w_M w ⊢* x_1 q_n x_2 if M applied to w does not halt
The input to this machine is w_M plus the input string w. The conditions specified to the two final states make no mention whatsoever of w_M.
They talk about *M* applied to w.
On 2021-11-02 14:43, olcott wrote:
If everyone "defines" that the halt decider is wrong when it correctly
reports what the actual behavior of its actual input would be then
everyone (besides me) is wrong.
The definition tells you what a halt decider *is*. It doesn't define it
as 'wrong'. It defines what question it is supposed to answer.
The input to a halt decider is a string. Strings don't *have* halting behaviour so your position above is entirely incoherent.
The string w_Ĥ w_Ĥ describes the computation where the Turing Machine Ĥ
is applied to the string w_Ĥ. That computation halts. And it is the behaviour of that computation that a halting decider must report when
given w_Ĥ w_Ĥ as an input BECAUSE THAT'S WHAT A HALT DECIDER IS DEFINED
TO DO.
Your claim that the "input" doesn't halt even though the actual machine
does simply illustrates that you are clueless about what the actual
halting problem is.
André
On 2021-11-02 15:41, olcott wrote:
On 11/2/2021 4:05 PM, André G. Isaak wrote:
On 2021-11-02 14:43, olcott wrote:
If everyone "defines" that the halt decider is wrong when it
correctly reports what the actual behavior of its actual input would
be then everyone (besides me) is wrong.
The definition tells you what a halt decider *is*. It doesn't define
it as 'wrong'. It defines what question it is supposed to answer.
The input to a halt decider is a string. Strings don't *have* halting
behaviour so your position above is entirely incoherent.
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
The definition of 'halting problem' is what it is.
Note that the above definition doesn't make any mentions of
'simulations' just as the more formal definition used by Linz's does not.
A halt decider only need answer whether or not the correct simulation
of its input would ever reach a final state of this input by a
simulating halt decider.
A 'correct simulation', presumably, would be one that acts identically
to the actual TM being simulated. That means that if the actual TM halts
the simulation also must halt. Which means that your simulation is not a 'correct simulation'.
If a simulation can have a different behaviour then the actual program,
then that simulation can't be used to answer the question which a halt decider is supposed to answer.
You really ought to consider a different line of 'work'. Have you
thought of maybe inventing a perpetual motion machine or of squaring the circle? Maybe you'd have more luck with those.
André
On 2021-11-02 18:49, olcott wrote:
On 11/2/2021 6:31 PM, André G. Isaak wrote:
On 2021-11-02 16:51, olcott wrote:
On 11/2/2021 4:49 PM, André G. Isaak wrote:
On 2021-11-02 15:41, olcott wrote:
On 11/2/2021 4:05 PM, André G. Isaak wrote:
On 2021-11-02 14:43, olcott wrote:
If everyone "defines" that the halt decider is wrong when it
correctly reports what the actual behavior of its actual input >>>>>>>> would be then everyone (besides me) is wrong.
The definition tells you what a halt decider *is*. It doesn't
define it as 'wrong'. It defines what question it is supposed to >>>>>>> answer.
The input to a halt decider is a string. Strings don't *have*
halting behaviour so your position above is entirely incoherent. >>>>>>>
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
The definition of 'halting problem' is what it is.
Note that the above definition doesn't make any mentions of
'simulations' just as the more formal definition used by Linz's
does not.
A halt decider only need answer whether or not the correct
simulation of its input would ever reach a final state of this
input by a simulating halt decider.
A 'correct simulation', presumably, would be one that acts
identically to the actual TM being simulated. That means that if
the actual TM halts the simulation also must halt. Which means that
your simulation is not a 'correct simulation'.
There are no freaking presumptions about it. As long as the
simulation of P(P) matches its x86 source code then the simulation
is correct.
I have no idea what it means for a simulation of P(P) to "match its
x86 source code".
When the simulator executes the instructions at
0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
of the x86 source code of P, then the simulator
correctly simulated P(P).
No. A simulator only 'correctly simulates' a machine when it accurately duplicates *all* of the behaviour of that machine. Part of the behaviour
of P(P) is that it halts.
_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]
A correct simulation of P on input P can be empirically validated by
the simulation of the first seven x86 instruction of P.
Begin Local Halt Decider Simulation at Machine Address:c36
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call
H(P,P)
Because the simulation of P(P) matches its x86 source-code it is
necessarily correct and impossibly incorrect.
The only possibility for every encoding of simulating halt decider H
is:
(a) H fails to abort its simulation (and thus fails to be a decider)
and the first seven instructions of P infinitely repeat in which
case P never reaches its final state of 0xc50.
(b) H aborts its simulation of P at some address of P between 0xc36
and 0xc41 in which case the input P fails to every reach its final
state of 0xc50.
One the basis of the correct simulation of the x86 source-code of
P(P) we can see that it is utterly impossible for P to ever reach
its final state of 0xc50.
Even if your argument above were sound, it is also *irrelevant* since
the criterion which defines a 'halt decider' makes no mention about
simulations, simulators or aborted simulations.
Because the criteria does say by what-so-ever means, it includes
simulation.
I never claimed otherwise.
If P(P) halts, then the correct answer to the question 'Does P(P)
halt?' is 'yes'. And that's the question *by definition* which a halt
decider must answer.
André
A halt decider only need answer whether or not the correct simulation
of its input would ever reach a final state of this input by a
simulating halt decider.
No. A halt decider needs to answer the question which a halt decider is required to answer.
A halt decider which takes w_M and w as its inputs
must answer the question 'Does M halt on input w?' since that is how a
halt decider is *defined*.
It doesn't matter whether you reach the answer by simulating or not. The question and the answer remain the same. P(P) halts,
so the answer to
'Does P(P) halt?', which is what a halt-decider is defined to answer, is 'yes'.
Any halt-decider which answers otherwise is simply wrong.
André
On 2021-11-02 19:32, olcott wrote:
On 11/2/2021 8:07 PM, André G. Isaak wrote:
On 2021-11-02 18:49, olcott wrote:
On 11/2/2021 6:31 PM, André G. Isaak wrote:
On 2021-11-02 16:51, olcott wrote:
On 11/2/2021 4:49 PM, André G. Isaak wrote:
On 2021-11-02 15:41, olcott wrote:
On 11/2/2021 4:05 PM, André G. Isaak wrote:
On 2021-11-02 14:43, olcott wrote:
If everyone "defines" that the halt decider is wrong when it >>>>>>>>>> correctly reports what the actual behavior of its actual input >>>>>>>>>> would be then everyone (besides me) is wrong.
The definition tells you what a halt decider *is*. It doesn't >>>>>>>>> define it as 'wrong'. It defines what question it is supposed >>>>>>>>> to answer.
The input to a halt decider is a string. Strings don't *have* >>>>>>>>> halting behaviour so your position above is entirely incoherent. >>>>>>>>>
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
The definition of 'halting problem' is what it is.
Note that the above definition doesn't make any mentions of
'simulations' just as the more formal definition used by Linz's
does not.
A halt decider only need answer whether or not the correct
simulation of its input would ever reach a final state of this >>>>>>>> input by a simulating halt decider.
A 'correct simulation', presumably, would be one that acts
identically to the actual TM being simulated. That means that if >>>>>>> the actual TM halts the simulation also must halt. Which means
that your simulation is not a 'correct simulation'.
There are no freaking presumptions about it. As long as the
simulation of P(P) matches its x86 source code then the simulation >>>>>> is correct.
I have no idea what it means for a simulation of P(P) to "match its
x86 source code".
When the simulator executes the instructions at
0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
of the x86 source code of P, then the simulator
correctly simulated P(P).
No. A simulator only 'correctly simulates' a machine when it
accurately duplicates *all* of the behaviour of that machine. Part of
the behaviour of P(P) is that it halts.
That is a stupid thing to say. The x86 emulator correctly emulates the
x86 instructions of P iff it emulates the actual x86 intructions of P
saying anything else is both pure bullshit and quite nutty.
That's a nonsensical claim. If it correctly emulates all the
instructions then it should have identical behaviour. That includes
whether it halts or not.
On 03/11/2021 04:09, Mike Terry wrote:
On 03/11/2021 03:30, André G. Isaak wrote:
On 2021-11-02 21:14, olcott wrote:
On 11/2/2021 9:26 PM, André G. Isaak wrote:
On 2021-11-02 19:32, olcott wrote:
On 11/2/2021 8:07 PM, André G. Isaak wrote:
On 2021-11-02 18:49, olcott wrote:
On 11/2/2021 6:31 PM, André G. Isaak wrote:
On 2021-11-02 16:51, olcott wrote:
On 11/2/2021 4:49 PM, André G. Isaak wrote:
On 2021-11-02 15:41, olcott wrote:
On 11/2/2021 4:05 PM, André G. Isaak wrote:
On 2021-11-02 14:43, olcott wrote:
If everyone "defines" that the halt decider is wrong when >>>>>>>>>>>>>> it correctly reports what the actual behavior of its >>>>>>>>>>>>>> actual input would be then everyone (besides me) is wrong. >>>>>>>>>>>>>The definition tells you what a halt decider *is*. It >>>>>>>>>>>>> doesn't define it as 'wrong'. It defines what question it >>>>>>>>>>>>> is supposed to answer.
The input to a halt decider is a string. Strings don't >>>>>>>>>>>>> *have* halting behaviour so your position above is entirely >>>>>>>>>>>>> incoherent.
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
The definition of 'halting problem' is what it is.
Note that the above definition doesn't make any mentions of >>>>>>>>>>> 'simulations' just as the more formal definition used by >>>>>>>>>>> Linz's does not.
A halt decider only need answer whether or not the correct >>>>>>>>>>>> simulation of its input would ever reach a final state of >>>>>>>>>>>> this input by a simulating halt decider.
A 'correct simulation', presumably, would be one that acts >>>>>>>>>>> identically to the actual TM being simulated. That means that >>>>>>>>>>> if the actual TM halts the simulation also must halt. Which >>>>>>>>>>> means that your simulation is not a 'correct simulation'. >>>>>>>>>>>
There are no freaking presumptions about it. As long as the >>>>>>>>>> simulation of P(P) matches its x86 source code then the
simulation is correct.
I have no idea what it means for a simulation of P(P) to "match >>>>>>>>> its x86 source code".
When the simulator executes the instructions at
0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
of the x86 source code of P, then the simulator
correctly simulated P(P).
No. A simulator only 'correctly simulates' a machine when it
accurately duplicates *all* of the behaviour of that machine.
Part of the behaviour of P(P) is that it halts.
That is a stupid thing to say. The x86 emulator correctly emulates >>>>>> the x86 instructions of P iff it emulates the actual x86
intructions of P saying anything else is both pure bullshit and
quite nutty.
That's a nonsensical claim. If it correctly emulates all the
instructions then it should have identical behaviour. That includes
whether it halts or not.
Maybe you don't understand the x86 language well enough to ever
understand what I am saying.
While H continues to simulate P these first seven instructions of P
continue to repeat. Do you understand that?
Which is irrelevant to the halting problem which asks whether P(P)
halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
'true'. *Nothing* apart from the actual behaviour of P(P) is relevant
to determining what the correct answer to this question is, so
there's not even any point in providing all your meaningless traces.
The correct answer to H(P, P) is determined by the actual behaviour
of P(P). We know the actual behaviour of P(P). So there's absolutely
no reason to consider anything else.
And you conveniently ignored all the questions which I asked.
What does the input to H(P, P) represent if not P(P)?
How can the inputs to H1(P, P) and H(P, P) represent different things
given that they are the *same* input?
My suspicion (difficult to confirm) is still that in both those cases,
PO is looking at the same computation. It's simply that H and H1, in
examining the identical execution traces, behave differently because
they take their own machine code address and use that in interpreting
the instruction trace.
So e.g. H uses its address to exclude certain parts of the trace it
examines, and consequently INCORRECTLY decides it is seeing infinite
recursion. H1 excludes a different address range, so it doesn't see
infinite recursion and so the simulation continues FURTHER than H
continues it, and in fact with H1 the simulation proceeds right up to
the point where it reaches its halt state, so H1 give the correct
answer. [I'd guess H1 works because it is seeing the conditional
branch instructions that H deliberately ignores, and so his unsound
recursion test does not match.]
I bet if we looked at the actual traces that H and H1 are producing,
Correction - what I meant to say here is "actual traces that H and H1
are EXAMINING".
Obviously the traces of H(P,P) and H1(P,P) [including the traces of the
outer emulations of H, H1 themselves] will be different, because H and
H1 addresses will be different if nothing else.
That's a trivial point, but seems to be a constant point of
miscomunication between PO and others. I reckon that when PO says "computations H(P,P) and H1(P,P)" he is intending to say "the traces of
the SIMULATIONS of P(P) within H and H1", or similar. [And if I'm right above, those are NOT different, other than that H1 simulates FURTHER
than H, and so gets to observe the simulation halting. Nothing to do
with the presence of mysterious PSR!.]
Mike.
they would be exactly the same UP TO THE POINT WHERE H MAKES ITS
MISTAKE AND SAYS "INFINITE RECURSION DETECTED". I.e. H just makes the
wrong decision and terminates the simulation too early, like everyone
has been saying for over a year... :)
Mike.
olcott <polcott2@gmail.com> writes:
On 11/2/2021 12:13 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 11/2/2021 10:10 AM, Ben Bacarisse wrote:Only one error really matters, and that's the fact that H(P,P)==0 is not >>> correct if P(P) halts,
You want me to get sucked into discussing your other errors, but really >>>>> only one counts: H(P,P) == false is the wrong answer if P(P) halts.As long as H(P,P)==0 is correct none of my other "errors" are of any
consequence what-so-ever.
As long as the input to H(P,P) cannot possibly halt for every possible
encoding of simulating halt decider H then H(P,P)==0 can't possibly be
incorrect NO MATTER WHAT.
Whether H(P,P)==0 is correct is determined by what P(P) does, and since
P(P) halts, H(P,P)==0 is wrong.
If we have a black cat then it is utterly impossible that we do not
have a cat.
We have a hating computation, P(P), and an H that is wrong about it. I
don't know what all this nonsense about cats is intended to show.
olcott <NoOne@NoWhere.com> writes:
On 11/2/2021 10:20 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
On 11/2/2021 12:13 PM, Ben Bacarisse wrote:Whether H(P,P)==0 is correct is determined by what P(P) does, and since
olcott <polcott2@gmail.com> writes:
On 11/2/2021 10:10 AM, Ben Bacarisse wrote:Only one error really matters, and that's the fact that H(P,P)==0 is not >>>>> correct if P(P) halts,
You want me to get sucked into discussing your other errors, but really >>>>>>> only one counts: H(P,P) == false is the wrong answer if P(P) halts. >>>>>>>As long as H(P,P)==0 is correct none of my other "errors" are of any >>>>>> consequence what-so-ever.
As long as the input to H(P,P) cannot possibly halt for every possible >>>> encoding of simulating halt decider H then H(P,P)==0 can't possibly be >>>> incorrect NO MATTER WHAT.
P(P) halts, H(P,P)==0 is wrong.
THE IS THE MOST RECENT UPDATE TO THE CRITERION MEASURE
A halt decider only need answer whether or not the correct pure
simulation of its input would ever reach a final state of this input
by a simulating halt decider.
We could problem just have one sub-thread about this. What I said both
above and in my other reply still applied no matter how many times you re-write your criterion.
On 2021-11-03 09:53, olcott wrote:
On 11/3/2021 10:36 AM, André G. Isaak wrote:
On 2021-11-03 08:48, olcott wrote:
On 11/2/2021 10:30 PM, André G. Isaak wrote:
On 2021-11-02 21:14, olcott wrote:
On 11/2/2021 9:26 PM, André G. Isaak wrote:
On 2021-11-02 19:32, olcott wrote:
On 11/2/2021 8:07 PM, André G. Isaak wrote:
On 2021-11-02 18:49, olcott wrote:
On 11/2/2021 6:31 PM, André G. Isaak wrote:
On 2021-11-02 16:51, olcott wrote:
On 11/2/2021 4:49 PM, André G. Isaak wrote:
On 2021-11-02 15:41, olcott wrote:
On 11/2/2021 4:05 PM, André G. Isaak wrote:
On 2021-11-02 14:43, olcott wrote:
If everyone "defines" that the halt decider is wrong >>>>>>>>>>>>>>>> when it correctly reports what the actual behavior of >>>>>>>>>>>>>>>> its actual input would be then everyone (besides me) is >>>>>>>>>>>>>>>> wrong.
The definition tells you what a halt decider *is*. It >>>>>>>>>>>>>>> doesn't define it as 'wrong'. It defines what question it >>>>>>>>>>>>>>> is supposed to answer.
The input to a halt decider is a string. Strings don't >>>>>>>>>>>>>>> *have* halting behaviour so your position above is >>>>>>>>>>>>>>> entirely incoherent.
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
The definition of 'halting problem' is what it is.
Note that the above definition doesn't make any mentions of >>>>>>>>>>>>> 'simulations' just as the more formal definition used by >>>>>>>>>>>>> Linz's does not.
A halt decider only need answer whether or not the correct >>>>>>>>>>>>>> simulation of its input would ever reach a final state of >>>>>>>>>>>>>> this input by a simulating halt decider.
A 'correct simulation', presumably, would be one that acts >>>>>>>>>>>>> identically to the actual TM being simulated. That means >>>>>>>>>>>>> that if the actual TM halts the simulation also must halt. >>>>>>>>>>>>> Which means that your simulation is not a 'correct
simulation'.
There are no freaking presumptions about it. As long as the >>>>>>>>>>>> simulation of P(P) matches its x86 source code then the >>>>>>>>>>>> simulation is correct.
I have no idea what it means for a simulation of P(P) to >>>>>>>>>>> "match its x86 source code".
When the simulator executes the instructions at
0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
of the x86 source code of P, then the simulator
correctly simulated P(P).
No. A simulator only 'correctly simulates' a machine when it >>>>>>>>> accurately duplicates *all* of the behaviour of that machine. >>>>>>>>> Part of the behaviour of P(P) is that it halts.
That is a stupid thing to say. The x86 emulator correctly
emulates the x86 instructions of P iff it emulates the actual
x86 intructions of P saying anything else is both pure bullshit >>>>>>>> and quite nutty.
That's a nonsensical claim. If it correctly emulates all the
instructions then it should have identical behaviour. That
includes whether it halts or not.
Maybe you don't understand the x86 language well enough to ever
understand what I am saying.
While H continues to simulate P these first seven instructions of
P continue to repeat. Do you understand that?
Which is irrelevant to the halting problem
I will not speak with you until you answer.
Whether it does or does not repeat cannot be determined from this
trace because you omit the instructions from the subroutine from your
trace.
Begin Local Halt Decider Simulation at Machine Address:c36
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P) >>
When it is given that H is a pure simulator of its input can you
comprhend that the above seven lines infinitely repeat?
Nothing in the above seven lines indicates that they would repeat since
there is no instruction there which branches back to c36.
But, again, all of this is besides the point. A halt decider is supposed
to determine whether the machine described by its input halts on a given input. You acknowledge that P(P) halts. Therefore H(P, P) == 0 is
incorrect. We don't need to look at a trace to know that the answer is
wrong. We just need to compare the result which H(P, P) returns with the correct answer.
André
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 226:18:08 |
| Calls: | 6,624 |
| Calls today: | 6 |
| Files: | 12,171 |
| Messages: | 5,318,698 |