Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #36857 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2021-07-22 10:51 -0500 |
| Last post | 2021-07-23 09:48 -0700 |
| Articles | 20 on this page of 88 — 7 participants |
Back to article view | Back to comp.theory
How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 10:51 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 11:15 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 10:38 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-22 10:34 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 13:16 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 11:39 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 00:11 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 23:14 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-22 19:30 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 14:17 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 12:42 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 00:04 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 18:25 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 00:48 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 08:53 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 08:50 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 11:00 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 09:31 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 12:13 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 11:31 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 13:42 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 11:56 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 14:07 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 12:23 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 15:38 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 13:53 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 15:56 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 14:25 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 17:49 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-24 03:56 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Andy Walker <anw@cuboid.co.uk> - 2021-07-24 12:40 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-24 04:52 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 08:55 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Andy Walker <anw@cuboid.co.uk> - 2021-07-24 16:44 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 10:54 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:08 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 08:50 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:16 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-24 10:31 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [ pure simulator ] olcott <NoOne@NoWhere.com> - 2021-07-24 09:34 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ pure simulator ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:25 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 17:42 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 19:26 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 19:02 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 20:32 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 18:42 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 20:50 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 19:28 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 23:38 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 23:17 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar? ] olcott <NoOne@NoWhere.com> - 2021-07-24 09:05 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:31 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 12:23 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 11:34 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 13:42 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] André G. Isaak <agisaak@gm.invalid> - 2021-07-24 13:07 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 14:22 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 12:38 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 15:01 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 13:14 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 04:07 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 21:02 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 21:33 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? [ Internals of H ] olcott <NoOne@NoWhere.com> - 2021-07-26 10:08 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 12:21 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 14:24 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 12:44 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 15:03 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 13:19 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] André G. Isaak <agisaak@gm.invalid> - 2021-07-24 16:10 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 17:31 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] André G. Isaak <agisaak@gm.invalid> - 2021-07-24 16:46 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 19:44 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] olcott <NoOne@NoWhere.com> - 2021-07-24 09:23 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:33 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] olcott <NoOne@NoWhere.com> - 2021-07-24 12:41 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 11:39 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 18:00 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 22:12 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 16:49 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 15:26 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 04:07 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-22 13:11 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 17:18 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 15:46 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-22 17:08 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 09:35 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 09:48 -0700
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 10:51 -0500 |
| Subject | How is H(P,P)==0 correct even though P(P) stops running? |
| Message-ID | <prednSOZ5uphDmT9nZ2dnUU7-bvNnZ2d@giganews.com> |
How is H(P,P)==0 correct even though P(P) stops running?
(a) The reason that P of int main(){ P(P); } it is construed as halting
is that it reaches its final state.
(b) The reason that it reaches its final state is that H(P,P) returns zero.
(c) The reason that H(P,P) returns zero is that the correct pure
simulation of its input can't possibly reach its final state.
(d) When the pure simulation of an input can't possibly ever reach its
final state then this input never halts.
∴ The only reason that P of int main(){ P(P); } halts is because H(P,P)
correctly decided that its input never halts.
We can easily verify that the simulation of P(P) is correct by comparing
the execution trace of this simulation to the x86 source-code of P shown
below.
(c) is proved in that when P calls H and H acts as a pure simulator of
P(P) it is very obvious that P(P) is stuck in infinitely nested
simulation when we examine the execution trace of the simulation of P(P)
shown below:
// Strachey(1965) "An impossible program"
// CPL translated to C
// https://doi.org/10.1093/comjnl/7.4.313
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
P((u32)P);
}
_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]
_main()
[00000c45](01) 55 push ebp
[00000c46](02) 8bec mov ebp,esp
[00000c48](05) 68250c0000 push 00000c25 // push P
[00000c4d](05) e8d3ffffff call 00000c25 // call P
[00000c52](03) 83c404 add esp,+04
[00000c55](02) 33c0 xor eax,eax
[00000c57](01) 5d pop ebp
[00000c58](01) c3 ret
Size in bytes:(0020) [00000c58]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c45][001016d6][00000000] 55 push ebp
[00000c46][001016d6][00000000] 8bec mov ebp,esp
[00000c48][001016d2][00000c25] 68250c0000 push 00000c25 // push P
[00000c4d][001016ce][00000c52] e8d3ffffff call 00000c25 // call P0
[00000c25][001016ca][001016d6] 55 push ebp // P0 begins
[00000c26][001016ca][001016d6] 8bec mov ebp,esp
[00000c28][001016ca][001016d6] 8b4508 mov eax,[ebp+08]
[00000c2b][001016c6][00000c25] 50 push eax // push P
[00000c2c][001016c6][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][001016c2][00000c25] 51 push ecx // push P
[00000c30][001016be][00000c35] e820fdffff call 00000955 // call H0
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P1 begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1
[00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
In the above computation (zero based addressing) H0 aborts P1.
[00000c35][001016ca][001016d6] 83c408 add esp,+08
[00000c38][001016ca][001016d6] 85c0 test eax,eax
[00000c3a][001016ca][001016d6] 7402 jz 00000c3e
[00000c3e][001016ce][00000c52] 5d pop ebp
[00000c3f][001016d2][00000c25] c3 ret
[00000c52][001016d6][00000000] 83c404 add esp,+04
[00000c55][001016d6][00000000] 33c0 xor eax,eax
[00000c57][001016da][00100000] 5d pop ebp
[00000c58][001016de][00000084] c3 ret
Number_of_User_Instructions(34)
Number of Instructions Executed(23729)
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 11:15 -0500 |
| Message-ID | <VJidnWCiJf8RBGT9nZ2dnUU7-d-dnZ2d@giganews.com> |
| In reply to | #36857 |
On 7/22/2021 10:51 AM, olcott wrote:
> How is H(P,P)==0 correct even though P(P) stops running?
>
> (a) The reason that P of int main(){ P(P); } it is construed as halting
> is that it reaches its final state.
>
> (b) The reason that it reaches its final state is that H(P,P) returns zero.
>
> (c) The reason that H(P,P) returns zero is that the correct pure
> simulation of its input can't possibly reach its final state.
>
We can easily verify that the pure simulation of the input to
H(P,P) is correct when we verify that the execution trace of
the simulation of P(P) precisely corresponds to the x86
source-code of P.
We can easily verify that the pure simulation of the input to
H(P,P) never reaches the final state of P by examining the
execution trace of the simulation of P(P) under the assumption
that the call to H at machine address 0x955 is a call to a pure
x86 emulator.
We can know that this assumption is valid because we know that H
is computationally equivalent to a pure simulator of its input
until after it makes its halt status decision.
> (d) When the pure simulation of an input can't possibly ever reach its
> final state then this input never halts.
>
> ∴ The only reason that P of int main(){ P(P); } halts is because H(P,P)
> correctly decided that its input never halts.
>
> We can easily verify that the simulation of P(P) is correct by comparing
> the execution trace of this simulation to the x86 source-code of P shown
> below.
>
> (c) is proved in that when P calls H and H acts as a pure simulator of
> P(P) it is very obvious that P(P) is stuck in infinitely nested
> simulation when we examine the execution trace of the simulation of P(P)
> shown below:
>
> // Strachey(1965) "An impossible program"
> // CPL translated to C
> // https://doi.org/10.1093/comjnl/7.4.313
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> int main()
> {
> P((u32)P);
> }
>
> _P()
> [00000c25](01) 55 push ebp
> [00000c26](02) 8bec mov ebp,esp
> [00000c28](03) 8b4508 mov eax,[ebp+08]
> [00000c2b](01) 50 push eax // 2nd Param
> [00000c2c](03) 8b4d08 mov ecx,[ebp+08]
> [00000c2f](01) 51 push ecx // 1st Param
> [00000c30](05) e820fdffff call 00000955 // call H
> [00000c35](03) 83c408 add esp,+08
> [00000c38](02) 85c0 test eax,eax
> [00000c3a](02) 7402 jz 00000c3e
> [00000c3c](02) ebfe jmp 00000c3c
> [00000c3e](01) 5d pop ebp
> [00000c3f](01) c3 ret
> Size in bytes:(0027) [00000c3f]
>
> _main()
> [00000c45](01) 55 push ebp
> [00000c46](02) 8bec mov ebp,esp
> [00000c48](05) 68250c0000 push 00000c25 // push P
> [00000c4d](05) e8d3ffffff call 00000c25 // call P
> [00000c52](03) 83c404 add esp,+04
> [00000c55](02) 33c0 xor eax,eax
> [00000c57](01) 5d pop ebp
> [00000c58](01) c3 ret
> Size in bytes:(0020) [00000c58]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00000c45][001016d6][00000000] 55 push ebp
> [00000c46][001016d6][00000000] 8bec mov ebp,esp
> [00000c48][001016d2][00000c25] 68250c0000 push 00000c25 // push P
> [00000c4d][001016ce][00000c52] e8d3ffffff call 00000c25 // call P0
> [00000c25][001016ca][001016d6] 55 push ebp // P0 begins
> [00000c26][001016ca][001016d6] 8bec mov ebp,esp
> [00000c28][001016ca][001016d6] 8b4508 mov eax,[ebp+08]
> [00000c2b][001016c6][00000c25] 50 push eax // push P
> [00000c2c][001016c6][00000c25] 8b4d08 mov ecx,[ebp+08]
> [00000c2f][001016c2][00000c25] 51 push ecx // push P
> [00000c30][001016be][00000c35] e820fdffff call 00000955 // call H0
>
> Begin Local Halt Decider Simulation at Machine Address:c25
> [00000c25][00211776][0021177a] 55 push ebp // P1 begins
> [00000c26][00211776][0021177a] 8bec mov ebp,esp
> [00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
> [00000c2b][00211772][00000c25] 50 push eax // push P
> [00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
> [00000c2f][0021176e][00000c25] 51 push ecx // push P
> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1
> [00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
> [00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
> [00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
> [00000c2b][0025c19a][00000c25] 50 push eax // push P
> [00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
> [00000c2f][0025c196][00000c25] 51 push ecx // push P
> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> In the above computation (zero based addressing) H0 aborts P1.
>
> [00000c35][001016ca][001016d6] 83c408 add esp,+08
> [00000c38][001016ca][001016d6] 85c0 test eax,eax
> [00000c3a][001016ca][001016d6] 7402 jz 00000c3e
> [00000c3e][001016ce][00000c52] 5d pop ebp
> [00000c3f][001016d2][00000c25] c3 ret
> [00000c52][001016d6][00000000] 83c404 add esp,+04
> [00000c55][001016d6][00000000] 33c0 xor eax,eax
> [00000c57][001016da][00100000] 5d pop ebp
> [00000c58][001016de][00000084] c3 ret
> Number_of_User_Instructions(34)
> Number of Instructions Executed(23729)
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-22 10:38 -0700 |
| Message-ID | <b2iKI.22498$uj5.8074@fx03.iad> |
| In reply to | #36859 |
On 7/22/21 9:15 AM, olcott wrote:
> On 7/22/2021 10:51 AM, olcott wrote:
>> How is H(P,P)==0 correct even though P(P) stops running?
>>
>> (a) The reason that P of int main(){ P(P); } it is construed as
>> halting is that it reaches its final state.
>>
>> (b) The reason that it reaches its final state is that H(P,P) returns
>> zero.
>>
>> (c) The reason that H(P,P) returns zero is that the correct pure
>> simulation of its input can't possibly reach its final state.
>>
>
> We can easily verify that the pure simulation of the input to
> H(P,P) is correct when we verify that the execution trace of
> the simulation of P(P) precisely corresponds to the x86
> source-code of P.
>
You mean the trace that makes the logical error of replacing the trace
of a simulation that isn't unconditional with the trace of the simulation.
That operation is ONLY valid if the simulator NEVER stops its simulation.
UNSOUND LOGIC.
> We can easily verify that the pure simulation of the input to
> H(P,P) never reaches the final state of P by examining the
> execution trace of the simulation of P(P) under the assumption
> that the call to H at machine address 0x955 is a call to a pure
> x86 emulator.
Right, if you make a FALSE assumption, then you get an UNSOUND results.
If you assume that H is a pure simulator, but it isn't, then you are
using unsound logic.
>
> We can know that this assumption is valid because we know that H
> is computationally equivalent to a pure simulator of its input
> until after it makes its halt status decision.
But then it isn't. Computation are complete units, from start to end,
the fact that it works one way for a while and then an other doesn't
mean you can just assume that it is the first class.
H is NOT a 'pure simulator' so you can't treat it as one.
It you wanted to try oto use that logic, H would have to simulate the H
that it is simulating until THAT simulated H reached its decision, which
you don't.
>
>
>> (d) When the pure simulation of an input can't possibly ever reach its
>> final state then this input never halts.
But you have posted a trace of the 'pure simulation' of P(P) showing
that it does come to a halt after the H that it calls aborts its
simulation and returns the non-halting answer.
Note, your arguement MEANS running a simulation of P(P), NOT as you make
in your argument changing H to be a pure simulation, which changes P and
gives you an H that never returns an answer for H(P,P)
>>
>> ∴ The only reason that P of int main(){ P(P); } halts is because
>> H(P,P) correctly decided that its input never halts.
>>
>> We can easily verify that the simulation of P(P) is correct by
>> comparing the execution trace of this simulation to the x86
>> source-code of P shown below.
>>
>> (c) is proved in that when P calls H and H acts as a pure simulator of
>> P(P) it is very obvious that P(P) is stuck in infinitely nested
>> simulation when we examine the execution trace of the simulation of
>> P(P) shown below:
>>
>> // Strachey(1965) "An impossible program"
>> // CPL translated to C
>> // https://doi.org/10.1093/comjnl/7.4.313
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>> _P()
>> [00000c25](01) 55 push ebp
>> [00000c26](02) 8bec mov ebp,esp
>> [00000c28](03) 8b4508 mov eax,[ebp+08]
>> [00000c2b](01) 50 push eax // 2nd Param
>> [00000c2c](03) 8b4d08 mov ecx,[ebp+08]
>> [00000c2f](01) 51 push ecx // 1st Param
>> [00000c30](05) e820fdffff call 00000955 // call H
>> [00000c35](03) 83c408 add esp,+08
>> [00000c38](02) 85c0 test eax,eax
>> [00000c3a](02) 7402 jz 00000c3e
>> [00000c3c](02) ebfe jmp 00000c3c
>> [00000c3e](01) 5d pop ebp
>> [00000c3f](01) c3 ret
>> Size in bytes:(0027) [00000c3f]
>>
>> _main()
>> [00000c45](01) 55 push ebp
>> [00000c46](02) 8bec mov ebp,esp
>> [00000c48](05) 68250c0000 push 00000c25 // push P
>> [00000c4d](05) e8d3ffffff call 00000c25 // call P
>> [00000c52](03) 83c404 add esp,+04
>> [00000c55](02) 33c0 xor eax,eax
>> [00000c57](01) 5d pop ebp
>> [00000c58](01) c3 ret
>> Size in bytes:(0020) [00000c58]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [00000c45][001016d6][00000000] 55 push ebp
>> [00000c46][001016d6][00000000] 8bec mov ebp,esp
>> [00000c48][001016d2][00000c25] 68250c0000 push 00000c25 // push P
>> [00000c4d][001016ce][00000c52] e8d3ffffff call 00000c25 // call P0
>> [00000c25][001016ca][001016d6] 55 push ebp // P0 begins
>> [00000c26][001016ca][001016d6] 8bec mov ebp,esp
>> [00000c28][001016ca][001016d6] 8b4508 mov eax,[ebp+08]
>> [00000c2b][001016c6][00000c25] 50 push eax // push P
>> [00000c2c][001016c6][00000c25] 8b4d08 mov ecx,[ebp+08]
>> [00000c2f][001016c2][00000c25] 51 push ecx // push P
>> [00000c30][001016be][00000c35] e820fdffff call 00000955 // call H0
>>
>> Begin Local Halt Decider Simulation at Machine Address:c25
>> [00000c25][00211776][0021177a] 55 push ebp // P1 begins
>> [00000c26][00211776][0021177a] 8bec mov ebp,esp
>> [00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
>> [00000c2b][00211772][00000c25] 50 push eax // push P
>> [00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
>> [00000c2f][0021176e][00000c25] 51 push ecx // push P
>> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1
>> [00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
>> [00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
>> [00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
>> [00000c2b][0025c19a][00000c25] 50 push eax // push P
>> [00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
>> [00000c2f][0025c196][00000c25] 51 push ecx // push P
>> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> In the above computation (zero based addressing) H0 aborts P1.
>>
>> [00000c35][001016ca][001016d6] 83c408 add esp,+08
>> [00000c38][001016ca][001016d6] 85c0 test eax,eax
>> [00000c3a][001016ca][001016d6] 7402 jz 00000c3e
>> [00000c3e][001016ce][00000c52] 5d pop ebp
>> [00000c3f][001016d2][00000c25] c3 ret
>> [00000c52][001016d6][00000000] 83c404 add esp,+04
>> [00000c55][001016d6][00000000] 33c0 xor eax,eax
>> [00000c57][001016da][00100000] 5d pop ebp
>> [00000c58][001016de][00000084] c3 ret
>> Number_of_User_Instructions(34)
>> Number of Instructions Executed(23729)
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-07-22 10:34 -0700 |
| Message-ID | <60bd26a4-844f-4fb4-8fd3-dfbc9089e0d4n@googlegroups.com> |
| In reply to | #36857 |
On Thursday, 22 July 2021 at 16:51:31 UTC+1, olcott wrote:
> How is H(P,P)==0 correct even though P(P) stops running?
>
> (a) The reason that P of int main(){ P(P); } it is construed as halting
> is that it reaches its final state.
>
> (b) The reason that it reaches its final state is that H(P,P) returns zero.
>
> (c) The reason that H(P,P) returns zero is that the correct pure
> simulation of its input can't possibly reach its final state.
>
> (d) When the pure simulation of an input can't possibly ever reach its
> final state then this input never halts.
>
> ∴ The only reason that P of int main(){ P(P); } halts is because H(P,P)
> correctly decided that its input never halts.
>
> We can easily verify that the simulation of P(P) is correct by comparing
> the execution trace of this simulation to the x86 source-code of P shown
> below.
>
> (c) is proved in that when P calls H and H acts as a pure simulator of
> P(P) it is very obvious that P(P) is stuck in infinitely nested
> simulation when we examine the execution trace of the simulation of P(P)
> shown below:
>
You've constructed your own paradox which has nothing to do with the
"invert" logic of the Linz proof.
If H is a simulating halt decider, and it is called on a version of itself, it
either detects that this will go on forever, or it doesn't. If it doesn't detect
that this will go on forever, there is nothing to stop the endless spawning
of "H" contexts, and the program never halts. So H has it wrong. However if
H detects the situation and terminates, the the program comes to a halt,
and H was also wrong.
There might be something useful here.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 13:16 -0500 |
| Message-ID | <y5ednWl_soN0KGT9nZ2dnUU7-YPNnZ2d@giganews.com> |
| In reply to | #36870 |
On 7/22/2021 12:34 PM, Malcolm McLean wrote:
> On Thursday, 22 July 2021 at 16:51:31 UTC+1, olcott wrote:
>> How is H(P,P)==0 correct even though P(P) stops running?
>>
>> (a) The reason that P of int main(){ P(P); } it is construed as halting
>> is that it reaches its final state.
>>
>> (b) The reason that it reaches its final state is that H(P,P) returns zero.
>>
>> (c) The reason that H(P,P) returns zero is that the correct pure
>> simulation of its input can't possibly reach its final state.
>>
>> (d) When the pure simulation of an input can't possibly ever reach its
>> final state then this input never halts.
>>
>> ∴ The only reason that P of int main(){ P(P); } halts is because H(P,P)
>> correctly decided that its input never halts.
>>
>> We can easily verify that the simulation of P(P) is correct by comparing
>> the execution trace of this simulation to the x86 source-code of P shown
>> below.
>>
>> (c) is proved in that when P calls H and H acts as a pure simulator of
>> P(P) it is very obvious that P(P) is stuck in infinitely nested
>> simulation when we examine the execution trace of the simulation of P(P)
>> shown below:
>>
> You've constructed your own paradox which has nothing to do with the
> "invert" logic of the Linz proof.
>
It uses the same "do the opposite of whatever the halt decider decides"
basis of all of the conventional proofs.
// Strachey(1965) "An impossible program"
// CPL translated to C
// https://doi.org/10.1093/comjnl/7.4.313
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
> If H is a simulating halt decider, and it is called on a version of itself, it
> either detects that this will go on forever, or it doesn't. If it doesn't detect
> that this will go on forever, there is nothing to stop the endless spawning
> of "H" contexts, and the program never halts. So H has it wrong. However if
> H detects the situation and terminates, the the program comes to a halt,
> and H was also wrong.
Only because H[0] correctly decides that the pure simulation of P[1]
can't possibly reach its final state does P[0] ever halt.
_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P1 begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1
[00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
https://www.researchgate.net/profile/Pl-Olcott/research
>
> There might be something useful here.
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-22 11:39 -0700 |
| Message-ID | <HXiKI.14754$W56.3798@fx08.iad> |
| In reply to | #36875 |
On 7/22/21 11:16 AM, olcott wrote:
> On 7/22/2021 12:34 PM, Malcolm McLean wrote:
>> On Thursday, 22 July 2021 at 16:51:31 UTC+1, olcott wrote:
>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>
>>> (a) The reason that P of int main(){ P(P); } it is construed as halting
>>> is that it reaches its final state.
>>>
>>> (b) The reason that it reaches its final state is that H(P,P) returns
>>> zero.
>>>
>>> (c) The reason that H(P,P) returns zero is that the correct pure
>>> simulation of its input can't possibly reach its final state.
>>>
>>> (d) When the pure simulation of an input can't possibly ever reach its
>>> final state then this input never halts.
>>>
>>> ∴ The only reason that P of int main(){ P(P); } halts is because H(P,P)
>>> correctly decided that its input never halts.
>>>
>>> We can easily verify that the simulation of P(P) is correct by comparing
>>> the execution trace of this simulation to the x86 source-code of P shown
>>> below.
>>>
>>> (c) is proved in that when P calls H and H acts as a pure simulator of
>>> P(P) it is very obvious that P(P) is stuck in infinitely nested
>>> simulation when we examine the execution trace of the simulation of P(P)
>>> shown below:
>>>
>> You've constructed your own paradox which has nothing to do with the
>> "invert" logic of the Linz proof.
>>
>
> It uses the same "do the opposite of whatever the halt decider decides"
> basis of all of the conventional proofs.
The only contradiction is in the design question of H, which shows that
a correct H can not exist.
Note, that Strachey says that it is impossible to design a program that
can correctly predict the behavior of any other program if that other
program is allowed to use the predictor to analyze itself and give a
contrary answer.
Note, the impossibility is for the decider to be CORRECT.
Since in this case P is using H and is acting contrary, Strachey proof
shows that it is impossible for H to return the right answer.
This doesn't mean the question is 'bad', it means that we have shown
that we can't make a decider that is universally correct.
From THIS statement, we can show that there has to exist some questions
that we can not analytically prove the answer to the question (even if
we know that one of the answers has to be right).
>
> // Strachey(1965) "An impossible program"
> // CPL translated to C
> // https://doi.org/10.1093/comjnl/7.4.313
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
>> If H is a simulating halt decider, and it is called on a version of
>> itself, it
>> either detects that this will go on forever, or it doesn't. If it
>> doesn't detect
>> that this will go on forever, there is nothing to stop the endless
>> spawning
>> of "H" contexts, and the program never halts. So H has it wrong.
>> However if
>> H detects the situation and terminates, the the program comes to a halt,
>> and H was also wrong.
>
> Only because H[0] correctly decides that the pure simulation of P[1]
> can't possibly reach its final state does P[0] ever halt.
But the fact that P[0] DOES halt, says that P is a halting calculation,
after all, that H[0] is part of the logic of P[0].
So H INCORRECTLY decides that P(P) is non-halting and thus aborts its
simulation and this makes the P that was using that H a Halting Computation.
You use UNSOUND logic to incorrectly conclude that H decided correctly.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-24 00:11 -0500 |
| Message-ID | <AOWdnQI1NLWOPGb9nZ2dnUU7-VfNnZ2d@giganews.com> |
| In reply to | #36870 |
On 7/22/2021 12:34 PM, Malcolm McLean wrote:
> On Thursday, 22 July 2021 at 16:51:31 UTC+1, olcott wrote:
>> How is H(P,P)==0 correct even though P(P) stops running?
>>
>> (a) The reason that P of int main(){ P(P); } it is construed as halting
>> is that it reaches its final state.
>>
>> (b) The reason that it reaches its final state is that H(P,P) returns zero.
>>
>> (c) The reason that H(P,P) returns zero is that the correct pure
>> simulation of its input can't possibly reach its final state.
>>
>> (d) When the pure simulation of an input can't possibly ever reach its
>> final state then this input never halts.
>>
>> ∴ The only reason that P of int main(){ P(P); } halts is because H(P,P)
>> correctly decided that its input never halts.
>>
>> We can easily verify that the simulation of P(P) is correct by comparing
>> the execution trace of this simulation to the x86 source-code of P shown
>> below.
>>
>> (c) is proved in that when P calls H and H acts as a pure simulator of
>> P(P) it is very obvious that P(P) is stuck in infinitely nested
>> simulation when we examine the execution trace of the simulation of P(P)
>> shown below:
>>
> You've constructed your own paradox which has nothing to do with the
> "invert" logic of the Linz proof.
>
> If H is a simulating halt decider, and it is called on a version of itself, it
> either detects that this will go on forever, or it doesn't. If it doesn't detect
> that this will go on forever, there is nothing to stop the endless spawning
> of "H" contexts, and the program never halts. So H has it wrong. However if
> H detects the situation and terminates, the the program comes to a halt,
> and H was also wrong.
>
> There might be something useful here.
>
The only reason why int main(){ P(P); } ever halts is that the
subsequent P(P) can be examined by the simulating halt decider and
determined to never reach its final state. H aborts it on this basis.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-23 23:14 -0700 |
| Message-ID | <hdOKI.39917$r21.14430@fx38.iad> |
| In reply to | #36956 |
On 7/23/21 10:11 PM, olcott wrote:
> The only reason why int main(){ P(P); } ever halts is that the
> subsequent P(P) can be examined by the simulating halt decider and
> determined to never reach its final state. H aborts it on this basis.
>
No, it halts because your H THINKS that the simulated P(P) will be
non-halting and aborts its simulation and returns the non-halting return
value and then P(P) will halt, showing that the answer from H was wrong.
That H used faulty logic so it got the wrong answer.
The mere fact that the program
int main() { P(P); }
does halt means that P(P) IS a Halting Computation BY DEFINITION.
That means that any accurate sumulaton of P(P) will also reach its
halting state if simulated long enough.
The fact that H gets it wrong, doesn't change that fact.
H makes the same mistake YOU do (makes sense, you wrote it) and starts
by assuming that H won't abort the simulation, but since it will, it
made a faulty assumption and gets the wrong answer.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-22 19:30 +0100 |
| Message-ID | <87lf5yi4lr.fsf@bsb.me.uk> |
| In reply to | #36857 |
olcott <NoOne@NoWhere.com> writes: > How is H(P,P)==0 correct even though P(P) stops running? Because H is not a halt decider. You've been clear that H does not compute the halting function. If it did, H(P, I) == 0 would be correct only when P(I) does not stop running. This is the pinnacle of your 17 years of "work" on halting? Seriously, go walk a shelter dog. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 14:17 -0500 |
| Message-ID | <vf6dnb_6bNH4WWT9nZ2dnUU7-IfNnZ2d@giganews.com> |
| In reply to | #36877 |
On 7/22/2021 1:30 PM, Ben Bacarisse wrote: > olcott <NoOne@NoWhere.com> writes: > >> How is H(P,P)==0 correct even though P(P) stops running? > > Because H is not a halt decider. You've been clear that H does not > compute the halting function. If it did, H(P, I) == 0 would be correct > only when P(I) does not stop running. > > This is the pinnacle of your 17 years of "work" on halting? > > Seriously, go walk a shelter dog. > The original post shows P[1] as P1 and such because the original source of this original post has formatted text equivalent to: P<sub>1</sub> The fact that P[0] Only halts because H(P[1],P[1]) was correctly decided as not halting and that P[0] would never halt unless P[1] has been aborted conclusively proves that H does correctly decide that its input never halts. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-22 12:42 -0700 |
| Message-ID | <xSjKI.13793$6j.10525@fx04.iad> |
| In reply to | #36880 |
On 7/22/21 12:17 PM, olcott wrote: > On 7/22/2021 1:30 PM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> How is H(P,P)==0 correct even though P(P) stops running? >> >> Because H is not a halt decider. You've been clear that H does not >> compute the halting function. If it did, H(P, I) == 0 would be correct >> only when P(I) does not stop running. >> >> This is the pinnacle of your 17 years of "work" on halting? >> >> Seriously, go walk a shelter dog. >> > > The original post shows P[1] as P1 and such because the original source > of this original post has formatted text equivalent to: P<sub>1</sub> > > The fact that P[0] Only halts because H(P[1],P[1]) was correctly decided > as not halting and that P[0] would never halt unless P[1] has been > aborted conclusively proves that H does correctly decide that its input > never halts. > > No, that is unsound logic. The decision of H[0] to abort its computation of H(P[1],P[1]) is PART of the logic of P[0], and thus it gets 'credit' for that decision. In fact, because these are computations, we actually do know that P[1](P[1]) will ALSO make that same decision through its sub-calculation of H[1](P[2],P[2]) that will also decide to abort it simulation of P[2](P[2]) and thus we see that H[0] deciding that P[1](P[1]) is an infinite computation is incorrect, and if H[0] (and JUST H[0]) had been changed to not halt, it would have simulated the computation of P[1](P[1]) to its halting state, and correctly returned the Halting answer. Summary, given Hn that doesn't abort and Ha that does abort its simulation of P(P) and the corresponding Pn and Pa. Pn(Pn) is non-halting. Pa(pa) is Halting. Hn(Pn,Pn) never returns an answer Ha(Pa,Pa) returns the incorrect Non-Halting answer Hn(Pa,Pa) returns the CORRECT Halting answer Ha(Pn,Pn) returns the CORRECT Non-Halting answer. The Halting Property of a computation should NOT depend on the decider bein used, but with your logic, it does.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-23 00:04 +0100 |
| Message-ID | <87y29ygdc6.fsf@bsb.me.uk> |
| In reply to | #36880 |
olcott <NoOne@NoWhere.com> writes: > On 7/22/2021 1:30 PM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> How is H(P,P)==0 correct even though P(P) stops running? >> Because H is not a halt decider. You've been clear that H does not >> compute the halting function. If it did, H(P, I) == 0 would be correct >> only when P(I) does not stop running. >> This is the pinnacle of your 17 years of "work" on halting? >> Seriously, go walk a shelter dog. > > The fact that P[0] Only halts because H(P[1],P[1]) was correctly > decided as not halting Stupid smoke and mirrors. P(P) halts. The reason does not matter. H does not compute the halting function because H(P, P) == 0. What else do you have? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 18:25 -0500 |
| Message-ID | <RoidndUP7P7wY2T9nZ2dnUU7-QednZ2d@giganews.com> |
| In reply to | #36895 |
On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>> Because H is not a halt decider. You've been clear that H does not
>>> compute the halting function. If it did, H(P, I) == 0 would be correct
>>> only when P(I) does not stop running.
>>> This is the pinnacle of your 17 years of "work" on halting?
>>> Seriously, go walk a shelter dog.
>>
>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>> decided as not halting
>
> Stupid smoke and mirrors. P(P) halts. The reason does not matter. H
> does not compute the halting function because H(P, P) == 0. What else
> do you have?
>
int main() { P(P); } only halts because H(P,P) correctly determines that
its input cannot possibly reach its final state.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-23 00:48 +0100 |
| Message-ID | <87sg05hpup.fsf@bsb.me.uk> |
| In reply to | #36898 |
olcott <NoOne@NoWhere.com> writes:
> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>> Because H is not a halt decider. You've been clear that H does not
>>>> compute the halting function. If it did, H(P, I) == 0 would be correct
>>>> only when P(I) does not stop running.
>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>> Seriously, go walk a shelter dog.
>>>
>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>> decided as not halting
>> Stupid smoke and mirrors. P(P) halts. The reason does not matter. H
>> does not compute the halting function because H(P, P) == 0. What else
>> do you have?
>
> int main() { P(P); } only halts because H(P,P) correctly determines
> that its input cannot possibly reach its final state.
For H to be halt decider, H(P,I) == 0 only for computations P(I) that
don't halt. You know this. H is not deciding halting, it's deciding
something else you refuse to give a name to.
(a) P(P) halts.
(b) H(P,P) == 0.
(c) H(P, I) == 0 is only correct if P(I) does not halt.
You don't accept (c). No amount of waffle about P(P) "only" halting
because reason, will alter what the right answer is.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-23 08:53 -0500 |
| Message-ID | <6q6dnZysGs95VGf9nZ2dnUU7-QPNnZ2d@giganews.com> |
| In reply to | #36899 |
On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>> Because H is not a halt decider. You've been clear that H does not
>>>>> compute the halting function. If it did, H(P, I) == 0 would be correct
>>>>> only when P(I) does not stop running.
>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>> Seriously, go walk a shelter dog.
>>>>
>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>> decided as not halting
>>> Stupid smoke and mirrors. P(P) halts. The reason does not matter. H
>>> does not compute the halting function because H(P, P) == 0. What else
>>> do you have?
>>
>> int main() { P(P); } only halts because H(P,P) correctly determines
>> that its input cannot possibly reach its final state.
>
> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
> don't halt. You know this. H is not deciding halting, it's deciding
> something else you refuse to give a name to.
>
Because we know that the simulation of a machine on its input is
equivalent to the execution of this machine on its input we know that
when the pure simulation of P on its input never halts that P never halts.
int main() { P(P); } only halts because H(P,P) correctly determines that
its input cannot possibly reach its final state.
> (a) P(P) halts.
> (b) H(P,P) == 0.
> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>
> You don't accept (c). No amount of waffle about P(P) "only" halting
> because reason, will alter what the right answer is.
>
I understand that you have no problem with contradicting yourself as
long as it supports your goal of staying focused on rebuttal no matter
what the truth is:
On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.
Unless H[0] aborts P[1] int main(){ P(P); } never halts proving that
H[0](P[1], P[1])==0 is correct according to the criteria that you agreed
to.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-23 08:50 -0700 |
| Message-ID | <3zBKI.58715$dp5.38533@fx48.iad> |
| In reply to | #36904 |
On 7/23/21 6:53 AM, olcott wrote:
> On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>> Because H is not a halt decider. You've been clear that H does not
>>>>>> compute the halting function. If it did, H(P, I) == 0 would be
>>>>>> correct
>>>>>> only when P(I) does not stop running.
>>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>>> Seriously, go walk a shelter dog.
>>>>>
>>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>>> decided as not halting
>>>> Stupid smoke and mirrors. P(P) halts. The reason does not matter. H
>>>> does not compute the halting function because H(P, P) == 0. What else
>>>> do you have?
>>>
>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>> that its input cannot possibly reach its final state.
>>
>> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
>> don't halt. You know this. H is not deciding halting, it's deciding
>> something else you refuse to give a name to.
>>
>
> Because we know that the simulation of a machine on its input is
> equivalent to the execution of this machine on its input we know that
> when the pure simulation of P on its input never halts that P never halts.
Except that you aren't doing a PURE simulation. Thus this logic is
unsound. You are doing a 'pure' simulation until ..., if that until
condition happens you abort the simulation and thus could not use the
logic based on a pure simulation.
The fact that an aborted simulation did not reach the halting state does
NOT prove that the computation is non-halting. It just says that if the
machine does halt, it halts after more steps then were simulated.
>
> int main() { P(P); } only halts because H(P,P) correctly determines that
> its input cannot possibly reach its final state.
But it DID Halt, and thus P(P) is Halting.
H(P,P) says non-halting, but it never actually correctly proved that,
becuase its logic was based on H never aborting its simulation, but H
does abort its simulation, and thus H used UNSOUND logic.
>
>> (a) P(P) halts.
>> (b) H(P,P) == 0.
>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>
>> You don't accept (c). No amount of waffle about P(P) "only" halting
>> because reason, will alter what the right answer is.
>>
>
> I understand that you have no problem with contradicting yourself as
> long as it supports your goal of staying focused on rebuttal no matter
> what the truth is:
>
Halting is not Non-Halting, thus H(P.P) == 0 can not be true.
> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Truism:
>>> Every simulation that would never stop unless Halts() stops
>>> it at some point specifies infinite execution.
>>
>> Any algorithm that implements this truism is, of course, a halting
>> decider.
>
> Unless H[0] aborts P[1] int main(){ P(P); } never halts proving that
> H[0](P[1], P[1])==0 is correct according to the criteria that you agreed
> to.
>
No, it doesn't, it shows that H is wrong. H[0] needs to abort P[1] in
order for H to meet the requirement of answering. If it doesn't do this,
it fails to even be an incorrect decider. By aborting the simulation it
gets to be a decider. It needs to figure out the right answer to be a
correct decider, but it doesn't have the information it needs to be
correct (and can't get it). Thus it is wrong.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-23 11:00 -0500 |
| Message-ID | <UvmdnW5SNNE4emf9nZ2dnUU7-LnNnZ2d@giganews.com> |
| In reply to | #36908 |
On 7/23/2021 10:50 AM, Richard Damon wrote:
> On 7/23/21 6:53 AM, olcott wrote:
>> On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>>> Because H is not a halt decider. You've been clear that H does not
>>>>>>> compute the halting function. If it did, H(P, I) == 0 would be
>>>>>>> correct
>>>>>>> only when P(I) does not stop running.
>>>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>>>> Seriously, go walk a shelter dog.
>>>>>>
>>>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>>>> decided as not halting
>>>>> Stupid smoke and mirrors. P(P) halts. The reason does not matter. H
>>>>> does not compute the halting function because H(P, P) == 0. What else
>>>>> do you have?
>>>>
>>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>>> that its input cannot possibly reach its final state.
>>>
>>> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
>>> don't halt. You know this. H is not deciding halting, it's deciding
>>> something else you refuse to give a name to.
>>>
>>
>> Because we know that the simulation of a machine on its input is
>> equivalent to the execution of this machine on its input we know that
>> when the pure simulation of P on its input never halts that P never halts.
>
> Except that you aren't doing a PURE simulation. Thus this logic is
> unsound. You are doing a 'pure' simulation until ..., if that until
> condition happens you abort the simulation and thus could not use the
> logic based on a pure simulation.
>
> The fact that an aborted simulation did not reach the halting state does
> NOT prove that the computation is non-halting.
The fact that the input to H(P,P) cannot possibly ever reach its final
state whether or not H aborts the simulation of this input conclusively
proves that this input never halts.
> It just says that if the
> machine does halt, it halts after more steps then were simulated.
>
The input to H(P,P) cannot possibly ever reach its final state even
after an infinite number of steps.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-23 09:31 -0700 |
| Message-ID | <u9CKI.13817$qL.8898@fx14.iad> |
| In reply to | #36910 |
On 7/23/21 9:00 AM, olcott wrote:
> On 7/23/2021 10:50 AM, Richard Damon wrote:
>> On 7/23/21 6:53 AM, olcott wrote:
>>> On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>>>> Because H is not a halt decider. You've been clear that H does not
>>>>>>>> compute the halting function. If it did, H(P, I) == 0 would be
>>>>>>>> correct
>>>>>>>> only when P(I) does not stop running.
>>>>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>>>>> Seriously, go walk a shelter dog.
>>>>>>>
>>>>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>>>>> decided as not halting
>>>>>> Stupid smoke and mirrors. P(P) halts. The reason does not
>>>>>> matter. H
>>>>>> does not compute the halting function because H(P, P) == 0. What
>>>>>> else
>>>>>> do you have?
>>>>>
>>>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>>>> that its input cannot possibly reach its final state.
>>>>
>>>> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
>>>> don't halt. You know this. H is not deciding halting, it's deciding
>>>> something else you refuse to give a name to.
>>>>
>>>
>>> Because we know that the simulation of a machine on its input is
>>> equivalent to the execution of this machine on its input we know that
>>> when the pure simulation of P on its input never halts that P never
>>> halts.
>>
>> Except that you aren't doing a PURE simulation. Thus this logic is
>> unsound. You are doing a 'pure' simulation until ..., if that until
>> condition happens you abort the simulation and thus could not use the
>> logic based on a pure simulation.
>>
>> The fact that an aborted simulation did not reach the halting state does
>> NOT prove that the computation is non-halting.
>
> The fact that the input to H(P,P) cannot possibly ever reach its final
> state whether or not H aborts the simulation of this input conclusively
> proves that this input never halts.
It isn't what the 'input' does, it is what the actual machine does. Look
at the DEFINITION.
P(P) DOES Halt, if H(P,P) returns non-halting.
Thus, if H(P,P) returns non-Halting, then P(P) IS HALTING, and H(P,P) is
wrong.
If H(P,P) never returns, it fails to be a decider, and is thus WRONG.
>
>> It just says that if the
>> machine does halt, it halts after more steps then were simulated.
>>
>
> The input to H(P,P) cannot possibly ever reach its final state even
> after an infinite number of steps.
>
Again, you have the WRONG definition. The answer that H needs to return
is what the ACTUAL MACHINE REPRENTED by the input does.
WRONG DEFINITION, bad logic, UNSOUND results.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-23 12:13 -0500 |
| Message-ID | <mMCdnR7WTMwqZWf9nZ2dnUU7-bXNnZ2d@giganews.com> |
| In reply to | #36911 |
On 7/23/2021 11:31 AM, Richard Damon wrote:
> On 7/23/21 9:00 AM, olcott wrote:
>> On 7/23/2021 10:50 AM, Richard Damon wrote:
>>> On 7/23/21 6:53 AM, olcott wrote:
>>>> On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>>>>> Because H is not a halt decider. You've been clear that H does not
>>>>>>>>> compute the halting function. If it did, H(P, I) == 0 would be
>>>>>>>>> correct
>>>>>>>>> only when P(I) does not stop running.
>>>>>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>>>>>> Seriously, go walk a shelter dog.
>>>>>>>>
>>>>>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>>>>>> decided as not halting
>>>>>>> Stupid smoke and mirrors. P(P) halts. The reason does not
>>>>>>> matter. H
>>>>>>> does not compute the halting function because H(P, P) == 0. What
>>>>>>> else
>>>>>>> do you have?
>>>>>>
>>>>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>>>>> that its input cannot possibly reach its final state.
>>>>>
>>>>> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
>>>>> don't halt. You know this. H is not deciding halting, it's deciding
>>>>> something else you refuse to give a name to.
>>>>>
>>>>
>>>> Because we know that the simulation of a machine on its input is
>>>> equivalent to the execution of this machine on its input we know that
>>>> when the pure simulation of P on its input never halts that P never
>>>> halts.
>>>
>>> Except that you aren't doing a PURE simulation. Thus this logic is
>>> unsound. You are doing a 'pure' simulation until ..., if that until
>>> condition happens you abort the simulation and thus could not use the
>>> logic based on a pure simulation.
>>>
>>> The fact that an aborted simulation did not reach the halting state does
>>> NOT prove that the computation is non-halting.
>>
>> The fact that the input to H(P,P) cannot possibly ever reach its final
>> state whether or not H aborts the simulation of this input conclusively
>> proves that this input never halts.
>
> It isn't what the 'input' does, it is what the actual machine does. Look
> at the DEFINITION.
>
> P(P) DOES Halt, if H(P,P) returns non-halting.
>
> Thus, if H(P,P) returns non-Halting, then P(P) IS HALTING, and H(P,P) is
> wrong.
>
> If H(P,P) never returns, it fails to be a decider, and is thus WRONG.
int main(){ P(P); } never halts unless H[0](P[1],P[1]) aborts the
simulation of its input, thus proving that its input never halts.
>
>
>>
>>> It just says that if the
>>> machine does halt, it halts after more steps then were simulated.
>>>
>>
>> The input to H(P,P) cannot possibly ever reach its final state even
>> after an infinite number of steps.
>>
>
> Again, you have the WRONG definition. The answer that H needs to return
> is what the ACTUAL MACHINE REPRENTED by the input does.
>
Not when we know that the simulation of the description of a machine on
its input is computationally equivalent to the execution of this same
machine on its input.
> WRONG DEFINITION, bad logic, UNSOUND results.
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-23 11:31 -0700 |
| Message-ID | <7WDKI.23498$7H7.3910@fx42.iad> |
| In reply to | #36914 |
On 7/23/21 10:13 AM, olcott wrote:
> On 7/23/2021 11:31 AM, Richard Damon wrote:
>> On 7/23/21 9:00 AM, olcott wrote:
>>> On 7/23/2021 10:50 AM, Richard Damon wrote:
>>>> On 7/23/21 6:53 AM, olcott wrote:
>>>>> On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>>>>>> Because H is not a halt decider. You've been clear that H
>>>>>>>>>> does not
>>>>>>>>>> compute the halting function. If it did, H(P, I) == 0 would be
>>>>>>>>>> correct
>>>>>>>>>> only when P(I) does not stop running.
>>>>>>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>>>>>>> Seriously, go walk a shelter dog.
>>>>>>>>>
>>>>>>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>>>>>>> decided as not halting
>>>>>>>> Stupid smoke and mirrors. P(P) halts. The reason does not
>>>>>>>> matter. H
>>>>>>>> does not compute the halting function because H(P, P) == 0. What
>>>>>>>> else
>>>>>>>> do you have?
>>>>>>>
>>>>>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>>>>>> that its input cannot possibly reach its final state.
>>>>>>
>>>>>> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
>>>>>> don't halt. You know this. H is not deciding halting, it's deciding
>>>>>> something else you refuse to give a name to.
>>>>>>
>>>>>
>>>>> Because we know that the simulation of a machine on its input is
>>>>> equivalent to the execution of this machine on its input we know that
>>>>> when the pure simulation of P on its input never halts that P never
>>>>> halts.
>>>>
>>>> Except that you aren't doing a PURE simulation. Thus this logic is
>>>> unsound. You are doing a 'pure' simulation until ..., if that until
>>>> condition happens you abort the simulation and thus could not use the
>>>> logic based on a pure simulation.
>>>>
>>>> The fact that an aborted simulation did not reach the halting state
>>>> does
>>>> NOT prove that the computation is non-halting.
>>>
>>> The fact that the input to H(P,P) cannot possibly ever reach its final
>>> state whether or not H aborts the simulation of this input conclusively
>>> proves that this input never halts.
>>
>> It isn't what the 'input' does, it is what the actual machine does. Look
>> at the DEFINITION.
>>
>> P(P) DOES Halt, if H(P,P) returns non-halting.
>>
>> Thus, if H(P,P) returns non-Halting, then P(P) IS HALTING, and H(P,P) is
>> wrong.
>>
>> If H(P,P) never returns, it fails to be a decider, and is thus WRONG.
>
> int main(){ P(P); } never halts unless H[0](P[1],P[1]) aborts the
> simulation of its input, thus proving that its input never halts.
But it HALTS, on its own. Thus it is Halting.
The fact that H INCORRECTLY aborts it simulation of P(P) doesn't mean
that it dopesn't halt.
The fact that a DIFFERENT P (using a diffent H) doesn't halt when that H
doesn't abort its simulation proves nothing, that is a DIFFERENT Turing
Machine Equivalent P.
Remember, we are talking about the PROGRAM P, not the 'Function' P.
The Function, by itself isn't a computation, or the equivalent of a
Turing Machine, because it is incomplete.
>
>>
>>
>>>
>>>> It just says that if the
>>>> machine does halt, it halts after more steps then were simulated.
>>>>
>>>
>>> The input to H(P,P) cannot possibly ever reach its final state even
>>> after an infinite number of steps.
>>>
>>
>> Again, you have the WRONG definition. The answer that H needs to return
>> is what the ACTUAL MACHINE REPRENTED by the input does.
>>
>
> Not when we know that the simulation of the description of a machine on
> its input is computationally equivalent to the execution of this same
> machine on its input.
But it isn't, if the simulation doesn't run to completion.
An aborted simulation proves NOTHING. Your logic that you use on the
traces is FLAWED, as it is based on the FALSE PREMISE that H NEVER
aborts its simulation, and is thus UNSOUND.
Being a 'Pure Simulation Until ...' isn't being a Pure Simulator, any
more that the fact that a robber can't say he is innocent of robbery as
he hadn't taken anything before he commited the robbery.
>
>> WRONG DEFINITION, bad logic, UNSOUND results.
>>
>
>
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.theory
csiph-web