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.
On 6/2/2022 9:41 PM, Richard Damon wrote:
On 6/2/22 7:45 PM, olcott wrote:
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 partialvoid Infinite_Loop()
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?*
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?*
On 6/3/22 5:08 PM, olcott wrote:BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
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?*
No, that isn't what I said.
I said that H can not generate a correct simulation of that input,
because it will generate only a partial simulation of it, and that by definition is NOT correct.
On 6/3/2022 5:31 PM, Richard Damon wrote:
On 6/3/22 5:08 PM, olcott wrote:BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
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?*
No, that isn't what I said.
I said that H can not generate a correct simulation of that input,
because it will generate only a partial simulation of it, and that by
definition is NOT correct.
PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?
BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?
BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?
void Infinite_Loop()
{
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]
It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret" instruction).
Equally obvious is the fact that a partial x86 emulation of this input conclusively proves that its complete x86 emulation would never halt.
Begin Local Halt Decider Simulation Execution Trace Stored at:212343 [00001342][00212333][00212337] 55 push ebp [00001343][00212333][00212337] 8bec mov ebp,esp [00001345][00212333][00212337] ebfe jmp 00001345 [00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
The exact same reasoning applies to the correctly emulated input to H(P,P):
_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.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 108:38:34 |
| Calls: | 6,662 |
| Calls today: | 4 |
| Files: | 12,209 |
| Messages: | 5,335,607 |