On 2022-02-25 09:11, olcott wrote:
On 2/25/2022 9:45 AM, Richard Damon wrote:
On 2/25/22 10:26 AM, olcott wrote:
THIS IS ALWAYS EXACTLY THE SAME
Simulating halt deciders continue to simulate their input until they
determine that this simulated input would never reach its final state.
But how do they determine that?
The fact that humans can see that in both cases the simulated input
never reaches its final state in any finite number of simulated steps
conclusively proves that it is possible to correctly detect the
infinite loop and the infinitely nested simulation.
What humans can do provides no evidence at all about what algorithms can
do. Humans are not algorithms. (and what humans can do with information
x, y, and z tells us even left about what an algorithm can do with only
x and y).
If you want to claim it is possible for an algorithm to recognize
infinitely recursive simulation, you need to actually show how that
algorithm works.
How does embedded_H determine whether its input leads to recursion or
not? IOW, how does it recognize whether the input string includes a copy
of itself?
André
On 2022-03-02 09:05, olcott wrote:
On 2/25/2022 11:17 AM, André G. Isaak wrote:
On 2022-02-25 09:11, olcott wrote:
On 2/25/2022 9:45 AM, Richard Damon wrote:
On 2/25/22 10:26 AM, olcott wrote:
THIS IS ALWAYS EXACTLY THE SAME
Simulating halt deciders continue to simulate their input until
they determine that this simulated input would never reach its
final state.
But how do they determine that?
The fact that humans can see that in both cases the simulated input
never reaches its final state in any finite number of simulated
steps conclusively proves that it is possible to correctly detect
the infinite loop and the infinitely nested simulation.
What humans can do provides no evidence at all about what algorithms
can do. Humans are not algorithms. (and what humans can do with
information x, y, and z tells us even left about what an algorithm
can do with only x and y).
If you want to claim it is possible for an algorithm to recognize
infinitely recursive simulation, you need to actually show how that
algorithm works.
How does embedded_H determine whether its input leads to recursion or
not? IOW, how does it recognize whether the input string includes a
copy of itself?
André
It would have to have some reference to its own machine description.
But TMs do NOT have access to their own machine description. They have
access only to what is placed on the tape as their input.
In the C/x86 version of these things the machine and its description
are one-and-the-same thing. The currently executing halt decider can
derive its own machine address. It can use this address for a string
comparison.
And your C 'solution' is a cheat. Even if it did get the right answer
(it doesn't) it isn't following the Linz proof nor does it implement the correct structure for a halt decider.
A halt decider is a COMPLETE and INDEPENDENT program which takes as its
input a description of a COMPLETE and INDEPENDENT program which it then evaluates. If your P calls your H then your P is NOT a complete and independent program.
Both P and H *must* be able to run independently in absence of the
other. That means P must contain its own private copy of any code from H which it makes use of. Which means the embedded H inside P will *not*
have the same address as H.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
iff Ĥ applied to ⟨Ĥ⟩ halts.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
iff Ĥ applied to ⟨Ĥ⟩ does not halt.
If you omit these conditions then what you write is meaningless.
If embedded_H can compare the machine description of itself and its
inputs
Which it cannot do since it is not given a description of itself as an
input.
Also, while every TM description maps to a unique TM, there is no unique description for any TM. Each TM has infinitely many possible
descriptions so just comparing two strings wouldn't cut it.
André
to its simulated call of a copy of this machine description at Ĥ.qx
then it can correctly reject ⟨Ĥ⟩ ⟨Ĥ⟩ as specifying infinitely nested
simulation. It can do this the first time that the simulated
embedded_H is called.
On 3/2/22 11:57 AM, olcott wrote:The key thing that it means is that the halt decider is necessarily
On 3/2/2022 10:21 AM, André G. Isaak wrote:
On 2022-03-02 09:05, olcott wrote:
On 2/25/2022 11:17 AM, André G. Isaak wrote:
On 2022-02-25 09:11, olcott wrote:
On 2/25/2022 9:45 AM, Richard Damon wrote:
On 2/25/22 10:26 AM, olcott wrote:
THIS IS ALWAYS EXACTLY THE SAME
Simulating halt deciders continue to simulate their input until >>>>>>>> they determine that this simulated input would never reach its >>>>>>>> final state.
But how do they determine that?
The fact that humans can see that in both cases the simulated
input never reaches its final state in any finite number of
simulated steps conclusively proves that it is possible to
correctly detect the infinite loop and the infinitely nested
simulation.
What humans can do provides no evidence at all about what
algorithms can do. Humans are not algorithms. (and what humans can
do with information x, y, and z tells us even left about what an
algorithm can do with only x and y).
If you want to claim it is possible for an algorithm to recognize
infinitely recursive simulation, you need to actually show how that
algorithm works.
How does embedded_H determine whether its input leads to recursion
or not? IOW, how does it recognize whether the input string
includes a copy of itself?
André
It would have to have some reference to its own machine description.
But TMs do NOT have access to their own machine description. They
have access only to what is placed on the tape as their input.
So we switch to RASP machines.
In the C/x86 version of these things the machine and its description
are one-and-the-same thing. The currently executing halt decider can
derive its own machine address. It can use this address for a string
comparison.
And your C 'solution' is a cheat. Even if it did get the right answer
(it doesn't) it isn't following the Linz proof nor does it implement
the correct structure for a halt decider.
YOU KNOW THIS IS TRUE:
It is a fact that in both the C/x86 H/P and the Linz embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
that the simulating halt decider must abort the simulation of its
input or this simulation would never stop running.
Yes, that means that if H is Hn that doesn't abort
On 3/2/22 8:24 PM, olcott wrote:
On 3/2/2022 7:11 PM, Richard Damon wrote:
On 3/2/22 11:57 AM, olcott wrote:The key thing that it means is that the halt decider is necessarily
On 3/2/2022 10:21 AM, André G. Isaak wrote:
On 2022-03-02 09:05, olcott wrote:
On 2/25/2022 11:17 AM, André G. Isaak wrote:But TMs do NOT have access to their own machine description. They
On 2022-02-25 09:11, olcott wrote:
On 2/25/2022 9:45 AM, Richard Damon wrote:
On 2/25/22 10:26 AM, olcott wrote:
THIS IS ALWAYS EXACTLY THE SAME
Simulating halt deciders continue to simulate their input
until they determine that this simulated input would never >>>>>>>>>> reach its final state.
But how do they determine that?
The fact that humans can see that in both cases the simulated
input never reaches its final state in any finite number of
simulated steps conclusively proves that it is possible to
correctly detect the infinite loop and the infinitely nested
simulation.
What humans can do provides no evidence at all about what
algorithms can do. Humans are not algorithms. (and what humans
can do with information x, y, and z tells us even left about what >>>>>>> an algorithm can do with only x and y).
If you want to claim it is possible for an algorithm to recognize >>>>>>> infinitely recursive simulation, you need to actually show how
that algorithm works.
How does embedded_H determine whether its input leads to
recursion or not? IOW, how does it recognize whether the input
string includes a copy of itself?
André
It would have to have some reference to its own machine description. >>>>>
have access only to what is placed on the tape as their input.
So we switch to RASP machines.
In the C/x86 version of these things the machine and its
description are one-and-the-same thing. The currently executing
halt decider can derive its own machine address. It can use this
address for a string comparison.
And your C 'solution' is a cheat. Even if it did get the right
answer (it doesn't) it isn't following the Linz proof nor does it
implement the correct structure for a halt decider.
YOU KNOW THIS IS TRUE:
It is a fact that in both the C/x86 H/P and the Linz embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
that the simulating halt decider must abort the simulation of its
input or this simulation would never stop running.
Yes, that means that if H is Hn that doesn't abort
correct when it rejects its input.
So a Halt Decider that rejects everything is correct that NO
computations halt?
On 3/2/22 9:28 PM, olcott wrote:
On 3/2/2022 8:16 PM, Richard Damon wrote:
On 3/2/22 8:24 PM, olcott wrote:
On 3/2/2022 7:11 PM, Richard Damon wrote:
On 3/2/22 11:57 AM, olcott wrote:The key thing that it means is that the halt decider is necessarily
On 3/2/2022 10:21 AM, André G. Isaak wrote:
On 2022-03-02 09:05, olcott wrote:
On 2/25/2022 11:17 AM, André G. Isaak wrote:
On 2022-02-25 09:11, olcott wrote:
On 2/25/2022 9:45 AM, Richard Damon wrote:
On 2/25/22 10:26 AM, olcott wrote:
THIS IS ALWAYS EXACTLY THE SAME
Simulating halt deciders continue to simulate their input >>>>>>>>>>>> until they determine that this simulated input would never >>>>>>>>>>>> reach its final state.
But how do they determine that?
The fact that humans can see that in both cases the simulated >>>>>>>>>> input never reaches its final state in any finite number of >>>>>>>>>> simulated steps conclusively proves that it is possible to >>>>>>>>>> correctly detect the infinite loop and the infinitely nested >>>>>>>>>> simulation.
What humans can do provides no evidence at all about what
algorithms can do. Humans are not algorithms. (and what humans >>>>>>>>> can do with information x, y, and z tells us even left about >>>>>>>>> what an algorithm can do with only x and y).
If you want to claim it is possible for an algorithm to
recognize infinitely recursive simulation, you need to actually >>>>>>>>> show how that algorithm works.
How does embedded_H determine whether its input leads to
recursion or not? IOW, how does it recognize whether the input >>>>>>>>> string includes a copy of itself?
André
It would have to have some reference to its own machine
description.
But TMs do NOT have access to their own machine description. They >>>>>>> have access only to what is placed on the tape as their input.
So we switch to RASP machines.
In the C/x86 version of these things the machine and its
description are one-and-the-same thing. The currently executing >>>>>>>> halt decider can derive its own machine address. It can use this >>>>>>>> address for a string comparison.
And your C 'solution' is a cheat. Even if it did get the right
answer (it doesn't) it isn't following the Linz proof nor does it >>>>>>> implement the correct structure for a halt decider.
YOU KNOW THIS IS TRUE:
It is a fact that in both the C/x86 H/P and the Linz embedded_H
⟨Ĥ⟩ ⟨Ĥ⟩
that the simulating halt decider must abort the simulation of its
input or this simulation would never stop running.
Yes, that means that if H is Hn that doesn't abort
correct when it rejects its input.
So a Halt Decider that rejects everything is correct that NO
computations halt?
The fact that H(P,P) and embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ both must abort the
simulation of their input conclusively proves they are correct in
rejecting this input. NITWIT
NOPE. Source for that?
Yes, you can show that Hn^ applied to <Hn^> is non-halting if it is
built on the Hn that doesn't abort, but when you change you H to be the
Ha that does abort, you haven't proved that Ha^ applied to <Ha^> doesn't halt, only that Ha would be correct if it was applied to <Hn^> <Hn^> but
that isn't the Linz computaiton.
You make the error of conflating your two machines, because you have a
fabled machine that is two different machines at once, your Fairy Dust Powered Unicorn.
H must be EITHER Hn that doens't abort or the Ha that does, it doesn't magically change in the middle of the problem from one to the other.
FAIL.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 112:09:40 |
| Calls: | 6,662 |
| Files: | 12,209 |
| Messages: | 5,336,029 |