On Sun, 07 Nov 2021 20:52:58 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
On Sun, 07 Nov 2021 13:57:26 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
olcott <NoOne@NoWhere.com> writes:
After many reviews no one has pointed out any error in this
claim: There is no possible simulating halt decider H such that
the correct pure simulation of the input to H(P,P) ever reaches
the final instruction of P.
As you know, there are no halt deciders
Not true. As long as the decider can recognize pathological self
reference and has infinite resources it can decide if a program
halts.
That's not what a halt decider is.
Sure it is.
/Flibble
On 2021-11-07 18:17, olcott wrote:
On 11/7/2021 6:39 PM, André G. Isaak wrote:
On 2021-11-07 17:25, olcott wrote:
On 11/7/2021 3:59 PM, Mr Flibble wrote:
On Sun, 07 Nov 2021 20:52:58 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
On Sun, 07 Nov 2021 13:57:26 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
olcott <NoOne@NoWhere.com> writes:
After many reviews no one has pointed out any error in this
claim: There is no possible simulating halt decider H such that >>>>>>>>> the correct pure simulation of the input to H(P,P) ever reaches >>>>>>>>> the final instruction of P.
As you know, there are no halt deciders
Not true. As long as the decider can recognize pathological self >>>>>>> reference and has infinite resources it can decide if a program
halts.
That's not what a halt decider is.
Sure it is.
/Flibble
...As long as the decider can... decide if a program halts:
Then we know it must be a halt decider for this program.
Because they are so highly motivated to disagree here are the key
points that no one else yet understands:
(A) If the simulated input of H(P,P) never halts then it is correct
for H to report that its simulated input never halts.
Not when you claim that the simulation can differ from the actual
execution.
So you are saying that sometimes a cat is not a cat.
I never mentioned cats. I am saying that a "simulation" which differs
from the actual execution is not actually a simulation at all.
Arguing with semantic tautologies makes you look stupid.
I'm not arguing with a semantic tautology. I'm arguing against your
rather ridiculous claims.
(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P) >>>> [ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.
Putting aside your strange use of the term 'simulate', a halt decider
So again you are saying that a cat is not a cat except that you are
saying that a correct simulation is not a correct simulation.
If it doesn't behave identically to the actual computation then it is
not a correct simulation.
André
On 2021-11-07 17:25, olcott wrote:
On 11/7/2021 3:59 PM, Mr Flibble wrote:
On Sun, 07 Nov 2021 20:52:58 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
On Sun, 07 Nov 2021 13:57:26 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
olcott <NoOne@NoWhere.com> writes:
After many reviews no one has pointed out any error in this
claim: There is no possible simulating halt decider H such that
the correct pure simulation of the input to H(P,P) ever reaches
the final instruction of P.
As you know, there are no halt deciders
Not true. As long as the decider can recognize pathological self
reference and has infinite resources it can decide if a program
halts.
That's not what a halt decider is.
Sure it is.
/Flibble
...As long as the decider can... decide if a program halts:
Then we know it must be a halt decider for this program.
Because they are so highly motivated to disagree here are the key
points that no one else yet understands:
(A) If the simulated input of H(P,P) never halts then it is correct
for H to report that its simulated input never halts.
Not when you claim that the simulation can differ from the actual
execution.
(B) Because of the one-way dependency relationship between the
executed P and the simulation of itself that it invokes: H(P,P)
[ P only halts because H(P,P) returns 0 ]
the executed P has different behavior than its simulated P.
Putting aside your strange use of the term 'simulate', a halt decider
must accurately describe the behaviour of "executed P". That's the
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.
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.
On Mon, 8 Nov 2021 07:33:44 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
On 11/8/21 12:00 AM, olcott wrote:
On 11/7/2021 10:46 PM, André G. Isaak wrote:
On 2021-11-07 20:19, olcott wrote:
On 11/7/2021 8:57 PM, André G. Isaak wrote:
On 2021-11-07 19:00, olcott wrote:
On 11/7/2021 7:24 PM, André G. Isaak wrote:
On 2021-11-07 18:17, olcott wrote:
On 11/7/2021 6:39 PM, André G. Isaak wrote:
On 2021-11-07 17:25, olcott wrote:
On 11/7/2021 3:59 PM, Mr Flibble wrote:
On Sun, 07 Nov 2021 20:52:58 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
On Sun, 07 Nov 2021 13:57:26 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
olcott <NoOne@NoWhere.com> writes:
After many reviews no one has pointed out any error in >>>>>>>>>>>>>>>> this claim: There is no possible simulating halt >>>>>>>>>>>>>>>> decider H such that
the correct pure simulation of the input to H(P,P) >>>>>>>>>>>>>>>> ever reaches
the final instruction of P.
As you know, there are no halt deciders
Not true. As long as the decider can recognize
pathological self
reference and has infinite resources it can decide if a >>>>>>>>>>>>>> program halts.
That's not what a halt decider is.
Sure it is.
/Flibble
...As long as the decider can... decide if a program halts: >>>>>>>>>>> Then we know it must be a halt decider for this program. >>>>>>>>>>>
Because they are so highly motivated to disagree here are >>>>>>>>>>> the key points that no one else yet understands:
(A) If the simulated input of H(P,P) never halts then it is >>>>>>>>>>> correct for H to report that its simulated input never
halts.
Not when you claim that the simulation can differ from the >>>>>>>>>> actual execution.
So you are saying that sometimes a cat is not a cat.
I never mentioned cats. I am saying that a "simulation" which
differs from the actual execution is not actually a simulation >>>>>>>> at all.
Arguing with semantic tautologies makes you look stupid.
I'm not arguing with a semantic tautology. I'm arguing against >>>>>>>> your rather ridiculous claims.
You are saying that when the correct pure simulation of the
input to H(P,P) never halts it is incorrect for H to report
that the simulation of its input never halts which is the same
thing as saying that it is incorrect to say that a cat is a
cat.
No. I am saying that H(P, P) does not perform a 'correct pure
simulation' of its input. A halt decider must accurately
describe the behaviour of the *actual* computation P(P).
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.
The Call 966 is not simulated correctly.
That has been pointed out before and you have ignored it, so you LIE
when you say that all the instructions are simulated correctly.
You put a deciteful disclaimer that limits the correctness to only
the 'simulated instructions' but that is just a dishonest dodge as a
pure simulation must simulate ALL the instructions it come to, not
just some select set.
It isn't even an equivalent simulation, as the substitution of
substituion of the code being simulated for the simulation of the
simulator is a valid transform only for an unconditional simulator,
and thus by doing so you are building into your precondition set that
H will NEVER abort its simulation. When you then decide to have H
abort its simulation you violate your conditions.
That is like making a transform on an equation that is based on the
fact that x > x+1, because there is no such x, just as there is no H
that both never aborts it simulation and also aborts its simulation.
This equivalence IS valid for just one case, the case when H actually
doesn't ever abort its simulation. In this case you proof does work,
and you do show that the P based on that H is non-halting, but
unfortunately for you, you also prove that in that case, H never
actually gives that answer, so this H isn't correct either.
A lot of you 'logic' is just a smoke screen to try and decive the
reader to think that it is ok for the H that aborts its simulation to
be used to decide on the P based on the H that doesn't. It does get
that case right, but it isn't the case you need to show, you need to
show that an H can get the H^/P based on itself correctly.
You seem to regularly like to reuse notation for different cases,
which appears to just be again part of your pattern to deceive.Even
you switch from H^ to P is an example of this.
The fact that P(P) halts whereas your simulation does not is
sufficient to know that it is not an accurate simulation. An
accurate simulation behaves *identically* to the thing being
simulated. Yours does not. That's a simple matter of definition.
That no one has pointed out the specific error in your trace is
because the trace omits the relevant details
It does not omit any relevant details.
WRONG. LIAR.
(i.e. the point at which it decides to abort or not to abort). And
the trace is meaningless because the result of the test eax, eax
instruction depends on that omitted code.
André
Do you understand that if H(P,P) aborts the simulation of its input
that its input never reaches its final state and thus never halts?
WRONG. The fact that H(P,P) aborts ITS Simulation of its input does
not affect what the PURE SIMULATION of that input would do.
UTM(P,P) Halts whenever H(P,P) == 0, that is a simple provable fact.
You just show you total IGNORANCE by your claim.
H, if it returns 0, is NOT a PURE SIMULATOR, you should know it,
either you are a LIAR or an IDIOT.
Which is it.
(Attacking the person): This fallacy occurs when, instead of addressing someone's argument or position, you irrelevantly attack the person or
some aspect of the person who is making the argument.
Olcott's halt decider either decides if a program halts or does not
halt or it throws an exception if pathological self reference occurs;
it is thus a valid halt decider -- the third result of exception is
perfectly valid result as it only occurs if you are DELIBERATELY trying
to defeat the decider but I still contend the decider needs to be a
black box to legitimately enable this behavior.
/Flibble
--
This message is a troll.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 384 |
Nodes: | 16 (3 / 13) |
Uptime: | 60:18:18 |
Calls: | 8,173 |
Calls today: | 5 |
Files: | 13,113 |
Messages: | 5,864,381 |