On Fri, 3 Jun 2022 16:08:34 -0500
olcott <polcott2@gmail.com> wrote:
On 6/2/2022 9:41 PM, Richard Damon wrote:
On 6/2/22 7:45 PM, olcott wrote:void Infinite_Loop()
On 6/2/2022 6:38 PM, Mr Flibble wrote:
On Thu, 2 Jun 2022 15:47:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/2/2022 1:12 PM, Andy Walker wrote:
On 02/06/2022 17:21, Ben wrote:
[...] We know simulation can't be
used to decide halting, and we know that there are only two
ways a decider that tries to do so can be wrong. Both come up >>>>>>>> every time this is taught to a class of programmers. (I've
never taught it to a class of mathematicians but I suspect the >>>>>>>> discussion would be very different.)
My first thought was "no, it's the same", but on
reflexion, and AFAIR, our mathematicians simply accepted what I
told them, which is essentially what
is at
http://www.cuboid.me.uk/anw/G12FCO/lect17.html
[second half, but see esp the last paragraph] and
http://www.cuboid.me.uk/anw/G12FCO/lect18.html
For these cases, we can turn to our second weapon -- emulation.
We want to know whether a program halts, so we try it. If it
halts, then we know the answer. If it doesn't halt, then `it
must be in a loop', so we monitor its state and `detect the
loop'. Sadly, although this is in one sense correct, it is a
false dichotomy. At any given moment as the emulation proceeds,
we are in one of not two but three states: the program has
halted, or it is looping, or it is still running and has not yet
entered a loop. It's the third case that kills us -- we just
have to keep going, and wait for one of the other two things to
happen. The trouble is that it may be that neither of them ever
happens -- which is why `it must be in a loop' was in quotes
above.
It is not considered correctly.
(a) the program has halted
(b) the program is still running
(c) the program matched an infinite behavior pattern
For any program H that might determine if programs halt, a >>>>>> "pathological"
program P, called with some input, can pass its own
source and its input to
H and then specifically do the opposite of what H
predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
Any competent software engineer can verify that H(P,P)==0
for the above behavior pattern. (The entire research scope)
As detailed in my paper:
Halting problem undecidability and infinitely nested simulation
(V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
The proofs you are attempting to refute do not contain the
infinite behaviour pattern you describe;
The correctly simulated input to a simulating halt decider never
reaches the final instruction of this simulated input thus is
unequivocally non-halting.
You keep on saying that, but it isn't actually true for the PROPER
definition of "correct simulation", that being, the simulation of
the input by a UTM equiavlent. (or an x86 processor for your x86
code).
What you want to call "correct simulation" is the partial
simulation by a particular H, but partial simulation are NEVER
"correct" because they are, by definitin=on, INCOMPLETE.
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
In other words you keep saying the same cockamamy bullshit that it is
utterly impossible to correctly determine what a complete simulation
would be from a partial simulation.
This is the exactly same numbskull idea that it is utterly impossible
to determine that a loop is infinite until after waiting forever to
see if it stops running. *Why are you such a jackass?*
Your "infinite loop" only starts if an infinite recursion is detected
however the proofs you are attempting to refute contain no such
infinite recursion so your "infinite loop" is irrelevant.
/Flibble
On Fri, 3 Jun 2022 16:08:34 -0500
olcott <polcott2@gmail.com> wrote:
On 6/2/2022 9:41 PM, Richard Damon wrote:
On 6/2/22 7:45 PM, olcott wrote:void Infinite_Loop()
On 6/2/2022 6:38 PM, Mr Flibble wrote:
On Thu, 2 Jun 2022 15:47:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/2/2022 1:12 PM, Andy Walker wrote:
On 02/06/2022 17:21, Ben wrote:
[...] We know simulation can't be
used to decide halting, and we know that there are only two
ways a decider that tries to do so can be wrong. Both come up >>>>>>>> every time this is taught to a class of programmers. (I've
never taught it to a class of mathematicians but I suspect the >>>>>>>> discussion would be very different.)
My first thought was "no, it's the same", but on
reflexion, and AFAIR, our mathematicians simply accepted what I
told them, which is essentially what
is at
http://www.cuboid.me.uk/anw/G12FCO/lect17.html
[second half, but see esp the last paragraph] and
http://www.cuboid.me.uk/anw/G12FCO/lect18.html
For these cases, we can turn to our second weapon -- emulation.
We want to know whether a program halts, so we try it. If it
halts, then we know the answer. If it doesn't halt, then `it
must be in a loop', so we monitor its state and `detect the
loop'. Sadly, although this is in one sense correct, it is a
false dichotomy. At any given moment as the emulation proceeds,
we are in one of not two but three states: the program has
halted, or it is looping, or it is still running and has not yet
entered a loop. It's the third case that kills us -- we just
have to keep going, and wait for one of the other two things to
happen. The trouble is that it may be that neither of them ever
happens -- which is why `it must be in a loop' was in quotes
above.
It is not considered correctly.
(a) the program has halted
(b) the program is still running
(c) the program matched an infinite behavior pattern
For any program H that might determine if programs halt, a >>>>>> "pathological"
program P, called with some input, can pass its own
source and its input to
H and then specifically do the opposite of what H
predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
Any competent software engineer can verify that H(P,P)==0
for the above behavior pattern. (The entire research scope)
As detailed in my paper:
Halting problem undecidability and infinitely nested simulation
(V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
The proofs you are attempting to refute do not contain the
infinite behaviour pattern you describe;
The correctly simulated input to a simulating halt decider never
reaches the final instruction of this simulated input thus is
unequivocally non-halting.
You keep on saying that, but it isn't actually true for the PROPER
definition of "correct simulation", that being, the simulation of
the input by a UTM equiavlent. (or an x86 processor for your x86
code).
What you want to call "correct simulation" is the partial
simulation by a particular H, but partial simulation are NEVER
"correct" because they are, by definitin=on, INCOMPLETE.
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
In other words you keep saying the same cockamamy bullshit that it is
utterly impossible to correctly determine what a complete simulation
would be from a partial simulation.
This is the exactly same numbskull idea that it is utterly impossible
to determine that a loop is infinite until after waiting forever to
see if it stops running. *Why are you such a jackass?*
Your "infinite loop" only starts if an infinite recursion is detected
however the proofs you are attempting to refute contain no such
infinite recursion so your "infinite loop" is irrelevant.
/Flibble
On 6/3/2022 4:47 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 16:08:34 -0500
olcott <polcott2@gmail.com> wrote:
On 6/2/2022 9:41 PM, Richard Damon wrote:
On 6/2/22 7:45 PM, olcott wrote:void Infinite_Loop()
On 6/2/2022 6:38 PM, Mr Flibble wrote:
On Thu, 2 Jun 2022 15:47:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/2/2022 1:12 PM, Andy Walker wrote:
On 02/06/2022 17:21, Ben wrote:
[...] We know simulation can't be
used to decide halting, and we know that there are only two
ways a decider that tries to do so can be wrong. Both come up >>>>>>>>> every time this is taught to a class of programmers. (I've >>>>>>>>> never taught it to a class of mathematicians but I suspect the >>>>>>>>> discussion would be very different.)
My first thought was "no, it's the same", but on
reflexion, and AFAIR, our mathematicians simply accepted what I >>>>>>>> told them, which is essentially what
is at
http://www.cuboid.me.uk/anw/G12FCO/lect17.html
[second half, but see esp the last paragraph] and
http://www.cuboid.me.uk/anw/G12FCO/lect18.html
For these cases, we can turn to our second weapon -- emulation.
We want to know whether a program halts, so we try it. If it
halts, then we know the answer. If it doesn't halt, then `it
must be in a loop', so we monitor its state and `detect the
loop'. Sadly, although this is in one sense correct, it is a
false dichotomy. At any given moment as the emulation proceeds,
we are in one of not two but three states: the program has
halted, or it is looping, or it is still running and has not yet >>>>>>> entered a loop. It's the third case that kills us -- we just
have to keep going, and wait for one of the other two things to
happen. The trouble is that it may be that neither of them ever
happens -- which is why `it must be in a loop' was in quotes
above.
It is not considered correctly.
(a) the program has halted
(b) the program is still running
(c) the program matched an infinite behavior pattern
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own >>>>>>> source and its input to
H and then specifically do the opposite of what H >>>>>>> predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
Any competent software engineer can verify that H(P,P)==0
for the above behavior pattern. (The entire research scope)
As detailed in my paper:
Halting problem undecidability and infinitely nested simulation
(V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
The proofs you are attempting to refute do not contain the
infinite behaviour pattern you describe;
The correctly simulated input to a simulating halt decider never
reaches the final instruction of this simulated input thus is
unequivocally non-halting.
You keep on saying that, but it isn't actually true for the PROPER
definition of "correct simulation", that being, the simulation of
the input by a UTM equiavlent. (or an x86 processor for your x86
code).
What you want to call "correct simulation" is the partial
simulation by a particular H, but partial simulation are NEVER
"correct" because they are, by definitin=on, INCOMPLETE.
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
In other words you keep saying the same cockamamy bullshit that it is
utterly impossible to correctly determine what a complete simulation
would be from a partial simulation.
This is the exactly same numbskull idea that it is utterly impossible
to determine that a loop is infinite until after waiting forever to
see if it stops running. *Why are you such a jackass?*
Your "infinite loop" only starts if an infinite recursion is detected
however the proofs you are attempting to refute contain no such
infinite recursion so your "infinite loop" is irrelevant.
/Flibble
That you can't comprehend that the full correct x86 emulation of the
input to H(P,P) by H would never stop running shows that your software engineering skills are woefully insufficient to evalulate my work.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Like H0(Infinite_Loop) does not need to perform a complete x86 emulation
of its input to correctly determine the behavior of a complete emulation H(P,P) correctly determines that its input would never halt.
On 6/3/2022 4:47 PM, Mr Flibble wrote:
On Fri, 3 Jun 2022 16:08:34 -0500
olcott <polcott2@gmail.com> wrote:
On 6/2/2022 9:41 PM, Richard Damon wrote:
On 6/2/22 7:45 PM, olcott wrote:void Infinite_Loop()
On 6/2/2022 6:38 PM, Mr Flibble wrote:
On Thu, 2 Jun 2022 15:47:22 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/2/2022 1:12 PM, Andy Walker wrote:
On 02/06/2022 17:21, Ben wrote:
[...] We know simulation can't be
used to decide halting, and we know that there are only two
ways a decider that tries to do so can be wrong. Both come up >>>>>>>>> every time this is taught to a class of programmers. (I've >>>>>>>>> never taught it to a class of mathematicians but I suspect the >>>>>>>>> discussion would be very different.)
My first thought was "no, it's the same", but on
reflexion, and AFAIR, our mathematicians simply accepted what I >>>>>>>> told them, which is essentially what
is at
http://www.cuboid.me.uk/anw/G12FCO/lect17.html
[second half, but see esp the last paragraph] and
http://www.cuboid.me.uk/anw/G12FCO/lect18.html
For these cases, we can turn to our second weapon -- emulation.
We want to know whether a program halts, so we try it. If it
halts, then we know the answer. If it doesn't halt, then `it
must be in a loop', so we monitor its state and `detect the
loop'. Sadly, although this is in one sense correct, it is a
false dichotomy. At any given moment as the emulation proceeds,
we are in one of not two but three states: the program has
halted, or it is looping, or it is still running and has not yet >>>>>>> entered a loop. It's the third case that kills us -- we just
have to keep going, and wait for one of the other two things to
happen. The trouble is that it may be that neither of them ever
happens -- which is why `it must be in a loop' was in quotes
above.
It is not considered correctly.
(a) the program has halted
(b) the program is still running
(c) the program matched an infinite behavior pattern
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own >>>>>>> source and its input to
H and then specifically do the opposite of what H >>>>>>> predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
Any competent software engineer can verify that H(P,P)==0
for the above behavior pattern. (The entire research scope)
As detailed in my paper:
Halting problem undecidability and infinitely nested simulation
(V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
The proofs you are attempting to refute do not contain the
infinite behaviour pattern you describe;
The correctly simulated input to a simulating halt decider never
reaches the final instruction of this simulated input thus is
unequivocally non-halting.
You keep on saying that, but it isn't actually true for the PROPER
definition of "correct simulation", that being, the simulation of
the input by a UTM equiavlent. (or an x86 processor for your x86
code).
What you want to call "correct simulation" is the partial
simulation by a particular H, but partial simulation are NEVER
"correct" because they are, by definitin=on, INCOMPLETE.
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
In other words you keep saying the same cockamamy bullshit that it is
utterly impossible to correctly determine what a complete simulation
would be from a partial simulation.
This is the exactly same numbskull idea that it is utterly impossible
to determine that a loop is infinite until after waiting forever to
see if it stops running. *Why are you such a jackass?*
Your "infinite loop" only starts if an infinite recursion is detected
however the proofs you are attempting to refute contain no such
infinite recursion so your "infinite loop" is irrelevant.
/Flibble
That you can't comprehend that the full correct x86 emulation of the
input to H(P,P) by H would never stop running shows that your software engineering skills are woefully insufficient to evaluate my work.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction, thus never halts.
Like H0(Infinite_Loop) does not need to perform a complete x86 emulation
of its input to correctly determine the behavior of a complete emulation H(P,P) correctly determines that its input would never halt.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 128:22:28 |
| Calls: | 6,663 |
| Calls today: | 1 |
| Files: | 12,212 |
| Messages: | 5,335,189 |