Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #36412 > unrolled thread
| Started by | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| First post | 2021-07-16 19:00 +0100 |
| Last post | 2021-07-22 08:12 -0700 |
| Articles | 20 on this page of 135 — 15 participants |
Back to article view | Back to comp.theory
Halting Problem Solved (Black Box Decider Theory) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-16 19:00 +0100
Re: Halting Problem Solved (Black Box Decider Theory) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-16 19:28 +0100
Re: Halting Problem Solved (Black Box Decider Theory) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-16 19:31 +0100
Re: Halting Problem Solved (Black Box Decider Theory) olcott <NoOne@NoWhere.com> - 2021-07-16 14:24 -0500
Re: Halting Problem Solved (Black Box Decider Theory) Alan Mackenzie <acm@muc.de> - 2021-07-16 19:46 +0000
Re: Halting Problem Solved (Black Box Decider Theory) olcott <NoOne@NoWhere.com> - 2021-07-16 14:56 -0500
Re: Halting Problem Solved (Black Box Decider Theory) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-16 20:56 +0100
Re: Halting Problem Solved (Black Box Decider Theory) olcott <NoOne@NoWhere.com> - 2021-07-16 15:00 -0500
Re: Halting Problem Solved (Black Box Decider Theory) Alan Mackenzie <acm@muc.de> - 2021-07-16 22:42 +0000
Re: Halting Problem Solved (Black Box Decider Theory) Alan Mackenzie <acm@muc.de> - 2021-07-16 22:24 +0000
Re: Halting Problem Solved (Black Box Decider Theory) olcott <NoOne@NoWhere.com> - 2021-07-16 17:32 -0500
Re: Halting Problem Solved (Black Box Decider Theory) Alan Mackenzie <acm@muc.de> - 2021-07-16 22:54 +0000
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] olcott <NoOne@NoWhere.com> - 2021-07-16 23:15 -0500
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] Alan Mackenzie <acm@muc.de> - 2021-07-17 09:10 +0000
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] olcott <NoOne@NoWhere.com> - 2021-07-17 09:37 -0500
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-17 17:24 +0100
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] olcott <NoOne@NoWhere.com> - 2021-07-17 12:06 -0500
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-18 02:45 +0100
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-18 12:26 +0100
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] olcott <NoOne@NoWhere.com> - 2021-07-19 09:41 -0500
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-20 01:36 +0100
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] Alan Mackenzie <acm@muc.de> - 2021-07-17 17:11 +0000
Re: Halting Problem Solved (Black Box Decider Theory)[ Strachey P ] Richard Damon <Richard@Damon-Family.org> - 2021-07-17 07:40 -0600
Re: Halting Problem Solved (Black Box Decider Theory) David Brown <david.brown@hesbynett.no> - 2021-07-17 16:47 +0200
Re: Halting Problem Solved (Black Box Decider Theory) David Brown <david.brown@hesbynett.no> - 2021-07-17 16:37 +0200
Re: Halting Problem Solved (Black Box Decider Theory) [ Flibble is correct ] olcott <NoOne@NoWhere.com> - 2021-07-17 11:40 -0500
Re: Halting Problem Solved (Black Box Decider Theory) [ Flibble is correct ] David Brown <david.brown@hesbynett.no> - 2021-07-18 11:43 +0200
Re: Halting Problem Solved Andy Walker <anw@cuboid.co.uk> - 2021-07-18 12:13 +0100
Re: Halting Problem Solved David Brown <david.brown@hesbynett.no> - 2021-07-18 15:15 +0200
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-18 07:42 -0600
Re: Halting Problem Solved David Brown <david.brown@hesbynett.no> - 2021-07-18 17:02 +0200
Re: Halting Problem Solved Jeff Barnett <jbb@notatt.com> - 2021-07-18 10:12 -0600
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-18 13:22 -0500
Re: Halting Problem Solved Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-18 12:30 -0700
Re: Halting Problem Solved [ Pathological self-reference error (Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-19 08:41 -0500
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-18 19:55 -0700
Re: Halting Problem Solved David Brown <david.brown@hesbynett.no> - 2021-07-18 21:00 +0200
Re: Halting Problem Solved Jeff Barnett <jbb@notatt.com> - 2021-07-18 14:22 -0600
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-18 20:08 -0700
Re: Halting Problem Solved Jeff Barnett <jbb@notatt.com> - 2021-07-19 02:06 -0600
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-19 21:09 -0700
Re: Halting Problem Solved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-20 11:24 +0100
Re: Halting Problem Solved Daniel Pehoushek <pehoushek1@gmail.com> - 2021-07-20 03:43 -0700
Re: Halting Problem Solved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-20 13:53 +0100
Re: Halting Problem Solved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-20 14:02 +0100
Re: Halting Problem Solved Daniel Pehoushek <pehoushek1@gmail.com> - 2021-07-20 06:30 -0700
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-20 10:22 -0700
Re: Halting Problem Solved David Brown <david.brown@hesbynett.no> - 2021-07-19 09:11 +0200
Re: Halting Problem Solved "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-19 01:13 -0700
Re: Halting Problem Solved "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-19 11:34 -0700
Re: Halting Problem Solved Jeff Barnett <jbb@notatt.com> - 2021-07-19 02:24 -0600
Re: Halting Problem Solved David Brown <david.brown@hesbynett.no> - 2021-07-19 13:06 +0200
Re: Halting Problem Solved Daniel Pehoushek <pehoushek1@gmail.com> - 2021-07-19 04:52 -0700
Re: Halting Problem Solved Daniel Pehoushek <pehoushek1@gmail.com> - 2021-07-19 08:14 -0700
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-19 08:43 -0500
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-19 21:12 -0700
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-19 09:16 -0500
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-19 21:25 -0700
Re: Halting Problem Solved Daniel Pehoushek <pehoushek1@gmail.com> - 2021-07-20 00:38 -0700
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-19 09:43 -0500
Re: Halting Problem Solved (Black Box Decider Theory) [ Flibble is correct ] olcott <NoOne@NoWhere.com> - 2021-07-19 09:48 -0500
Re: Halting Problem Solved (Black Box Decider Theory) Newberry <newberryxy@gmail.com> - 2021-07-19 13:30 -0700
Re: Halting Problem Solved (Black Box Decider Theory) "dklei...@gmail.com" <dkleinecke@gmail.com> - 2021-07-20 16:16 -0700
Re: Halting Problem Solved (Black Box Decider Theory) André G. Isaak <agisaak@gm.invalid> - 2021-07-20 17:21 -0600
Re: Halting Problem Solved (Black Box Decider Theory) "dklei...@gmail.com" <dkleinecke@gmail.com> - 2021-07-20 16:37 -0700
Re: Halting Problem Solved (Black Box Decider Theory) André G. Isaak <agisaak@gm.invalid> - 2021-07-20 18:37 -0600
Re: Halting Problem Solved (Black Box Decider Theory) Richard Damon <Richard@Damon-Family.org> - 2021-07-20 18:02 -0700
Re: Halting Problem Solved (Black Box Decider Theory) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-20 23:32 -0700
Re: Halting Problem Solved (Black Box Decider Theory) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-21 08:17 -0700
Re: Halting Problem Solved (Black Box Decider Theory) André G. Isaak <agisaak@gm.invalid> - 2021-07-21 09:24 -0600
Re: Halting Problem Solved (Black Box Decider Theory) Newberry <newberryxy@gmail.com> - 2021-07-20 23:26 -0700
Re: Halting Problem Solved (Black Box Decider Theory) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-16 21:57 +0100
Re: Halting Problem Solved (Black Box Decider Theory) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-16 22:06 +0100
Re: Halting Problem Solved (Black Box Decider Theory) olcott <NoOne@NoWhere.com> - 2021-07-16 16:10 -0500
Re: Halting Problem Solved (Black Box Decider Theory) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-16 22:22 +0100
Re: Halting Problem Solved (Black Box Decider Theory) olcott <NoOne@NoWhere.com> - 2021-07-16 16:30 -0500
Re: Halting Problem Solved (Black Box Decider Theory) olcott <NoOne@NoWhere.com> - 2021-07-16 13:31 -0500
Re: Halting Problem Solved (Black Box Decider Theory) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-16 21:46 +0100
Re: Halting Problem Solved (Black Box Decider Theory) olcott <NoOne@NoWhere.com> - 2021-07-16 16:07 -0500
Re: Halting Problem Solved (Black Box Decider Theory) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-16 23:59 +0100
Re: Halting Problem Solved [ Ben admits that he lied ] olcott <NoOne@NoWhere.com> - 2021-07-17 10:35 -0500
Re: Halting Problem Solved [ Ben admits that he lied ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-18 03:32 +0100
Re: Halting Problem Solved [ Ben admits that he lied ] olcott <NoOne@NoWhere.com> - 2021-07-19 09:55 -0500
Re: Halting Problem Solved [ Ben admits that he lied ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-20 01:35 +0100
Re: Halting Problem Solved [ Ben admits that he lied ] olcott <NoOne@NoWhere.com> - 2021-07-20 09:22 -0500
Re: Halting Problem Solved [ Ben admits that he lied ] André G. Isaak <agisaak@gm.invalid> - 2021-07-20 08:40 -0600
Re: Halting Problem Solved [ Ben admits that he lied ] olcott <NoOne@NoWhere.com> - 2021-07-20 10:18 -0500
Re: Halting Problem Solved [ Ben admits that he lied ] André G. Isaak <agisaak@gm.invalid> - 2021-07-20 09:29 -0600
Re: Halting Problem Solved [ Ben admits that he lied ] Daniel Pehoushek <pehoushek1@gmail.com> - 2021-07-20 09:45 -0700
Re: Halting Problem Solved [ Ben admits that he lied ] Richard Damon <Richard@Damon-Family.org> - 2021-07-20 10:33 -0700
Re: Halting Problem Solved [ Ben admits that he lied ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-21 01:28 +0100
Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] olcott <NoOne@NoWhere.com> - 2021-07-21 09:48 -0500
Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-21 09:41 -0700
Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-22 01:12 +0100
Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] olcott <NoOne@NoWhere.com> - 2021-07-21 20:27 -0500
Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-21 18:37 -0700
Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] olcott <NoOne@NoWhere.com> - 2021-07-21 20:49 -0500
Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] Richard Damon <Richard@Damon-Family.org> - 2021-07-21 19:01 -0700
Re: Halting Problem Solved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-22 02:49 +0100
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-21 20:57 -0500
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-21 19:19 -0700
Re: Halting Problem Solved André G. Isaak <agisaak@gm.invalid> - 2021-07-21 20:57 -0600
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-21 22:25 -0500
Re: Halting Problem Solved André G. Isaak <agisaak@gm.invalid> - 2021-07-21 21:50 -0600
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-21 23:40 -0500
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-21 22:26 -0700
Re: Halting Problem Solved André G. Isaak <agisaak@gm.invalid> - 2021-07-22 00:55 -0600
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-22 08:04 -0500
Re: Halting Problem Solved André G. Isaak <agisaak@gm.invalid> - 2021-07-22 08:23 -0600
Re: Halting Problem Solved (title is a misnomer) olcott <NoOne@NoWhere.com> - 2021-07-22 09:52 -0500
Re: Halting Problem Solved (title is a misnomer) Richard Damon <Richard@Damon-Family.org> - 2021-07-22 10:24 -0700
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-22 10:22 -0700
Re: Halting Problem Solved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-22 21:53 +0100
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-22 16:47 -0500
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-22 14:54 -0700
Re: Halting Problem Solved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 00:04 +0100
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-22 18:22 -0500
Re: Halting Problem Solved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 00:53 +0100
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-23 09:04 -0500
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-23 09:41 -0700
Re: Halting Problem Solved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 22:13 +0100
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-23 16:54 -0500
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-23 15:19 -0700
Re: Halting Problem Solved Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 04:02 +0100
Re: Halting Problem Solved André G. Isaak <agisaak@gm.invalid> - 2021-07-22 18:05 -0600
Re: Halting Problem Solved olcott <NoOne@NoWhere.com> - 2021-07-23 08:36 -0500
Re: Halting Problem Solved Richard Damon <Richard@Damon-Family.org> - 2021-07-23 08:51 -0700
Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-07-21 21:04 -0700
Re: Halting Problem Solved [ Ben admits that he lied ] Richard Damon <Richard@Damon-Family.org> - 2021-07-19 21:17 -0700
Re: Halting Problem Solved (Black Box Decider Theory) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-16 23:59 +0100
Re: Halting Problem Solved (Black Box Decider Theory) [Ben is a liar ] olcott <NoOne@NoWhere.com> - 2021-07-17 10:38 -0500
Re: Halting Problem Solved (Black Box Decider Theory) [Ben is a liar ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-18 03:12 +0100
Re: Halting Problem Solved (Black Box Decider Theory) [Ben is a liar ] olcott <NoOne@NoWhere.com> - 2021-07-19 10:02 -0500
Re: Halting Problem Solved (Black Box Decider Theory) [Ben is a liar ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-20 01:36 +0100
Re: Halting Problem Solved (Black Box Decider Theory) Charlie-Boo <shymathguy@gmail.com> - 2021-07-22 08:12 -0700
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-21 19:19 -0700 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <sA4KI.66397$VU3.3313@fx46.iad> |
| In reply to | #36829 |
On 7/21/21 6:57 PM, olcott wrote:
> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I did not even glance at any of the words
>>
>> It's simple. I asked which of these three facts you reject:
>>
>> (a) P(P) halts.
>> (b) H(P, P) == 0.
>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>
>> and it seems the answer is (c). This despite your disingenuous
>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>> clear. (Details in the parent article for those who do read.)
>>
>
> The P of int main() { P(P); } halts
> and H(P,P)==0 is the correct halts status.
> It is not a contradiction it is a paradox.
>
> We know that it is not a contradiction because we can verify that the
> input to H(P,P) cannot possibly ever reach its halt state. This
> conclusively proves that the input to H(P,P) never halts.
WRONG. BAD DEFINITION.
H is claimed to be 'Halt Decider', that means its answer is supposed to
be an the answer to the question: Does the machine and input given by
representation to this machine reach its Halt state in a finite number
of steps (Halting) or not (Non-Halting).
Thus, H(P,P) == 0 IS WRONG.
Like all real paradox, the apparent contradiction is solved by the right
understanding, that you are using two DIFFERENT questions. THe fact that
you are judging H(P,P) == 0 to be correct by a question other than the
question of the Halting Problem, shows that you whole argument fails to
meet its claimed purpose, as you are just showing that POOP doesn't get
disproven by arguments like Linz. It says NOTHING about the real Halting
Problem.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> _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]
>
>
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2021-07-21 20:57 -0600 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <sdamrl$2de$1@dont-email.me> |
| In reply to | #36829 |
On 2021-07-21 19:57, olcott wrote:
> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I did not even glance at any of the words
>>
>> It's simple. I asked which of these three facts you reject:
>>
>> (a) P(P) halts.
>> (b) H(P, P) == 0.
>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>
>> and it seems the answer is (c). This despite your disingenuous
>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>> clear. (Details in the parent article for those who do read.)
>>
>
> The P of int main() { P(P); } halts
> and H(P,P)==0 is the correct halts status.
> It is not a contradiction it is a paradox.
This statement is entirely laughable.
If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
demonstrates that whatever logic your H is using is *wrong*.
A halt decider H(X,Y) is *defined* as something which answers the
question 'Does the TM described by X halt on input Y'.
If X(Y) halts, then the *only* correct answer for H(X, Y) to give is
'yes, it halts'.
This is a simple matter of definition.
It is entirely pointless to argue about your flawed algorithm, your
silly 'axioms', or your pointless traces given the above. Above you've
given a crystal clear statement to the effect that your H(P, P) gives
the *wrong* answer.
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-21 22:25 -0500 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <z7mdnbWXpuaCeGX9nZ2dnUU7-UnNnZ2d@giganews.com> |
| In reply to | #36832 |
On 7/21/2021 9:57 PM, André G. Isaak wrote:
> On 2021-07-21 19:57, olcott wrote:
>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I did not even glance at any of the words
>>>
>>> It's simple. I asked which of these three facts you reject:
>>>
>>> (a) P(P) halts.
>>> (b) H(P, P) == 0.
>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>
>>> and it seems the answer is (c). This despite your disingenuous
>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>> clear. (Details in the parent article for those who do read.)
>>>
>>
>> The P of int main() { P(P); } halts
>> and H(P,P)==0 is the correct halts status.
>> It is not a contradiction it is a paradox.
>
> This statement is entirely laughable.
>
> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
> demonstrates that whatever logic your H is using is *wrong*.
>
If you bothered to pay complete attention you would understand that the
input to H(P,P) cannot possibly reach its final state thus never halts.
> A halt decider H(X,Y) is *defined* as something which answers the
> question 'Does the TM described by X halt on input Y'.
>
> If X(Y) halts, then the *only* correct answer for H(X, Y) to give is
> 'yes, it halts'.
>
> This is a simple matter of definition.
>
If you bothered to pay complete attention you would understand that the
input to H(P,P) cannot possibly reach its final state thus never halts.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]
> It is entirely pointless to argue about your flawed algorithm, your
> silly 'axioms', or your pointless traces given the above. Above you've
> given a crystal clear statement to the effect that your H(P, P) gives
> the *wrong* answer.
>
> André
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2021-07-21 21:50 -0600 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <sdaptf$hrd$1@dont-email.me> |
| In reply to | #36834 |
On 2021-07-21 21:25, olcott wrote:
> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>> On 2021-07-21 19:57, olcott wrote:
>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> I did not even glance at any of the words
>>>>
>>>> It's simple. I asked which of these three facts you reject:
>>>>
>>>> (a) P(P) halts.
>>>> (b) H(P, P) == 0.
>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>
>>>> and it seems the answer is (c). This despite your disingenuous
>>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>>> clear. (Details in the parent article for those who do read.)
>>>>
>>>
>>> The P of int main() { P(P); } halts
>>> and H(P,P)==0 is the correct halts status.
>>> It is not a contradiction it is a paradox.
>>
>> This statement is entirely laughable.
>>
>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>> demonstrates that whatever logic your H is using is *wrong*.
>>
>
> If you bothered to pay complete attention you would understand that the
> input to H(P,P) cannot possibly reach its final state thus never halts.
Even if this statement were true, it is entirely irrelevant.
A halt decider is *defined* as a TM which takes the description of a
Turing Machine and an input string and determines whether the
computation described by those two inputs halts.
In other words, H(P, P) is supposed to answer the question 'Does the
computation P(P) halt?'
It is *not* concerned with the unrelated question 'Does a simulation of
P(P) inside of H halt?' or 'Does a simulation of some modified version
of P(P) halt?' or any other question which you might imagine as part of
your futile attempt to claim that your H is actually correct.
P(P) halts when run *independently*. That is the *only* thing that
matters by the very definition of the problem.
Everything else you claim is entirely irrelevant.
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-21 23:40 -0500 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <hoOdnTty8NxEa2X9nZ2dnUU7-RvNnZ2d@giganews.com> |
| In reply to | #36835 |
On 7/21/2021 10:50 PM, André G. Isaak wrote:
> On 2021-07-21 21:25, olcott wrote:
>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>> On 2021-07-21 19:57, olcott wrote:
>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> I did not even glance at any of the words
>>>>>
>>>>> It's simple. I asked which of these three facts you reject:
>>>>>
>>>>> (a) P(P) halts.
>>>>> (b) H(P, P) == 0.
>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>
>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>> decider is
>>>>> clear. (Details in the parent article for those who do read.)
>>>>>
>>>>
>>>> The P of int main() { P(P); } halts
>>>> and H(P,P)==0 is the correct halts status.
>>>> It is not a contradiction it is a paradox.
>>>
>>> This statement is entirely laughable.
>>>
>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>> demonstrates that whatever logic your H is using is *wrong*.
>>>
>>
>> If you bothered to pay complete attention you would understand that
>> the input to H(P,P) cannot possibly reach its final state thus never
>> halts.
>
> Even if this statement were true, it is entirely irrelevant.
>
> A halt decider is *defined* as a TM which takes the description of a
> Turing Machine and an input string and determines whether the
> computation described by those two inputs halts.
>
> In other words, H(P, P) is supposed to answer the question 'Does the
> computation P(P) halt?'
>
> It is *not* concerned with the unrelated question 'Does a simulation of
> P(P) inside of H halt?' or 'Does a simulation of some modified version
> of P(P) halt?' or any other question which you might imagine as part of
> your futile attempt to claim that your H is actually correct.
>
> P(P) halts when run *independently*. That is the *only* thing that
> matters by the very definition of the problem.
>
> Everything else you claim is entirely irrelevant.
>
> André
>
The only reason that P of int main() { P(P); } halts on its input is
that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
--
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-21 22:26 -0700 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <6k7KI.22657$Nq7.18576@fx33.iad> |
| In reply to | #36838 |
On 7/21/21 9:40 PM, olcott wrote:
> On 7/21/2021 10:50 PM, André G. Isaak wrote:
>> On 2021-07-21 21:25, olcott wrote:
>>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>>> On 2021-07-21 19:57, olcott wrote:
>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> I did not even glance at any of the words
>>>>>>
>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>>
>>>>>> (a) P(P) halts.
>>>>>> (b) H(P, P) == 0.
>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>
>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>> decider is
>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>>
>>>>>
>>>>> The P of int main() { P(P); } halts
>>>>> and H(P,P)==0 is the correct halts status.
>>>>> It is not a contradiction it is a paradox.
>>>>
>>>> This statement is entirely laughable.
>>>>
>>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>>> demonstrates that whatever logic your H is using is *wrong*.
>>>>
>>>
>>> If you bothered to pay complete attention you would understand that
>>> the input to H(P,P) cannot possibly reach its final state thus never
>>> halts.
>>
>> Even if this statement were true, it is entirely irrelevant.
>>
>> A halt decider is *defined* as a TM which takes the description of a
>> Turing Machine and an input string and determines whether the
>> computation described by those two inputs halts.
>>
>> In other words, H(P, P) is supposed to answer the question 'Does the
>> computation P(P) halt?'
>>
>> It is *not* concerned with the unrelated question 'Does a simulation
>> of P(P) inside of H halt?' or 'Does a simulation of some modified
>> version of P(P) halt?' or any other question which you might imagine
>> as part of your futile attempt to claim that your H is actually correct.
>>
>> P(P) halts when run *independently*. That is the *only* thing that
>> matters by the very definition of the problem.
>>
>> Everything else you claim is entirely irrelevant.
>>
>> André
>>
>
> The only reason that P of int main() { P(P); } halts on its input is
> that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
>
It isn't 'on its input', it is what it does given the input.
P(P) Halts.
Thus H(P,P) == 0 is WRONG.
DEFINITION.
In fact, P(P) only Halts because H(P,P) is WRONG.
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2021-07-22 00:55 -0600 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <sdb4op$7m4$1@dont-email.me> |
| In reply to | #36838 |
On 2021-07-21 22:40, olcott wrote:
> On 7/21/2021 10:50 PM, André G. Isaak wrote:
>> On 2021-07-21 21:25, olcott wrote:
>>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>>> On 2021-07-21 19:57, olcott wrote:
>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> I did not even glance at any of the words
>>>>>>
>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>>
>>>>>> (a) P(P) halts.
>>>>>> (b) H(P, P) == 0.
>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>
>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>> decider is
>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>>
>>>>>
>>>>> The P of int main() { P(P); } halts
>>>>> and H(P,P)==0 is the correct halts status.
>>>>> It is not a contradiction it is a paradox.
>>>>
>>>> This statement is entirely laughable.
>>>>
>>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>>> demonstrates that whatever logic your H is using is *wrong*.
>>>>
>>>
>>> If you bothered to pay complete attention you would understand that
>>> the input to H(P,P) cannot possibly reach its final state thus never
>>> halts.
>>
>> Even if this statement were true, it is entirely irrelevant.
>>
>> A halt decider is *defined* as a TM which takes the description of a
>> Turing Machine and an input string and determines whether the
>> computation described by those two inputs halts.
>>
>> In other words, H(P, P) is supposed to answer the question 'Does the
>> computation P(P) halt?'
>>
>> It is *not* concerned with the unrelated question 'Does a simulation
>> of P(P) inside of H halt?' or 'Does a simulation of some modified
>> version of P(P) halt?' or any other question which you might imagine
>> as part of your futile attempt to claim that your H is actually correct.
>>
>> P(P) halts when run *independently*. That is the *only* thing that
>> matters by the very definition of the problem.
>>
>> Everything else you claim is entirely irrelevant.
>>
>> André
>>
>
> The only reason that P of int main() { P(P); } halts on its input is
> that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
Um. No.
The reason that P(P) halts is because it reaches a final state in a
finite amount of time by mechanically following its program.
To claim the P(P) halts because H(P, P) claims it doesn't halt is absurd.
To claim that P(P) halts because H(P, P) *correctly* claims it doesn't
halt is even more absurd.
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 08:04 -0500 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <jdSdnQUmPdRp8WT9nZ2dnUU7-V3NnZ2d@giganews.com> |
| In reply to | #36840 |
On 7/22/2021 1:55 AM, André G. Isaak wrote:
> On 2021-07-21 22:40, olcott wrote:
>> On 7/21/2021 10:50 PM, André G. Isaak wrote:
>>> On 2021-07-21 21:25, olcott wrote:
>>>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>>>> On 2021-07-21 19:57, olcott wrote:
>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> I did not even glance at any of the words
>>>>>>>
>>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>>>
>>>>>>> (a) P(P) halts.
>>>>>>> (b) H(P, P) == 0.
>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>>
>>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>>> decider is
>>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>>>
>>>>>>
>>>>>> The P of int main() { P(P); } halts
>>>>>> and H(P,P)==0 is the correct halts status.
>>>>>> It is not a contradiction it is a paradox.
>>>>>
>>>>> This statement is entirely laughable.
>>>>>
>>>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>>>> demonstrates that whatever logic your H is using is *wrong*.
>>>>>
>>>>
>>>> If you bothered to pay complete attention you would understand that
>>>> the input to H(P,P) cannot possibly reach its final state thus never
>>>> halts.
>>>
>>> Even if this statement were true, it is entirely irrelevant.
>>>
>>> A halt decider is *defined* as a TM which takes the description of a
>>> Turing Machine and an input string and determines whether the
>>> computation described by those two inputs halts.
>>>
>>> In other words, H(P, P) is supposed to answer the question 'Does the
>>> computation P(P) halt?'
>>>
>>> It is *not* concerned with the unrelated question 'Does a simulation
>>> of P(P) inside of H halt?' or 'Does a simulation of some modified
>>> version of P(P) halt?' or any other question which you might imagine
>>> as part of your futile attempt to claim that your H is actually correct.
>>>
>>> P(P) halts when run *independently*. That is the *only* thing that
>>> matters by the very definition of the problem.
>>>
>>> Everything else you claim is entirely irrelevant.
>>>
>>> André
>>>
>>
>> The only reason that P of int main() { P(P); } halts on its input is
>> that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
>
>
> Um. No.
>
> The reason that P(P) halts is because it reaches a final state in a
> finite amount of time by mechanically following its program.
>
(a) The reason that 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 0;
(c) The reason that H(P,P) returns zero is that the 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.
> To claim the P(P) halts because H(P, P) claims it doesn't halt is absurd.
>
The only reason that P of int main(){ P(P); } halts is because H(P,P)
correctly decided that its input never halts.
> To claim that P(P) halts because H(P, P) *correctly* claims it doesn't
> halt is even more absurd.
>
> André
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2021-07-22 08:23 -0600 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <sdbv0k$igk$1@dont-email.me> |
| In reply to | #36844 |
On 2021-07-22 07:04, olcott wrote:
> On 7/22/2021 1:55 AM, André G. Isaak wrote:
>> On 2021-07-21 22:40, olcott wrote:
>>> On 7/21/2021 10:50 PM, André G. Isaak wrote:
>>>> On 2021-07-21 21:25, olcott wrote:
>>>>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>>>>> On 2021-07-21 19:57, olcott wrote:
>>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> I did not even glance at any of the words
>>>>>>>>
>>>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>>>>
>>>>>>>> (a) P(P) halts.
>>>>>>>> (b) H(P, P) == 0.
>>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>>>
>>>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>>>> decider is
>>>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>>>>
>>>>>>>
>>>>>>> The P of int main() { P(P); } halts
>>>>>>> and H(P,P)==0 is the correct halts status.
>>>>>>> It is not a contradiction it is a paradox.
>>>>>>
>>>>>> This statement is entirely laughable.
>>>>>>
>>>>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>>>>> demonstrates that whatever logic your H is using is *wrong*.
>>>>>>
>>>>>
>>>>> If you bothered to pay complete attention you would understand that
>>>>> the input to H(P,P) cannot possibly reach its final state thus
>>>>> never halts.
>>>>
>>>> Even if this statement were true, it is entirely irrelevant.
>>>>
>>>> A halt decider is *defined* as a TM which takes the description of a
>>>> Turing Machine and an input string and determines whether the
>>>> computation described by those two inputs halts.
>>>>
>>>> In other words, H(P, P) is supposed to answer the question 'Does the
>>>> computation P(P) halt?'
>>>>
>>>> It is *not* concerned with the unrelated question 'Does a simulation
>>>> of P(P) inside of H halt?' or 'Does a simulation of some modified
>>>> version of P(P) halt?' or any other question which you might imagine
>>>> as part of your futile attempt to claim that your H is actually
>>>> correct.
>>>>
>>>> P(P) halts when run *independently*. That is the *only* thing that
>>>> matters by the very definition of the problem.
>>>>
>>>> Everything else you claim is entirely irrelevant.
>>>>
>>>> André
>>>>
>>>
>>> The only reason that P of int main() { P(P); } halts on its input is
>>> that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
>>
>>
>> Um. No.
>>
>> The reason that P(P) halts is because it reaches a final state in a
>> finite amount of time by mechanically following its program.
>>
>
> (a) The reason that it is construed as halting is that it reaches its
> final state.
It isn't just 'construed' as halting. It *is* halting.
> (b) The reason that it reaches its final state is that H(P,P) returns 0;
>
> (c) The reason that H(P,P) returns zero is that the 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.
A pure simulation of P(P) would behave exactly as P(P) behaves. Since
P(P) halts, a pure simulation of P(P) would also halt.
>> To claim the P(P) halts because H(P, P) claims it doesn't halt is absurd.
>>
>
> The only reason that P of int main(){ P(P); } halts is because H(P,P)
> correctly decided that its input never halts.
So P(P) halts because H(P, P) "correctly" decides that P(P) doesn't halt.
I look forward to seeing how you plan on justifying the use of the word
'correctly' in the above sentence in your final paper. I'm sure it will
go over well with whomever you submit this paper to.
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 09:52 -0500 |
| Subject | Re: Halting Problem Solved (title is a misnomer) |
| Message-ID | <Y-ydndonBvvVG2T9nZ2dnUU7-UHNnZ2d@giganews.com> |
| In reply to | #36846 |
On 7/22/2021 9:23 AM, André G. Isaak wrote:
> On 2021-07-22 07:04, olcott wrote:
>> On 7/22/2021 1:55 AM, André G. Isaak wrote:
>>> On 2021-07-21 22:40, olcott wrote:
>>>> On 7/21/2021 10:50 PM, André G. Isaak wrote:
>>>>> On 2021-07-21 21:25, olcott wrote:
>>>>>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-21 19:57, olcott wrote:
>>>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> I did not even glance at any of the words
>>>>>>>>>
>>>>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>>>>>
>>>>>>>>> (a) P(P) halts.
>>>>>>>>> (b) H(P, P) == 0.
>>>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>>>>
>>>>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>>>>> decider is
>>>>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>>>>>
>>>>>>>>
>>>>>>>> The P of int main() { P(P); } halts
>>>>>>>> and H(P,P)==0 is the correct halts status.
>>>>>>>> It is not a contradiction it is a paradox.
>>>>>>>
>>>>>>> This statement is entirely laughable.
>>>>>>>
>>>>>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>>>>>> demonstrates that whatever logic your H is using is *wrong*.
>>>>>>>
>>>>>>
>>>>>> If you bothered to pay complete attention you would understand
>>>>>> that the input to H(P,P) cannot possibly reach its final state
>>>>>> thus never halts.
>>>>>
>>>>> Even if this statement were true, it is entirely irrelevant.
>>>>>
>>>>> A halt decider is *defined* as a TM which takes the description of
>>>>> a Turing Machine and an input string and determines whether the
>>>>> computation described by those two inputs halts.
>>>>>
>>>>> In other words, H(P, P) is supposed to answer the question 'Does
>>>>> the computation P(P) halt?'
>>>>>
>>>>> It is *not* concerned with the unrelated question 'Does a
>>>>> simulation of P(P) inside of H halt?' or 'Does a simulation of some
>>>>> modified version of P(P) halt?' or any other question which you
>>>>> might imagine as part of your futile attempt to claim that your H
>>>>> is actually correct.
>>>>>
>>>>> P(P) halts when run *independently*. That is the *only* thing that
>>>>> matters by the very definition of the problem.
>>>>>
>>>>> Everything else you claim is entirely irrelevant.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> The only reason that P of int main() { P(P); } halts on its input is
>>>> that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
>>>
>>>
>>> Um. No.
>>>
>>> The reason that P(P) halts is because it reaches a final state in a
>>> finite amount of time by mechanically following its program.
>>>
>>
>> (a) The reason that it is construed as halting is that it reaches its
>> final state.
>
> It isn't just 'construed' as halting. It *is* halting.
>
>> (b) The reason that it reaches its final state is that H(P,P) returns 0;
>>
>> (c) The reason that H(P,P) returns zero is that the 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.
>
> A pure simulation of P(P) would behave exactly as P(P) behaves. Since
> P(P) halts, a pure simulation of P(P) would also halt.
>
That a pure simulation of the input to H(P,P) never reaches a final
state is an easily verified fact.
>>> To claim the P(P) halts because H(P, P) claims it doesn't halt is
>>> absurd.
>>>
>>
>> The only reason that P of int main(){ P(P); } halts is because H(P,P)
>> correctly decided that its input never halts.
>
> So P(P) halts because H(P, P) "correctly" decides that P(P) doesn't halt.
>
Yes, a paradox rather than a contradiction.
"This sentence is not true".
is indeed not true yet that does not make it true.
> I look forward to seeing how you plan on justifying the use of the word
> 'correctly' in the above sentence in your final paper. I'm sure it will
> go over well with whomever you submit this paper to.
>
> André
>
That a correct pure simulation of the input to H(P,P) never reaches a
final state is an easily verified fact. This conclusively proves that
the input never halts.
I am not going to submit the paper to anyone until after it is approved
here. Now that I have at least one very excellent reviewer (you) we will
reach a point of mutual agreement.
--
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:24 -0700 |
| Subject | Re: Halting Problem Solved (title is a misnomer) |
| Message-ID | <BRhKI.70729$VU3.48978@fx46.iad> |
| In reply to | #36849 |
On 7/22/21 7:52 AM, olcott wrote:
> On 7/22/2021 9:23 AM, André G. Isaak wrote:
>> On 2021-07-22 07:04, olcott wrote:
>>> On 7/22/2021 1:55 AM, André G. Isaak wrote:
>>>> On 2021-07-21 22:40, olcott wrote:
>>>>> On 7/21/2021 10:50 PM, André G. Isaak wrote:
>>>>>> On 2021-07-21 21:25, olcott wrote:
>>>>>>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>>>>>>> On 2021-07-21 19:57, olcott wrote:
>>>>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> I did not even glance at any of the words
>>>>>>>>>>
>>>>>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>>>>>>
>>>>>>>>>> (a) P(P) halts.
>>>>>>>>>> (b) H(P, P) == 0.
>>>>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>>>>>
>>>>>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>>>>>> decider is
>>>>>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The P of int main() { P(P); } halts
>>>>>>>>> and H(P,P)==0 is the correct halts status.
>>>>>>>>> It is not a contradiction it is a paradox.
>>>>>>>>
>>>>>>>> This statement is entirely laughable.
>>>>>>>>
>>>>>>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>>>>>>> demonstrates that whatever logic your H is using is *wrong*.
>>>>>>>>
>>>>>>>
>>>>>>> If you bothered to pay complete attention you would understand
>>>>>>> that the input to H(P,P) cannot possibly reach its final state
>>>>>>> thus never halts.
>>>>>>
>>>>>> Even if this statement were true, it is entirely irrelevant.
>>>>>>
>>>>>> A halt decider is *defined* as a TM which takes the description of
>>>>>> a Turing Machine and an input string and determines whether the
>>>>>> computation described by those two inputs halts.
>>>>>>
>>>>>> In other words, H(P, P) is supposed to answer the question 'Does
>>>>>> the computation P(P) halt?'
>>>>>>
>>>>>> It is *not* concerned with the unrelated question 'Does a
>>>>>> simulation of P(P) inside of H halt?' or 'Does a simulation of
>>>>>> some modified version of P(P) halt?' or any other question which
>>>>>> you might imagine as part of your futile attempt to claim that
>>>>>> your H is actually correct.
>>>>>>
>>>>>> P(P) halts when run *independently*. That is the *only* thing that
>>>>>> matters by the very definition of the problem.
>>>>>>
>>>>>> Everything else you claim is entirely irrelevant.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> The only reason that P of int main() { P(P); } halts on its input
>>>>> is that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT
>>>>> WRONG !!!
>>>>
>>>>
>>>> Um. No.
>>>>
>>>> The reason that P(P) halts is because it reaches a final state in a
>>>> finite amount of time by mechanically following its program.
>>>>
>>>
>>> (a) The reason that it is construed as halting is that it reaches its
>>> final state.
>>
>> It isn't just 'construed' as halting. It *is* halting.
>>
>>> (b) The reason that it reaches its final state is that H(P,P) returns 0;
>>>
>>> (c) The reason that H(P,P) returns zero is that the 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.
>>
>> A pure simulation of P(P) would behave exactly as P(P) behaves. Since
>> P(P) halts, a pure simulation of P(P) would also halt.
>>
>
> That a pure simulation of the input to H(P,P) never reaches a final
> state is an easily verified fact.
Try it. Keep H as aborting and just simulate P(P). It halts. You
yourself have shown that.
What doesn't halt is a P based on an H that doesn't abort, but that H
doesn't give an answer to H(P,P), so doesn't need to be refuted.
>
>>>> To claim the P(P) halts because H(P, P) claims it doesn't halt is
>>>> absurd.
>>>>
>>>
>>> The only reason that P of int main(){ P(P); } halts is because H(P,P)
>>> correctly decided that its input never halts.
>>
>> So P(P) halts because H(P, P) "correctly" decides that P(P) doesn't halt.
>>
>
> Yes, a paradox rather than a contradiction.
> "This sentence is not true".
> is indeed not true yet that does not make it true.
>
>> I look forward to seeing how you plan on justifying the use of the
>> word 'correctly' in the above sentence in your final paper. I'm sure
>> it will go over well with whomever you submit this paper to.
>>
>> André
>>
>
> That a correct pure simulation of the input to H(P,P) never reaches a
> final state is an easily verified fact. This conclusively proves that
> the input never halts.
WRONG.
Already disproven.
>
> I am not going to submit the paper to anyone until after it is approved
> here. Now that I have at least one very excellent reviewer (you) we will
> reach a point of mutual agreement.
>
Well, then you are never going to publish.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-22 10:22 -0700 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <4PhKI.70728$VU3.21073@fx46.iad> |
| In reply to | #36844 |
On 7/22/21 6:04 AM, olcott wrote:
> On 7/22/2021 1:55 AM, André G. Isaak wrote:
>>
>> Um. No.
>>
>> The reason that P(P) halts is because it reaches a final state in a
>> finite amount of time by mechanically following its program.
>>
>
> (a) The reason that it is construed as halting is that it reaches its
> final state.
CORRECT
>
> (b) The reason that it reaches its final state is that H(P,P) returns 0;
CORRECT
>
> (c) The reason that H(P,P) returns zero is that the pure simulation of
> its input can't possibly reach its final state.
WRONG. UTM(P,P) Will Halt too, as the H within P will still come to this
same halting state.
YOU want to look at a DIFFERENT P to decide. Yes, The Pn that is based
on the Hn that doesn't abort its simulation is non-halting, but the Pa
that is based on the Ha that does abort is Halting.
You don't understand that the actions of P are dependent on the actions
of H so changing H looks at a different P.
>
> (d) When the pure simulation of an input can't possibly ever reach its
> final state then this input never halts.
UNSOUND
>
>> To claim the P(P) halts because H(P, P) claims it doesn't halt is absurd.
>>
>
> The only reason that P of int main(){ P(P); } halts is because H(P,P)
> correctly decided that its input never halts.
Nope, it only halts because H(P,P) INCORRECTED decider that its input
represents a machine that never halts.
>
>> To claim that P(P) halts because H(P, P) *correctly* claims it doesn't
>> halt is even more absurd.
>>
>> André
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-22 21:53 +0100 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <87fsw6hxy9.fsf@bsb.me.uk> |
| In reply to | #36829 |
olcott <NoOne@NoWhere.com> writes:
> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I did not even glance at any of the words
>> It's simple. I asked which of these three facts you reject:
>> (a) P(P) halts.
>> (b) H(P, P) == 0.
>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>> and it seems the answer is (c). This despite your disingenuous
>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>> clear. (Details in the parent article for those who do read.)
>
> The P of int main() { P(P); } halts
Yes, you've confirmed (a) many times.
> and H(P,P)==0
Yes, (b) is also not in dispute.
> is the correct halts status.
> It is not a contradiction it is a paradox.
It's neither. It's just that H is not a halt decider. The fact you
reject is (c) -- the definition of a halt decider.
We've known that for ages. The only issue has been your reluctance to
admit it. You know the game is up unless you can pretend to be still
talking about the halting problem as defined in Linz, Sipser, Davis,
Kleene and everyone else except you.
Although, as I've pointed out many times, the game need not be up. Your
stated specification for the POOH problem is also undecidable. We could
argue about that for the next 17 years instead.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 16:47 -0500 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <1IednbDdRdvEemT9nZ2dnUU7-QPNnZ2d@giganews.com> |
| In reply to | #36887 |
On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I did not even glance at any of the words
>>> It's simple. I asked which of these three facts you reject:
>>> (a) P(P) halts.
>>> (b) H(P, P) == 0.
>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>> and it seems the answer is (c). This despite your disingenuous
>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>> clear. (Details in the parent article for those who do read.)
>>
>> The P of int main() { P(P); } halts
>
> Yes, you've confirmed (a) many times.
>
>> and H(P,P)==0
>
> Yes, (b) is also not in dispute.
>
>> is the correct halts status.
>> It is not a contradiction it is a paradox.
>
> It's neither. It's just that H is not a halt decider. The fact you
> reject is (c) -- the definition of a halt decider.
>
> We've known that for ages. The only issue has been your reluctance to
> admit it. You know the game is up unless you can pretend to be still
> talking about the halting problem as defined in Linz, Sipser, Davis,
> Kleene and everyone else except you.
>
> Although, as I've pointed out many times, the game need not be up. Your
> stated specification for the POOH problem is also undecidable. We could
> argue about that for the next 17 years instead.
>
The fact that int main(){ P(P); } only halts because the input to H(P,P)
aborts the simulation of its input has been mutually agreed that H did
decide its input correctly.
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.
--
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 14:54 -0700 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <FOlKI.54701$h8.6601@fx47.iad> |
| In reply to | #36889 |
On 7/22/21 2:47 PM, olcott wrote:
> On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> I did not even glance at any of the words
>>>> It's simple. I asked which of these three facts you reject:
>>>> (a) P(P) halts.
>>>> (b) H(P, P) == 0.
>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>> and it seems the answer is (c). This despite your disingenuous
>>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>>> clear. (Details in the parent article for those who do read.)
>>>
>>> The P of int main() { P(P); } halts
>>
>> Yes, you've confirmed (a) many times.
>>
>>> and H(P,P)==0
>>
>> Yes, (b) is also not in dispute.
>>
>>> is the correct halts status.
>>> It is not a contradiction it is a paradox.
>>
>> It's neither. It's just that H is not a halt decider. The fact you
>> reject is (c) -- the definition of a halt decider.
>>
>> We've known that for ages. The only issue has been your reluctance to
>> admit it. You know the game is up unless you can pretend to be still
>> talking about the halting problem as defined in Linz, Sipser, Davis,
>> Kleene and everyone else except you.
>>
>> Although, as I've pointed out many times, the game need not be up. Your
>> stated specification for the POOH problem is also undecidable. We could
>> argue about that for the next 17 years instead.
>>
>
> The fact that int main(){ P(P); } only halts because the input to H(P,P)
> aborts the simulation of its input has been mutually agreed that H did
> decide its input correctly.
WHO agrees that that makes the answer right?
A Wrong answer is NEVER the Right Answer.
By Definition, when we run P(P) and it reaches its final Halt state in a
finite number of steps, then P(P) as a Halting Computation.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-23 00:04 +0100 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <871r7qhrx6.fsf@bsb.me.uk> |
| In reply to | #36889 |
olcott <NoOne@NoWhere.com> writes:
> On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> I did not even glance at any of the words
>>>> It's simple. I asked which of these three facts you reject:
>>>> (a) P(P) halts.
>>>> (b) H(P, P) == 0.
>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>> and it seems the answer is (c). This despite your disingenuous
>>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>>> clear. (Details in the parent article for those who do read.)
>>>
>>> The P of int main() { P(P); } halts
>> Yes, you've confirmed (a) many times.
>>
>>> and H(P,P)==0
>> Yes, (b) is also not in dispute.
>>
>>> is the correct halts status.
>>> It is not a contradiction it is a paradox.
>>
>> It's neither. It's just that H is not a halt decider. The fact you
>> reject is (c) -- the definition of a halt decider.
>> We've known that for ages. The only issue has been your reluctance to
>> admit it. You know the game is up unless you can pretend to be still
>> talking about the halting problem as defined in Linz, Sipser, Davis,
>> Kleene and everyone else except you.
>> Although, as I've pointed out many times, the game need not be up. Your
>> stated specification for the POOH problem is also undecidable. We could
>> argue about that for the next 17 years instead.
>
> The fact that int main(){ P(P); } only halts because the input to
> H(P,P) aborts the simulation of its input has been mutually agreed
> that H did decide its input correctly.
Every computation that halts, for whatever reason, is a halting
computation. Every one but you agrees that a halt decider should return
true for a computation that halts, not matter what the "reason" for that
halting.
You have reached a dead-end. You have no more options to find
obfuscating language. H decides something, but it's not what the world
call halting. What a waste of time.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 18:22 -0500 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <RoidndoP7P4tYGT9nZ2dnUU7-QfNnZ2d@giganews.com> |
| In reply to | #36894 |
On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> I did not even glance at any of the words
>>>>> It's simple. I asked which of these three facts you reject:
>>>>> (a) P(P) halts.
>>>>> (b) H(P, P) == 0.
>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>>>> clear. (Details in the parent article for those who do read.)
>>>>
>>>> The P of int main() { P(P); } halts
>>> Yes, you've confirmed (a) many times.
>>>
>>>> and H(P,P)==0
>>> Yes, (b) is also not in dispute.
>>>
>>>> is the correct halts status.
>>>> It is not a contradiction it is a paradox.
>>>
>>> It's neither. It's just that H is not a halt decider. The fact you
>>> reject is (c) -- the definition of a halt decider.
>>> We've known that for ages. The only issue has been your reluctance to
>>> admit it. You know the game is up unless you can pretend to be still
>>> talking about the halting problem as defined in Linz, Sipser, Davis,
>>> Kleene and everyone else except you.
>>> Although, as I've pointed out many times, the game need not be up. Your
>>> stated specification for the POOH problem is also undecidable. We could
>>> argue about that for the next 17 years instead.
>>
>> The fact that int main(){ P(P); } only halts because the input to
>> H(P,P) aborts the simulation of its input has been mutually agreed
>> that H did decide its input correctly.
>
> Every computation that halts, for whatever reason, is a halting
> computation.
Ah but now with André's suggestion of using the proper definition of
halting:
Halting computation: is any computation that eventually reaches its own
final state.
We can know that the input to H(P,P) never halts.
> Every one but you agrees that a halt decider should return
> true for a computation that halts, not matter what the "reason" for that
> halting.
>
> You have reached a dead-end. You have no more options to find
> obfuscating language. H decides something, but it's not what the world
> call halting. What a waste of time.
>
--
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:53 +0100 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <87mtqdhpms.fsf@bsb.me.uk> |
| In reply to | #36897 |
olcott <NoOne@NoWhere.com> writes:
> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> I did not even glance at any of the words
>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>> (a) P(P) halts.
>>>>>> (b) H(P, P) == 0.
>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>
>>>>> The P of int main() { P(P); } halts
>>>> Yes, you've confirmed (a) many times.
>>>>
>>>>> and H(P,P)==0
>>>> Yes, (b) is also not in dispute.
>>>>
>>>>> is the correct halts status.
>>>>> It is not a contradiction it is a paradox.
>>>>
>>>> It's neither. It's just that H is not a halt decider. The fact you
>>>> reject is (c) -- the definition of a halt decider.
>>>> We've known that for ages. The only issue has been your reluctance to
>>>> admit it. You know the game is up unless you can pretend to be still
>>>> talking about the halting problem as defined in Linz, Sipser, Davis,
>>>> Kleene and everyone else except you.
>>>> Although, as I've pointed out many times, the game need not be up. Your
>>>> stated specification for the POOH problem is also undecidable. We could
>>>> argue about that for the next 17 years instead.
>>>
>>> The fact that int main(){ P(P); } only halts because the input to
>>> H(P,P) aborts the simulation of its input has been mutually agreed
>>> that H did decide its input correctly.
>> Every computation that halts, for whatever reason, is a halting
>> computation.
>
> Ah but now with André's suggestion of using the proper definition of
> halting:
>
> Halting computation: is any computation that eventually reaches its
> own final state.
>
> We can know that the input to H(P,P) never halts.
Are you changing your mind about one of the three key facts?
Do you still agree that P(P) halts?
Do you still agree that H(P,P) == 0?
Do you still reject that for H to be a halt decider H(P,I) == 0 only
when P(I) does not halt?
A clear answer would be appreciated. If you are not changing your mind,
you're at a dead-end.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-23 09:04 -0500 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <4sGdnQYuWtPsUWf9nZ2dnUU7-bHNnZ2d@giganews.com> |
| In reply to | #36900 |
On 7/22/2021 6:53 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 3:53 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> I did not even glance at any of the words
>>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>>> (a) P(P) halts.
>>>>>>> (b) H(P, P) == 0.
>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>>
>>>>>> The P of int main() { P(P); } halts
>>>>> Yes, you've confirmed (a) many times.
>>>>>
>>>>>> and H(P,P)==0
>>>>> Yes, (b) is also not in dispute.
>>>>>
>>>>>> is the correct halts status.
>>>>>> It is not a contradiction it is a paradox.
>>>>>
>>>>> It's neither. It's just that H is not a halt decider. The fact you
>>>>> reject is (c) -- the definition of a halt decider.
>>>>> We've known that for ages. The only issue has been your reluctance to
>>>>> admit it. You know the game is up unless you can pretend to be still
>>>>> talking about the halting problem as defined in Linz, Sipser, Davis,
>>>>> Kleene and everyone else except you.
>>>>> Although, as I've pointed out many times, the game need not be up. Your
>>>>> stated specification for the POOH problem is also undecidable. We could
>>>>> argue about that for the next 17 years instead.
>>>>
>>>> The fact that int main(){ P(P); } only halts because the input to
>>>> H(P,P) aborts the simulation of its input has been mutually agreed
>>>> that H did decide its input correctly.
>>> Every computation that halts, for whatever reason, is a halting
>>> computation.
>>
>> Ah but now with André's suggestion of using the proper definition of
>> halting:
>>
>> Halting computation: is any computation that eventually reaches its
>> own final state.
>>
>> We can know that the input to H(P,P) never halts.
>
> Are you changing your mind about one of the three key facts?
>
The key fact that André changed my mind on is that int main(){ P(P); }
halts. Prior to this I thought that it was reasonably possible to
construe it as not halting even though it stops running. By referring to
the key element of the conventional definition of halting André puts
things in much sharper focus.
> Do you still agree that P(P) halts?
>
> Do you still agree that H(P,P) == 0?
>
> Do you still reject that for H to be a halt decider H(P,I) == 0 only
> when P(I) does not halt?
>
P[0] halts when H[0](P[1],P[1]) is correctly decided as never halting.
Once we make the references totally specific it is no longer even
paradoxical.
> A clear answer would be appreciated. If you are not changing your mind,
> you're at a dead-end.
>
--
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:41 -0700 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <xiCKI.16871$_fgb.12681@fx01.iad> |
| In reply to | #36905 |
On 7/23/21 7:04 AM, olcott wrote:
> On 7/22/2021 6:53 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 3:53 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> I did not even glance at any of the words
>>>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>>>> (a) P(P) halts.
>>>>>>>> (b) H(P, P) == 0.
>>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>>>> decider is
>>>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>>>
>>>>>>> The P of int main() { P(P); } halts
>>>>>> Yes, you've confirmed (a) many times.
>>>>>>
>>>>>>> and H(P,P)==0
>>>>>> Yes, (b) is also not in dispute.
>>>>>>
>>>>>>> is the correct halts status.
>>>>>>> It is not a contradiction it is a paradox.
>>>>>>
>>>>>> It's neither. It's just that H is not a halt decider. The fact you
>>>>>> reject is (c) -- the definition of a halt decider.
>>>>>> We've known that for ages. The only issue has been your
>>>>>> reluctance to
>>>>>> admit it. You know the game is up unless you can pretend to be still
>>>>>> talking about the halting problem as defined in Linz, Sipser, Davis,
>>>>>> Kleene and everyone else except you.
>>>>>> Although, as I've pointed out many times, the game need not be
>>>>>> up. Your
>>>>>> stated specification for the POOH problem is also undecidable. We
>>>>>> could
>>>>>> argue about that for the next 17 years instead.
>>>>>
>>>>> The fact that int main(){ P(P); } only halts because the input to
>>>>> H(P,P) aborts the simulation of its input has been mutually agreed
>>>>> that H did decide its input correctly.
>>>> Every computation that halts, for whatever reason, is a halting
>>>> computation.
>>>
>>> Ah but now with André's suggestion of using the proper definition of
>>> halting:
>>>
>>> Halting computation: is any computation that eventually reaches its
>>> own final state.
>>>
>>> We can know that the input to H(P,P) never halts.
>>
>> Are you changing your mind about one of the three key facts?
>>
>
> The key fact that André changed my mind on is that int main(){ P(P); }
> halts. Prior to this I thought that it was reasonably possible to
> construe it as not halting even though it stops running. By referring to
> the key element of the conventional definition of halting André puts
> things in much sharper focus.
So, do you now agree that H(P,P) == 0 is wrong?
>
>> Do you still agree that P(P) halts?
>>
>> Do you still agree that H(P,P) == 0?
>>
>> Do you still reject that for H to be a halt decider H(P,I) == 0 only
>> when P(I) does not halt?
>>
>
> P[0] halts when H[0](P[1],P[1]) is correctly decided as never halting.
> Once we make the references totally specific it is no longer even
> paradoxical.
>
Obviously not. So you think that P[0[ and P[1] can act differently?
This implies that P is not a computation, and thus not a Turing Machine
Equivalent, but that can only happen if H is not a computation and thus
also not a Turig Machine Equivalent. If this is true, your whole
argument has failed, as H needs to be a Turing Machine (or at least an
equivalent of one).
>> A clear answer would be appreciated. If you are not changing your mind,
>> you're at a dead-end.
>>
>
>
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.theory
csiph-web