On 1/8/22 10:20 PM, olcott wrote:
On 1/8/2022 8:55 PM, Richard Damon wrote:
On 1/8/22 8:41 PM, olcott wrote:
// Simplified Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{
if (H(x, y))
HERE: goto HERE;
}
H and P are defined according to the standard HP counter-example
template shown above.
H bases its halt status decision on the behavior of the simulation
of its input.
Then P demonstrates an infinitely repeating pattern that cannot
possibly ever reach its final state.
This conclusively proves that the input to H meets the Linz
definition of non-halting:
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
thus the sufficiency condition for H to report that its input
specifies a non-halting computation.
Halting problem undecidability and infinitely nested simulation V2
https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
Full Proof with Request for Rebuttal
We have gone around the circle of this MANY times, and you keep just
rearranging things and not every answering the refutation.
The problem is that you are simply too stupid to ever understand that
P specifies a sequence of configurations that never reach its final
state and thus is correctly determined to be a non-halting computation
according to Linz.
And you are too stupid to see that it doesn't if H(P,P) returns 0, as
this just proved.
Your failure to point out an error will be taken as an admission that
you accept that your logic is incorrect.
FAIR WARNING.
Malcolm, Kaz and Flibble are not too stupid to understand this.
Ben, André and Mike are not interested in understanding what I say
they are only interested in finding some basis for rebuttal. If there
is at least one minor point that I have not proven completely they
count everything that I say as incorrect on the basis of this minor
point.
On 1/9/22 12:57 PM, olcott wrote:
On 1/9/2022 11:43 AM, Richard Damon wrote:
On 1/9/22 11:40 AM, olcott wrote:
On 1/8/2022 9:59 PM, Richard Damon wrote:
On 1/8/22 10:20 PM, olcott wrote:
On 1/8/2022 8:55 PM, Richard Damon wrote:
On 1/8/22 8:41 PM, olcott wrote:
// Simplified Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{
if (H(x, y))
HERE: goto HERE;
}
H and P are defined according to the standard HP counter-example >>>>>>>> template shown above.
H bases its halt status decision on the behavior of the
simulation of its input.
Then P demonstrates an infinitely repeating pattern that cannot >>>>>>>> possibly ever reach its final state.
This conclusively proves that the input to H meets the Linz
definition of non-halting:
computation that halts … the Turing machine will halt whenever >>>>>>>> it enters a final state. (Linz:1990:234)
thus the sufficiency condition for H to report that its input
specifies a non-halting computation.
Halting problem undecidability and infinitely nested simulation V2 >>>>>>>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
Full Proof with Request for Rebuttal
We have gone around the circle of this MANY times, and you keep
just rearranging things and not every answering the refutation.
The problem is that you are simply too stupid to ever understand
that P specifies a sequence of configurations that never reach its >>>>>> final state and thus is correctly determined to be a non-halting
computation according to Linz.
And you are too stupid to see that it doesn't if H(P,P) returns 0,
as this just proved.
It is always correct for H to report on what the behavior of its
input would be if H did not interfere with the behavior of this input. >>>> H is an objective observer.
It is never correct for H to report on what the behavior of its
input would be if H did interfere with the behavior of this input.
H is not an objective observer.
IMPROPERLY PHRASED, H must report on what the machine that its input
represents will do, even if that includes a copy of itself. That is
not H 'interfering' with the behavior of that machine.
It is Impossible for the copy of a decider doing the deciding to
'interfere' with the behavior of a machine, as that behavior is
defined independent of the decider.
Yes, the aborting of a simulation by the copy of the decider doing
the deciding doesn't affect the behavior of the machine it is
deciding on, a copy of it IN the machine it is trying to decide on,
DOES, as it IS part of the machine it is deciding on.
FAIL.
The fact that you can't keep the different copies of H separate shows
your lack of reasoning ability.
When H reports on what the behavior of its simulated input would be if
H did not interfere, it is the same for P, infinite loops, or infinite
recursion, H must only reject its input as non-halting.
Except it isn't 'interference' for the copy of H in the input to do what
it is programmed to do.
In fact, it is interference for the H that is deciding to NOT let the
copy of H inside P to do that that H is programmed to do.
DEFINITIONS, you know, The correct answer for H(<X>, y) is basd on what
X(y) would do when run.
The behavior of 'the input' is what that program would do when run
'without outside interference', that means that copy of H inside P does
what it will do.
Since H(P,P) returns 0, ALL Copies of H(P,P) return 0, so the copy
inside P does thins, and P(P) will Halt.
FAIL.
This has been PROVEN and no actual rebuttal provided, so you have
conceded the point.
Your failure to point out an error will be taken as an admission
that you accept that your logic is incorrect.
FAIR WARNING.
Malcolm, Kaz and Flibble are not too stupid to understand this.
Ben, André and Mike are not interested in understanding what I say >>>>>> they are only interested in finding some basis for rebuttal. If
there is at least one minor point that I have not proven
completely they count everything that I say as incorrect on the
basis of this minor point.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 365 |
Nodes: | 16 (2 / 14) |
Uptime: | 25:10:56 |
Calls: | 7,769 |
Files: | 12,905 |
Messages: | 5,749,274 |