On 2021-11-08 17:47, olcott wrote:
On 11/8/2021 6:12 PM, André G. Isaak wrote:
On 2021-11-08 16:41, olcott wrote:
On 11/8/2021 5:11 PM, André G. Isaak wrote:
On 2021-11-08 15:54, olcott wrote:
On 11/8/2021 2:47 PM, André G. Isaak wrote:
On 2021-11-08 12:52, olcott wrote:
On 11/8/2021 10:32 AM, André G. Isaak wrote:
On 2021-11-08 08:26, olcott wrote:
On 11/7/2021 11:51 PM, André G. Isaak wrote:
On 2021-11-07 22:00, olcott wrote:
On 11/7/2021 10:46 PM, André G. Isaak wrote:
On 2021-11-07 20:19, olcott wrote:
Yet you cannot point to a single error in any of the >>>>>>>>>>>>>> details below because there are no errors in any of the >>>>>>>>>>>>>> details below.
I don't *need* to point out any errors in the below.
If is it not simulated correctly then at least one of the >>>>>>>>>>>> simulated instructions is not simulated correctly. If all of >>>>>>>>>>>> the simulated instructions are simulated correctly then the >>>>>>>>>>>> simulation is correct.
If it were being simulated correctly, the simulation would >>>>>>>>>>> have the exact same behaviour as P(P). It does not. It is >>>>>>>>>>> therefore not being simulated correctly. BY DEFINITION.
And your trace don't show anything being simulated. If it >>>>>>>>>>> did, the actual simulator code would be part of the trace. >>>>>>>>>>>
Even if I was merely simulating it in my head and writing it down >>>>>>>>>> using cut-and-paste the fact that
Each instruction of the x86 source code of P is simulated in >>>>>>>>>> the exact same sequence that it is specified in the above
source code then we know that this aspect of the pure
simulation the input to H(P,P) is perfectly correct.
We know that P(P) halts. Therefore you are not correctly
simulating the instruction which causes it to halt. Therefore >>>>>>>>> you are not "correctly" simulating it.
You do not address the critical point: P(P) halts.
I have addressed it many times and you make sure to always ignore
the fact that P(P) and H(P,P) are proven to be entirely different
Of course P(P) and H(P, P) are different computations. But what I
*think* you are trying to say is that independent P(P) is different
from what happens inside the simulator. At least *try* to say what
you mean.
computations by the fact of the one-way dependency of P(P) on the
return value of its invocation of H(P,P).
And you keep ignoring the fact that the computation which H(P, P)
is supposed to be answering about is P(P).
The pure simulation of the input to H1(P,P) is computationally
equivalent to the direct execution of P(P).
The pure simulation of the input to H(P,P) is NOT computationally
equivalent to the direct execution of P(P).
And the halt decider is being asked to describe the behaviour of the
DIRECT EXECUTION of P(P). That's what halt deciders are defined to do.
If H directly executed its input in debug step mode the result would
be the same. The one-way dependency that P(P) has on the return value
of its execution of H(P,P) makes P(P) and H(P,P) entirely different
computations that are not equivalent.
You seem to have rather serious reading comprehension problems since you
keep coming back to what happens inside H. The correct answer for H(P,
P) to give is the one that corresponds to the ACTUAL DIRECT EXECUTION of P(P). And P(P) HALTS.
And no one ever claimed P(P) and H(P, P) are equivalent. They are not supposed to be equivalent. H(P, P) is supposed to describe the halting behaviour of P(P) WHICH DOES IN FACT HALT. It isn't being asked about
the halting behaviour of H(P, P).
The question which your halt decider must answer is "does P(P) halt?"
because that is how the halting problem is DEFINED.
André
On 11/8/21 8:46 PM, olcott wrote:
On 11/8/2021 7:40 PM, André G. Isaak wrote:
On 2021-11-08 17:47, olcott wrote:
On 11/8/2021 6:12 PM, André G. Isaak wrote:
On 2021-11-08 16:41, olcott wrote:
On 11/8/2021 5:11 PM, André G. Isaak wrote:
On 2021-11-08 15:54, olcott wrote:
On 11/8/2021 2:47 PM, André G. Isaak wrote:
On 2021-11-08 12:52, olcott wrote:
On 11/8/2021 10:32 AM, André G. Isaak wrote:
On 2021-11-08 08:26, olcott wrote:
On 11/7/2021 11:51 PM, André G. Isaak wrote:
On 2021-11-07 22:00, olcott wrote:
On 11/7/2021 10:46 PM, André G. Isaak wrote:
On 2021-11-07 20:19, olcott wrote:
If is it not simulated correctly then at least one of the >>>>>>>>>>>>>> simulated instructions is not simulated correctly. If all >>>>>>>>>>>>>> of the simulated instructions are simulated correctly then >>>>>>>>>>>>>> the simulation is correct.Yet you cannot point to a single error in any of the >>>>>>>>>>>>>>>> details below because there are no errors in any of the >>>>>>>>>>>>>>>> details below.
I don't *need* to point out any errors in the below. >>>>>>>>>>>>>>
If it were being simulated correctly, the simulation would >>>>>>>>>>>>> have the exact same behaviour as P(P). It does not. It is >>>>>>>>>>>>> therefore not being simulated correctly. BY DEFINITION. >>>>>>>>>>>>>
And your trace don't show anything being simulated. If it >>>>>>>>>>>>> did, the actual simulator code would be part of the trace. >>>>>>>>>>>>>
Even if I was merely simulating it in my head and writing it >>>>>>>>>>>> down
using cut-and-paste the fact that
Each instruction of the x86 source code of P is simulated in >>>>>>>>>>>> the exact same sequence that it is specified in the above >>>>>>>>>>>> source code then we know that this aspect of the pure
simulation the input to H(P,P) is perfectly correct.
We know that P(P) halts. Therefore you are not correctly >>>>>>>>>>> simulating the instruction which causes it to halt. Therefore >>>>>>>>>>> you are not "correctly" simulating it.
You do not address the critical point: P(P) halts.
I have addressed it many times and you make sure to always
ignore the fact that P(P) and H(P,P) are proven to be entirely >>>>>>>> different
Of course P(P) and H(P, P) are different computations. But what I >>>>>>> *think* you are trying to say is that independent P(P) is
different from what happens inside the simulator. At least *try* >>>>>>> to say what you mean.
computations by the fact of the one-way dependency of P(P) on
the return value of its invocation of H(P,P).
And you keep ignoring the fact that the computation which H(P, P) >>>>>>> is supposed to be answering about is P(P).
The pure simulation of the input to H1(P,P) is computationally
equivalent to the direct execution of P(P).
The pure simulation of the input to H(P,P) is NOT computationally
equivalent to the direct execution of P(P).
And the halt decider is being asked to describe the behaviour of
the DIRECT EXECUTION of P(P). That's what halt deciders are defined
to do.
If H directly executed its input in debug step mode the result would
be the same. The one-way dependency that P(P) has on the return
value of its execution of H(P,P) makes P(P) and H(P,P) entirely
different computations that are not equivalent.
You seem to have rather serious reading comprehension problems since
you keep coming back to what happens inside H. The correct answer for
H(P, P) to give is the one that corresponds to the ACTUAL DIRECT
EXECUTION of P(P). And P(P) HALTS.
The direct execution of the input to H(P,P) does not halt therefore
H(P,P)==0 is correct.
SO you LIE?
The closest thing to 'direct execution of the input to H(P,P)' would be
On 2021-11-09 14:49, olcott wrote:
On 11/9/2021 1:57 PM, André G. Isaak wrote:
On 2021-11-09 11:10, olcott wrote:
On 11/9/2021 11:56 AM, André G. Isaak wrote:
On 2021-11-09 10:00, olcott wrote:
On 11/9/2021 10:42 AM, André G. Isaak wrote:Those two references say exactly the same thing that I did. They
On 2021-11-09 09:09, olcott wrote:
On 11/9/2021 9:56 AM, André G. Isaak wrote:But the halting problem doesn't ask what happens when you call
On 2021-11-08 20:34, olcott wrote:
None-the-less I have utterly refuted the idea that H(P,P) must >>>>>>>>>> report what the direct execution of what P(P) does. Whether >>>>>>>>>> its input is simulated or directly executed the input to
H(P,P) never halts.
Look, I realize that you and reality aren't exactly on speaking >>>>>>>>> terms, but the above claim is going into lalaland even for you. >>>>>>>>>
To claim that you have "utterly refuted the idea that H(P,P) >>>>>>>>> must report what the direct execution of what P(P) does." is >>>>>>>>> tantamount to saying that you have refuted the idea that an add >>>>>>>>> function ADD(x, y) must return the sum of x and y. You can't >>>>>>>>> refute the idea that a program must answer the question which >>>>>>>>> it purports to answer
If H is a halt decider, then H(P, P) must BY THE DEFINITION OF >>>>>>>>> HALT DECIDER return true if and only if P(P) halts. What a
simulation of P(P) by H does, or what the "direct execution of >>>>>>>>> the input to H(P, P)" (whatever the hell that means) aren't
what a halt decider is being asked about. A halt decider is
being asked about P(P) which you acknowledge halts. Halt
decider is a well-defined term. You don't get to redefine the >>>>>>>>> question which a halt decider must answer.
André
To refute the claim that the direct execution of P(P) halts thus >>>>>>>> its simulation is incorrect H(P,P) directly executes its input >>>>>>>> instead of simulating it. The result is the infinitely nested
simulation becomes infinite recursion. In no case does the
following directly executed P ever reach its final state of c50. >>>>>>>
P(P) from within H. It asks what happens when you run P(P). And
that computation halts.
the Turing machine halting problem. Simply stated, the problem
is: given the description of a Turing machine M and an input w,
does M, when started in the initial configuration q0w, perform
a computation that eventually halts? (Linz:1990:317). >>>>>>
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 >>>>>
CONFIRM my position.
Not quite. Those two references imply that it is only the behavior
of the input to H that counts everything else is out-of-scope.
You might want to take a course on remedial reading comprehension.
The input to the Halt Decider is a *description* of Turing Machine M.
The x86 equivalent of this is some description of an x86 unit of
computation.
What exactly is a 'unit of computation"? Is that like a meter or a yen?
The key detail that you keep missing is that it only has to decide the
behavior of its actual input. Some other computation that is somewhere
else makes not one damn bit of difference to the correctness of its
decision of its actual input.
That "key detail" falls into the category of "not even wrong". Why don't
you try rereading the definitions of the halting problem that you
posted, only this time try to actually *understand* them.
I am only focusing on the logical necessity that H(P,P)==0 is correct
for every simulating halt decider H until 100% complete closure of
this point is obtained. I will simply ignore all attempts to change
the subject Away from this point as a dishonest dodge.
Pointing out your errors hardly counts as "changing the subject".
André
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 81:29:47 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,333,316 |
| Posted today: | 1 |