olcott <polcott2@gmail.com> writes:
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:H(P,P)==0 is wrong because P(P) halts. You keep trying to explain some
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.
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 youNo, 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
just don't believe it.
much like that. Almost exactly like that in fact.
It seems to be intuitively true that H(P,P) should report that itsNo. I have no intuition about what you even mean because inputs don't
input halts because P(P) halts.
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 intuitionI don't have that intuition. What "the input" does is meaningless.
Every halt decider is ONLY tasked with determining the behavior of its
input.
No. Every halt decider is tasked with determining the behaviour of the computation represented by its input. That's why H(P,P)==0 is wrong.
The arguments in that call represent the halting computation P(P).
That you say otherwise is very stupid.
I say otherwise because I know what the halting problem is, and because
I want to be careful about the details. You are deliberately not
talking about what the input represents because you know H is wrong
about that computation. This shift in wording is all you have left
after 14 years of being wrong about halting.
On 2021-11-03 09:47, olcott wrote:
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.
The halting problem already defines what the criterion used by a halt
decider must be. You don't get to update it if that's the problem you
want to work on.
André
olcott <NoOne@NoWhere.com> writes:
On 11/2/2021 10:17 PM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
Every halt decider is ONLY tasked with determining the behavior of its >>>> input.
No. Every halt decider is tasked with determining the behaviour of the
computation represented by its input. That's why H(P,P)==0 is wrong.
The arguments in that call represent the halting computation P(P).
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.
The halting problem is already defined, thank you. H(P,P) == false is
wrong because P(P) halts.
olcott <NoOne@NoWhere.com> writes:
No one here seems capable of understanding is that when a halt decider
does correctly decide the halt status of its input then its input has
had its halt status correctly decided.
Don't be silly. No one disputes that (thought the wording is poor).
The only disagreement is on what the correct answer is. Since P(P)
halts and H(P,P) == false, H is not deciding correctly.
On 2021-11-03 11:19, olcott wrote:
On 11/3/2021 12:09 PM, André G. Isaak wrote:
On 2021-11-03 10:14, olcott wrote:
On 11/3/2021 11:00 AM, André G. Isaak wrote:
On 2021-11-03 09:47, olcott wrote:
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.
The halting problem already defines what the criterion used by a
halt decider must be. You don't get to update it if that's the
problem you want to work on.
André
No one here seems capable of understanding is that when a halt
decider does correctly decide the halt status of its input then its
input has had its halt status correctly decided.
Right. And since yours doesn't correctly decide the halt status of
its input then its input has not had its halt status correctly decided.
The only criteria for correctly deciding the halt status of the actual
input is whether or not the correct pure simulation of this input
would ever reach a final state.
Every other criteria changes the subject to an entirely different
comutation.
Both 'halting problem' and 'halt decider' were defined before you were
born by people who actually UNDERSTOOD the topic.
The definitions of these things are precise, unambiguous, and clearly indicate the actual criterion which a halt decider must use in making
its decision. That criterion makes no reference to pure simulations. It refers only to whether the computation represented by the input string
halts.
On 2021-11-03 14:02, olcott wrote:
On 11/3/2021 2:02 PM, André G. Isaak wrote:
On 2021-11-03 12:23, olcott wrote:It is impossible for any halt decider to be incorrect when the correct
On 11/3/2021 12:44 PM, André G. Isaak wrote:
On 2021-11-03 11:19, olcott wrote:
On 11/3/2021 12:09 PM, André G. Isaak wrote:
On 2021-11-03 10:14, olcott wrote:
On 11/3/2021 11:00 AM, André G. Isaak wrote:
On 2021-11-03 09:47, olcott wrote:
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.
The halting problem already defines what the criterion used by >>>>>>>>> a halt decider must be. You don't get to update it if that's >>>>>>>>> the problem you want to work on.
André
No one here seems capable of understanding is that when a halt >>>>>>>> decider does correctly decide the halt status of its input then >>>>>>>> its input has had its halt status correctly decided.
Right. And since yours doesn't correctly decide the halt status
of its input then its input has not had its halt status correctly >>>>>>> decided.
The only criteria for correctly deciding the halt status of the
actual input is whether or not the correct pure simulation of this >>>>>> input would ever reach a final state.
Every other criteria changes the subject to an entirely different
comutation.
Both 'halting problem' and 'halt decider' were defined before you
were born by people who actually UNDERSTOOD the topic.
The definitions of these things are precise, unambiguous, and
clearly indicate the actual criterion which a halt decider must use
in making its decision. That criterion makes no reference to pure
simulations. It refers only to whether the computation represented
by the input string halts.
It is impossible for any halt decider to be incorrect when the
correct pure simulation of its input never halts and it reports not
halting.
Not if it contradicts the actual correct answer as determined by the
criterion which defines the halting problem since that criterion
alone determines which answer is correct.
pure simulation of its input never halts and it reports not halting.
But your halt decider doesn't implement a 'pure simulation' under any reasonable definition of the term.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 365 |
Nodes: | 16 (0 / 16) |
Uptime: | 11:07:51 |
Calls: | 7,758 |
Calls today: | 1 |
Files: | 12,897 |
Messages: | 5,744,534 |