On 2021-09-08 14:41, olcott wrote:
On 9/8/2021 3:02 PM, André G. Isaak wrote:
On 2021-09-08 13:33, olcott wrote:
On 9/8/2021 2:13 PM, olcott wrote:
On 9/8/2021 1:58 PM, André G. Isaak wrote:
On 2021-09-08 12:12, olcott wrote:
On 9/8/2021 12:59 PM, André G. Isaak wrote:Yes, we could and I did.
But ⟨Ĥ⟩ ⟨Ĥ⟩ represents a *single* computation. It either halts
or it doesn't.
We could say the same thing about P(P), yet we can clearly see every >>>>>>
single step where H1(P,P) correctly reports that its input halts >>>>>>> because H(P,P) correctly reports that its input never halts.
H(P, P) *can't* correctly report that its input never halts
because P(P) does halt.
You can ignore this forever, yet that will not make a verifiable >>>>>>> fact simply go away.
You're ignoring the fact that it gets the answer wrong since you
are overlooking the actual definition of the halting problem.
We can see that unless H(P,P) aborts the simulation of its input
that its input never halts.
You've said this many times but it is simply wrong. We know that P(P)
is a halting computation.
You can say that you don't see this only because you don't look at it. >>>>> At this point after it has been brought up so many times you must
simply be a God damned liar.
Begin Local Halt Decider Simulation at Machine Address:c36
[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)
[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call
H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The above code does match this infinite recursion pattern and the
infinite recursion pattern is correct therefore the input to H(P,P)
never halts even if an omniscient being disagrees.
A trace shows *how* a particular program got to a particular answer.
It in no way establishes that that answer is actually correct. Traces
are not proofs. If you ever attempt to publish your work, no one is
even going to be willing to look at a trace.
The problem is that your 'infinite recursion pattern' doesn't work.
And how can something be 'correct' if an omniscient being (taking the
term literally) disagrees?
This infinite recursion detection criteria are met by the above
execution trace:
(a) P calls H twice in sequence from the same machine address.
(b) With the same parameters: (P,P) to H.
(c) With no conditional branch or indexed jump instructions in the
execution trace of P.
(d) We know that there are no return instructions in H because we
know that H is in pure simulation mode.
As has been pointed out many times, your (d) is simply wrong. It
cannot be justified in any way. And your (d) is why your H
erroneously concludes that P(P) halts.
But even if we ignore (d), you can't just pull some criteria out of
your ass and claim that these criteria work without providing actual
proof. I can think of numerous ways to construct a C routine which
would meet conditions (a)-(c) but which would not be infinitely
recursive.
If X has no effect on Y until after Z then X can be ignored before Z.
X is a simulating halt decider
Y is its input program
Z When X makes its halt status decision.
THIS IS A TRUISM THUS DISAGREEMENT IS ERROR
While H acts as a pure simulator of P(P) nothing that X does has any
effect on the behavior of P(P) therefore X can ignore its own behavior
while making its halt status decision.
Declaring something to be a 'truism' doesn't magically make it true.
That requires actual proof which you haven't given, whereas many people (myself included) have already explained at length why it is wrong.
It might sound plausible, but your sloppy use of the term 'its' destroys
that plausibilty.
The only way to prove that the above infinite recursion detection
criteria are correct is to show that there are no counter-examples of
cases that meet the criteria and are not infinitely recursive.
Once (a)(b)(c)(d) criteria have been met
not infinitely recursive is categorically impossible.
As I said, I can think of numerous ways to write a C program which meets those requirements but which is not infinitely recursive.
So clearly it
isn't "categorically impossible". You should think about this rather
harder. If you can't come up with counterexamples in a week or so maybe
I'll provide some.
The crucial point is that just because *you* haven't thought of counterexamples doesn't mean there aren't any.
You can't just declare
something to be 'categorically impossible' unless you can actually
*prove* this. You have note.
And of course, even if these criteria worked they are completely
worthless where actually TMs are concerned since TMs don't have machine addresses and can't call things.
This has been somewhat extensively reviewed.
Which, again, doesn't make it true. It's not incumbent on others to make
your case for you, and you make so many errors that people can't be
bothered to point out all of them. People have been more focused on your patently false (d) rather than on the other three since that's the one
which causes your H to get the wrong answer.
André
On 2021-09-08 16:00, olcott wrote:
On 9/8/2021 4:27 PM, André G. Isaak wrote:
On 2021-09-08 14:41, olcott wrote:
Declaring something to be a 'truism' doesn't magically make it true.
That requires actual proof which you haven't given, whereas many
people (myself included) have already explained at length why it is
wrong.
It is impossibly incorrect.
"impossibly incorrect" is not English. Illiterate buffoon makes you look
like your continual (mis)use of this term.
Maybe this simplification is easy enough for you to understand:
If X cannot possibly have any effect on Y then there is never any
reason to study the effect of X on Y.
When H(P, P) is called, H cannot have an effect on P(P), but P(P) makes
its own call to H(P, P). Your upper H *cannot* ignore this one because
it is an entirely different process. It is *part* of the P(P) being
evaluated by the upper H.
This is patently obvious to everyone but you.
Calling something a 'truism' when you haven't been able to convince even
a single person of its truth is hardly warranted.
It might sound plausible, but your sloppy use of the term 'its'
destroys that plausibilty.
The only way to prove that the above infinite recursion detection
criteria are correct is to show that there are no counter-examples
of cases that meet the criteria and are not infinitely recursive.
Once (a)(b)(c)(d) criteria have been met
not infinitely recursive is categorically impossible.
As I said, I can think of numerous ways to write a C program which
meets those requirements but which is not infinitely recursive.
Name at least one. That list has been the subject of numerous
revisions to make it as simple as possible.
I told you that I would, but that I would first give you a week or so to think about it further. Your approach has always been "this works for
all the cases I considered, therefore it works in all cases" which is
*not* valid logic. You should perhaps think of more cases. But of course
it doesn't matter how many cases you consider, there will always be
cases you haven't considered. That's why a proof can't simply consist of showing it works in some cases.
On 2021-09-08 20:02, olcott wrote:
On 9/8/2021 8:21 PM, André G. Isaak wrote:
On 2021-09-08 16:34, olcott wrote:
On 9/8/2021 5:20 PM, André G. Isaak wrote:
On 2021-09-08 16:00, olcott wrote:
On 9/8/2021 4:27 PM, André G. Isaak wrote:
On 2021-09-08 14:41, olcott wrote:
Declaring something to be a 'truism' doesn't magically make it
true. That requires actual proof which you haven't given, whereas >>>>>>> many people (myself included) have already explained at length
why it is wrong.
It is impossibly incorrect.
"impossibly incorrect" is not English. Illiterate buffoon makes you
look like your continual (mis)use of this term.
Maybe this simplification is easy enough for you to understand:
If X cannot possibly have any effect on Y then there is never any
reason to study the effect of X on Y.
When H(P, P) is called, H cannot have an effect on P(P), but P(P)
makes its own call to H(P, P). Your upper H *cannot* ignore this
one because it is an entirely different process. It is *part* of
the P(P) being evaluated by the upper H.
This is patently obvious to everyone but you.
So go one and show the actual "patently obvious" error.
I am calling your bluff!
I just did. The H which is *evaluating* the input P(P) can't affect
the behaviour of its input, but the second call to H *isn't*
evaluating P(P), it is *part* of the computation performed by P(P)
and that computation is critically dependent on what that H does. You
can't just ignore it.
None of the recursive invocations of H has any effect on the behavior
of its input until after the behavior of its input has matched the
INFINITE_LOOP or INFINITE_RECURSION behavior pattern.
Every time that such a rebuttal is made I utterly refute it and my
refutation is simply ignored. Later on the same lame rebuttal (that
does not even bother to connect most of its ideas together) is
presented again.
You've never 'utterly refuted' anything. You just keep reiterating your original position in response to clear evidence that your initial
position is simply wrong.
You keep using terms like 'its input' and 'its
simulator' where 'its' rather sloppily refers to the wrong things. You
really need to strike the word 'its' from your vocabulary altogether.
I know that no H in the entire recursive invocation chain has any
effect on the behavior of its input until after the outer-most H
makes its halt status decision.
I know that this outer-most H makes its halt status decision on the
basis that the behavior of its input has matched the infinite
recursion behavior pattern.
But your 'infinite recursion behaviour pattern' is flawed. In this
particular instance precisely because of your (d).
Calling something a 'truism' when you haven't been able to convince
even a single person of its truth is hardly warranted.
It might sound plausible, but your sloppy use of the term 'its'
destroys that plausibilty.
The only way to prove that the above infinite recursion
detection criteria are correct is to show that there are no
counter-examples of cases that meet the criteria and are not
infinitely recursive.
Once (a)(b)(c)(d) criteria have been met
not infinitely recursive is categorically impossible.
As I said, I can think of numerous ways to write a C program
which meets those requirements but which is not infinitely
recursive.
Name at least one. That list has been the subject of numerous
revisions to make it as simple as possible.
I told you that I would, but that I would first give you a week or
so to think about it further. Your approach has always been "this
works for all the cases I considered, therefore it works in all
cases" which is *not* valid logic. You should perhaps think of more
cases. But of course it doesn't matter how many cases you consider,
there will always be cases you haven't considered. That's why a
proof can't simply consist of showing it works in some cases.
This has been under review for many months.
I am calling your bluff.
Your really that adverse to thinking on something for a week?
Just to give you a few hints, though, your (a)-(c) make no mention of
(among other things) cases where the routine manipulates the contents
of the stack or the stack pointer, or cases where the routine
involves self-modifying code. There's all sorts of creative ways to
meet your criteria without being infinitely recursive using those.
I am not convinced that this is a counter-example, yet it does seem
reasonably plausible. The current code does not do that so we can see
that the halt decider did decide correctly.
Whether you are convinced or not isn't the issue. Since you claim it is 'reasonably plausible' you need to actually think it through. I assure
you it is possible to create routines which meet your 'infinite
recursion pattern' but which are not infinitely recursive using these strategies. Without actually showing that it is *impossible* to do so
(which you can't because it isn't), claiming you don't find it
convincing doesn't get you very far.
Whether the current code does so or not isn't relevant since I was
responding to your statement that once your criteria are met "not
infinitely recursive is categorically impossible."
This only requires that the halt decider be made more elaborate, not
that the "impossible input" cannot be correctly decided.
'Must be made more elaborate' isn't worth much unless you can actually demonstrate that it is *possible* to make them more elaborate to the
extent that they cover all cases. You can't.
I simply assume that all of the code is generated by the Microsoft C
compiler. x86utm can only read COFF object files.
Relevance? The strategies for breaking your 'infinite recursion pattern'
I offered are all possible using the Microsoft C compiler.
André
On 9/9/2021 12:16 AM, André G. Isaak wrote:
On 2021-09-08 20:02, olcott wrote:
On 9/8/2021 8:21 PM, André G. Isaak wrote:
On 2021-09-08 16:34, olcott wrote:
On 9/8/2021 5:20 PM, André G. Isaak wrote:
On 2021-09-08 16:00, olcott wrote:
On 9/8/2021 4:27 PM, André G. Isaak wrote:
On 2021-09-08 14:41, olcott wrote:
The key evidence is my code and you can't see my code so you can't
truthfully say what my code does. Even though you can't truthfully say
this you dishonestly say what it does anyway.
You keep using terms like 'its input' and 'its simulator' where 'its'
rather sloppily refers to the wrong things. You really need to strike
the word 'its' from your vocabulary altogether.
When H(P,P) is invoked none of its recursive invocations has any effect
on the halting behavior of P(P) until after a non-halting behavior
pattern has been matched.
Until a non-halting behavior pattern has been matched H merely simulates
its input and examines the execution trace of this simulation. Neither
of these things can possibly have any effect on the behavior of the input.
I know that no H in the entire recursive invocation chain has any
effect on the behavior of its input until after the outer-most H
makes its halt status decision.
I know that this outer-most H makes its halt status decision on the
basis that the behavior of its input has matched the infinite
recursion behavior pattern.
But your 'infinite recursion behaviour pattern' is flawed. In this
particular instance precisely because of your (d).
Calling something a 'truism' when you haven't been able to
convince even a single person of its truth is hardly warranted.
It might sound plausible, but your sloppy use of the term 'its' >>>>>>>> destroys that plausibilty.
The only way to prove that the above infinite recursion
detection criteria are correct is to show that there are no
counter-examples of cases that meet the criteria and are not >>>>>>>>> infinitely recursive.
Once (a)(b)(c)(d) criteria have been met
not infinitely recursive is categorically impossible.
As I said, I can think of numerous ways to write a C program
which meets those requirements but which is not infinitely
recursive.
Name at least one. That list has been the subject of numerous
revisions to make it as simple as possible.
I told you that I would, but that I would first give you a week or >>>>>> so to think about it further. Your approach has always been "this
works for all the cases I considered, therefore it works in all
cases" which is *not* valid logic. You should perhaps think of
more cases. But of course it doesn't matter how many cases you
consider, there will always be cases you haven't considered.
That's why a proof can't simply consist of showing it works in
some cases.
This has been under review for many months.
I am calling your bluff.
Your really that adverse to thinking on something for a week?
Just to give you a few hints, though, your (a)-(c) make no mention
of (among other things) cases where the routine manipulates the
contents of the stack or the stack pointer, or cases where the
routine involves self-modifying code. There's all sorts of creative
ways to meet your criteria without being infinitely recursive using
those.
I am not convinced that this is a counter-example, yet it does seem
reasonably plausible. The current code does not do that so we can see
that the halt decider did decide correctly.
Whether you are convinced or not isn't the issue. Since you claim it
is 'reasonably plausible' you need to actually think it through. I
assure you it is possible to create routines which meet your 'infinite
recursion pattern' but which are not infinitely recursive using these
strategies. Without actually showing that it is *impossible* to do so
(which you can't because it isn't), claiming you don't find it
convincing doesn't get you very far.
Whether the current code does so or not isn't relevant since I was
responding to your statement that once your criteria are met "not
infinitely recursive is categorically impossible."
I concede that you may be right.
This only requires that the halt decider be made more elaborate, not
that the "impossible input" cannot be correctly decided.
'Must be made more elaborate' isn't worth much unless you can actually
demonstrate that it is *possible* to make them more elaborate to the
extent that they cover all cases. You can't.
It need not cover all cases. It only needs to cover the simplest
instance of the "impossible" case. It does that now. Human inspection of
the code (by honest people that know the x86 language) proves that it
never halts unless H aborts its simulation of this code.
On 2021-09-09 07:34, olcott wrote:
On 9/9/2021 12:16 AM, André G. Isaak wrote:
On 2021-09-08 20:02, olcott wrote:
On 9/8/2021 8:21 PM, André G. Isaak wrote:
On 2021-09-08 16:34, olcott wrote:
On 9/8/2021 5:20 PM, André G. Isaak wrote:
On 2021-09-08 16:00, olcott wrote:
On 9/8/2021 4:27 PM, André G. Isaak wrote:
On 2021-09-08 14:41, olcott wrote:
The key evidence is my code and you can't see my code so you can't
truthfully say what my code does. Even though you can't truthfully say
this you dishonestly say what it does anyway.
I see. The "I have proof but its level 12 scientology and you're only
paid up for level 9" defence.
I'm sure that will go over well with actual journals. "The key evidence
is my code but you're not allowed to see it."
You keep using terms like 'its input' and 'its simulator' where 'its'
rather sloppily refers to the wrong things. You really need to strike
the word 'its' from your vocabulary altogether.
When H(P,P) is invoked none of its recursive invocations has any
effect on the halting behavior of P(P) until after a non-halting
behavior pattern has been matched.
Yet another 'its'.
Until a non-halting behavior pattern has been matched H merely
simulates its input and examines the execution trace of this
simulation. Neither of these things can possibly have any effect on
the behavior of the input.
But your halting pattern doesn't actually work.
I know that no H in the entire recursive invocation chain has any
effect on the behavior of its input until after the outer-most H
makes its halt status decision.
I know that this outer-most H makes its halt status decision on
the basis that the behavior of its input has matched the infinite
recursion behavior pattern.
But your 'infinite recursion behaviour pattern' is flawed. In this
particular instance precisely because of your (d).
Calling something a 'truism' when you haven't been able to
convince even a single person of its truth is hardly warranted.
It might sound plausible, but your sloppy use of the term 'its' >>>>>>>>> destroys that plausibilty.
The only way to prove that the above infinite recursion
detection criteria are correct is to show that there are no >>>>>>>>>> counter-examples of cases that meet the criteria and are not >>>>>>>>>> infinitely recursive.
Once (a)(b)(c)(d) criteria have been met
not infinitely recursive is categorically impossible.
As I said, I can think of numerous ways to write a C program >>>>>>>>> which meets those requirements but which is not infinitely
recursive.
Name at least one. That list has been the subject of numerous
revisions to make it as simple as possible.
I told you that I would, but that I would first give you a week
or so to think about it further. Your approach has always been
"this works for all the cases I considered, therefore it works in >>>>>>> all cases" which is *not* valid logic. You should perhaps think
of more cases. But of course it doesn't matter how many cases you >>>>>>> consider, there will always be cases you haven't considered.
That's why a proof can't simply consist of showing it works in
some cases.
This has been under review for many months.
I am calling your bluff.
Your really that adverse to thinking on something for a week?
Just to give you a few hints, though, your (a)-(c) make no mention
of (among other things) cases where the routine manipulates the
contents of the stack or the stack pointer, or cases where the
routine involves self-modifying code. There's all sorts of creative
ways to meet your criteria without being infinitely recursive using
those.
I am not convinced that this is a counter-example, yet it does seem
reasonably plausible. The current code does not do that so we can
see that the halt decider did decide correctly.
Whether you are convinced or not isn't the issue. Since you claim it
is 'reasonably plausible' you need to actually think it through. I
assure you it is possible to create routines which meet your
'infinite recursion pattern' but which are not infinitely recursive
using these strategies. Without actually showing that it is
*impossible* to do so (which you can't because it isn't), claiming
you don't find it convincing doesn't get you very far.
Whether the current code does so or not isn't relevant since I was
responding to your statement that once your criteria are met "not
infinitely recursive is categorically impossible."
I concede that you may be right.
Which is an acknowledgment that your criteria are not sound.
This only requires that the halt decider be made more elaborate, not
that the "impossible input" cannot be correctly decided.
'Must be made more elaborate' isn't worth much unless you can
actually demonstrate that it is *possible* to make them more
elaborate to the extent that they cover all cases. You can't.
It need not cover all cases. It only needs to cover the simplest
instance of the "impossible" case. It does that now. Human inspection
of the code (by honest people that know the x86 language) proves that
it never halts unless H aborts its simulation of this code.
But your 'argument' for H(P, P)==0 being 'correct' rests on the claim
that your criteria are sound. They are not. It also rests on the
assumption that the actual answer isn't important which is a rather odd position to take.
To get the "impossible" case right, you need H(P, P)==1.
André
On 9/11/21 7:14 PM, olcott wrote:
On 9/11/2021 6:05 PM, Richard Damon wrote:
On 9/11/21 6:53 PM, olcott wrote:
It is a verifiable fact that none of them do until after the halt status >>>> decision is made thus eliminating the otherwise impossible feedback loop >>>> where the input changes its behavior based on the behavior of the halt >>>> decider.
If tempreral order of decision and action matter, decide that you will
live, then put a pistol to your head and pull the trigger. Since you did >>> that action after deciding otherwise it won't have any affect, right?
That is your claim.
The fact that H will at some point make the decision to abort its
simulation and return non-halting, means that it does affect that
machine that it is calling it, and that machine will halt.
That topic is not under discussion.
Why not?
We are only discussing whether or not H can ignore its own behavior when
it examines the execution trace of its input.
Since H DOES abort it simulation and return the non-halting answer to P
and that causes P to halt shows that the H simulating this machihne
can't ignore that behavior.
On 9/12/21 2:00 PM, olcott wrote:SUMMATION
On 9/12/2021 12:51 PM, André G. Isaak wrote:
On 2021-09-12 11:31, olcott wrote:
On 9/12/2021 12:20 PM, André G. Isaak wrote:
On 2021-09-12 11:00, olcott wrote:
On 9/12/2021 10:47 AM, André G. Isaak wrote:You can't demand a yes or no answer if the statement itself is
On 2021-09-12 07:43, olcott wrote:
[I say that H does not have any effect on the behavior of its
input while H remains in pure simulation mode]
Do you agree with the above statement: Yes or No.
Your language is so equivocal that I can't make out whether you >>>>>>>> agree with the above statement or not. We can move on to the next >>>>>>>> half of the same point if you agree with the above statement.
There's nothing remotely equivocal about Richard's language.
The boil it down to a Yes or No:
[I say that H does not have any effect on the behavior of its input >>>>>> while H remains in pure simulation mode]
Do you agree with the above statement: Yes or No.
Any reply besides Yes or No will be construed as a dishonest dodge. >>>>>
ambiguous or poorly defined.
Your statement can be construed as true for certain interpretations
of that statement (one in which the terms used have *consistent*
referents), but it is clear that you are *not* using that
interpretation but another interpretation which is clearly false.
OK then I will define pure simulation mode tautologically.
The simulation mode of a simulating halt decider is defined as the
mode such that the simulating halt decider only acts as a pure
simulator of its input that watches the execution trace of this input
and has no effect on the behavior of its input while it is in
simulation mode.
And how does that fix anything? You're still abusing the referents in
the above. (And btw you really need to come up with a better term than
'mode'. Computations don't have "modes.")
Let's try to lay this out more clearly. You have a halt decider, A,
which takes an input, B. In this example the halt decider A is H and
the input B is P(P). While B is being simulated, it simulates another
computation C with an input D. Once again in this case C equals H and
D equals P(P).
No. Simulating halt decider H which simulates its input P
calls simulating halt decider H which simulates its input P
calls simulating halt decider H which simulates its input P
The key fact that you seem to miss is that each of those things called 'simulating halt decider H' are distinct instances of the execution of
the algorithm of your Halt Decider, and properties that actually refer
to a given instance, apply only to the one that the property applies to.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 427 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:34:54 |
| Calls: | 9,027 |
| Calls today: | 10 |
| Files: | 13,384 |
| Messages: | 6,008,640 |