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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-17 10:35 -0500 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <W9ydnViuzrAvZW_9nZ2dnUU7-ffNnZ2d@giganews.com> |
| In reply to | #36478 |
On 7/16/2021 5:59 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/16/2021 1:00 PM, Mr Flibble wrote:
>>>>> A pathological program that executes a black box decider and returns the
>>>>> opposite result can be detected by the black box decider.
>>>>> So there are THREE possible results the black box decider can return:
>>>>> 1) Program halts
>>>>> 2) Program does not halt
>>>>> 3) Program is pathological and can be discarded as invalid.
>>>>> Halting problem solved.
>>>>> Next.
>>>>> /Flibble
>>>>>
>>>>
>>>> Rice's theorem says that pathological self-reference is (in at least
>>>> some cases) an undecidable property. Unless halting is decidable then
>>>> neither is pathological self-reference.
>>> I am cheered to see you've been paying attention.
>>>
>>>> Halting <is> decidable.
Here is Ben's lie:
>>> No, but more specifically, you've told us that your H gets this case
>>> wrong:
>>
>> No you God damned liar I never said that.
>
> It's true that you never admitted it was wrong,
Above is his admission that it was a lie.
> but you told us that
> H(P,P) == 0 and that P(P) halts. That's the wrong answer, and you knew
> it at the time.
>
I have always known that it is the correct answer, (as shown below) so
you lie again.
I really hope for your sake that this is an exaggeration:
Revelation 21:8 KJV
...all liars, shall have their part in the lake which
burneth with fire and brimstone: which is the second death.
When P(P) stops running because one of the function calls in its
infinite chain of function calls has been aborted this does not make
P(P) a halting computation.
void Infinite_Loop()
{
HERE: goto HERE;
}
_Infinite_Loop()
[00000ab6](01) 55 push ebp
[00000ab7](02) 8bec mov ebp,esp
[00000ab9](02) ebfe jmp 00000ab9
[00000abb](01) 5d pop ebp
[00000abc](01) c3 ret
Size in bytes:(0007) [00000abc]
When the simulating halt decider aborts its simulation of
Infinite_Loop() such that it stops running this does not make
Infinite_Loop() a halting computation.
--
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-18 03:32 +0100 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <878s24l5b9.fsf@bsb.me.uk> |
| In reply to | #36540 |
olcott <NoOne@NoWhere.com> writes: > On 7/16/2021 5:59 PM, Ben Bacarisse wrote: >> olcott <NoOne@NoWhere.com> writes: >> >>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote: >>>> olcott <NoOne@NoWhere.com> writes: >>>> >>>>> On 7/16/2021 1:00 PM, Mr Flibble wrote: >>>>>> A pathological program that executes a black box decider and returns the >>>>>> opposite result can be detected by the black box decider. >>>>>> So there are THREE possible results the black box decider can return: >>>>>> 1) Program halts >>>>>> 2) Program does not halt >>>>>> 3) Program is pathological and can be discarded as invalid. >>>>>> Halting problem solved. >>>>>> Next. >>>>>> /Flibble >>>>>> >>>>> >>>>> Rice's theorem says that pathological self-reference is (in at least >>>>> some cases) an undecidable property. Unless halting is decidable then >>>>> neither is pathological self-reference. >>>> I am cheered to see you've been paying attention. >>>> >>>>> Halting <is> decidable. > > Here is Ben's lie: > >>>> No, but more specifically, you've told us that your H gets this case >>>> wrong: >>> >>> No you God damned liar I never said that. >> It's true that you never admitted it was wrong, > > Above is his admission that it was a lie. A lie is a falsehood deliberately intended to deceive. I believed that you were talking about the halting problem. You kept quoting Linz's definition of what the correct answer was. I thought you understood those lines and took them to be the definition of a halt decider. After all, ever since the Great Delusion of Dec 2018 you've claimed to have two "actual Turing machines", H and H^, "exactly and precisely as in Linz". You got people's attention by claiming to have something impossible, but if you are to believed now, you just had an H that gets the wrong answer (according to Linz) about H^, but you never accepted Linz's notion of the the right answer should be. Well, if anyone believes you now, it's clear that I made a mistake in taking you are your word. A mistake is not a lie. For my part, I don't believe you now. I think you meant what you said back in 2018. I think you have always known how the halting problem is defined, and when you quoted those lines from Linz it was to confirm what a halt decider should do. In other words, I think this is just the latest part of the two and a half year walking back of the deluded claims of Dec 2018. I may, of course, be wrong about this too. The one thing you can know for sure is that I have never lied about any of this. > When P(P) stops running because one of the function calls in its > infinite chain of function calls has been aborted this does not make > P(P) a halting computation. I once asked you to confirm that || (B) Every computation that halts, for whatever reason, is a halting || computation. you said | OK Was that a lie? Where you mistaken? Are you playing some strange language game in which "P(P) stops running" is not "P(P) halts"? Or are you simply saying whatever you need to say in order to keep this nonsense going? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-19 09:55 -0500 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <47udna5Uo4vDD2j9nZ2dnUU7-VvNnZ2d@giganews.com> |
| In reply to | #36578 |
On 7/17/2021 9:32 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/16/2021 5:59 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/16/2021 1:00 PM, Mr Flibble wrote:
>>>>>>> A pathological program that executes a black box decider and returns the
>>>>>>> opposite result can be detected by the black box decider.
>>>>>>> So there are THREE possible results the black box decider can return:
>>>>>>> 1) Program halts
>>>>>>> 2) Program does not halt
>>>>>>> 3) Program is pathological and can be discarded as invalid.
>>>>>>> Halting problem solved.
>>>>>>> Next.
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Rice's theorem says that pathological self-reference is (in at least
>>>>>> some cases) an undecidable property. Unless halting is decidable then
>>>>>> neither is pathological self-reference.
>>>>> I am cheered to see you've been paying attention.
>>>>>
>>>>>> Halting <is> decidable.
>>
>> Here is Ben's lie:
>>
>>>>> No, but more specifically, you've told us that your H gets this case
>>>>> wrong:
>>>>
>>>> No you God damned liar I never said that.
>>> It's true that you never admitted it was wrong,
>>
>> Above is his admission that it was a lie.
>
> A lie is a falsehood deliberately intended to deceive. I believed that
You said :
>>>>> you've told us that your H gets this case wrong:
You know damn well that I never said that H gets this case wrong.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
P((u32)P);
}
The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.
Personally this seems too harsh to me: Revelation 21:8 KJV
...all liars, shall have their part in the lake which burneth with fire
and brimstone: which is the second death.
> you were talking about the halting problem. You kept quoting Linz's
> definition of what the correct answer was. I thought you understood
> those lines and took them to be the definition of a halt decider.
>
> After all, ever since the Great Delusion of Dec 2018 you've claimed to
> have two "actual Turing machines", H and H^, "exactly and precisely as
> in Linz". You got people's attention by claiming to have something
> impossible, but if you are to believed now, you just had an H that gets
> the wrong answer (according to Linz) about H^, but you never accepted
> Linz's notion of the the right answer should be.
>
> Well, if anyone believes you now, it's clear that I made a mistake in
> taking you are your word. A mistake is not a lie.
>
> For my part, I don't believe you now. I think you meant what you said
> back in 2018. I think you have always known how the halting problem is
> defined, and when you quoted those lines from Linz it was to confirm
> what a halt decider should do.
>
> In other words, I think this is just the latest part of the two and a
> half year walking back of the deluded claims of Dec 2018.
>
> I may, of course, be wrong about this too. The one thing you can know
> for sure is that I have never lied about any of this.
>
>> When P(P) stops running because one of the function calls in its
>> infinite chain of function calls has been aborted this does not make
>> P(P) a halting computation.
>
> I once asked you to confirm that
>
> || (B) Every computation that halts, for whatever reason, is a halting
> || computation.
>
> you said
>
> | OK
>
> Was that a lie? Where you mistaken? Are you playing some strange
> language game in which "P(P) stops running" is not "P(P) halts"? Or are
> you simply saying whatever you need to say in order to keep this
> nonsense going?
>
--
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-20 01:35 +0100 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <877dhlizz2.fsf@bsb.me.uk> |
| In reply to | #36641 |
olcott <NoOne@NoWhere.com> writes:
> You said :
>>>>>> you've told us that your H gets this case wrong:
> You know damn well that I never said that H gets this case wrong.
You know it gets this case wrong, and you told us exactly how and why:
Me: Every computation that halts, for whatever reason, is a halting
computation.
You: OK
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> int main()
> {
> P((u32)P);
> }
>
> The fact is that the above computation never ever halts unless...
The fact is that P(P) halts (according to you). H(P,P) == 0 (according
to you). That is wrong, and you've known it's wrong for a very long
time.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-20 09:22 -0500 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <RP2dnYuABuqLQWv9nZ2dnUU7-I3NnZ2d@giganews.com> |
| In reply to | #36672 |
On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> You said :
>>>>>>> you've told us that your H gets this case wrong:
>> You know damn well that I never said that H gets this case wrong.
>
> You know it gets this case wrong, and you told us exactly how and why:
>
> Me: Every computation that halts, for whatever reason, is a halting
> computation.
>
> You: OK
>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>> The fact is that the above computation never ever halts unless...
>
> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
> to you). That is wrong, and you've known it's wrong for a very long
> time.
>
The above computation that is not under the supervision of H is an
entirely different computation than the one that is under the
supervision of H.
Intuitively it seems that they must be the same yet intuition is simply
incorrect. The fact that their execution trace is different proves that
they are entirely different computations.
H aborts the simulation of its input at the earliest point that its
input demonstrates non-halting behavior.
--
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-20 08:40 -0600 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <sd6n8j$9rv$1@dont-email.me> |
| In reply to | #36702 |
On 2021-07-20 08:22, olcott wrote:
> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> You said :
>>>>>>>> you've told us that your H gets this case wrong:
>>> You know damn well that I never said that H gets this case wrong.
>>
>> You know it gets this case wrong, and you told us exactly how and why:
>>
>> Me: Every computation that halts, for whatever reason, is a halting
>> computation.
>>
>> You: OK
>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>> P((u32)P);
>>> }
>>>
>>> The fact is that the above computation never ever halts unless...
>>
>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>> to you). That is wrong, and you've known it's wrong for a very long
>> time.
>>
>
> The above computation that is not under the supervision of H is an
> entirely different computation than the one that is under the
> supervision of H.
In this case your H is answering the wrong question. A halt decider is
supposed to decide whether its input halts. That means H(P, P) is
supposed to determine whether P(P) halts. It isn't supposed to determine
whether some separate computation, "P(P) being supervised by H" halts.
André
> Intuitively it seems that they must be the same yet intuition is simply
> incorrect. The fact that their execution trace is different proves that
> they are entirely different computations.
>
> H aborts the simulation of its input at the earliest point that its
> input demonstrates non-halting behavior.
>
>
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-20 10:18 -0500 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <FJidndQL-POgdGv9nZ2dnUU7-fvNnZ2d@giganews.com> |
| In reply to | #36705 |
On 7/20/2021 9:40 AM, André G. Isaak wrote:
> On 2021-07-20 08:22, olcott wrote:
>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> You said :
>>>>>>>>> you've told us that your H gets this case wrong:
>>>> You know damn well that I never said that H gets this case wrong.
>>>
>>> You know it gets this case wrong, and you told us exactly how and why:
>>>
>>> Me: Every computation that halts, for whatever reason, is a halting
>>> computation.
>>>
>>> You: OK
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> The fact is that the above computation never ever halts unless...
>>>
>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>> to you). That is wrong, and you've known it's wrong for a very long
>>> time.
>>>
>>
>> The above computation that is not under the supervision of H is an
>> entirely different computation than the one that is under the
>> supervision of H.
>
> In this case your H is answering the wrong question. A halt decider is
> supposed to decide whether its input halts. That means H(P, P) is
> supposed to determine whether P(P) halts. It isn't supposed to determine
> whether some separate computation, "P(P) being supervised by H" halts.
>
> André
>
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
P((u32)P);
}
The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.
_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) H[0] aborts P[2].
[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)
>> Intuitively it seems that they must be the same yet intuition is
>> simply incorrect. The fact that their execution trace is different
>> proves that they are entirely different computations.
>>
>> H aborts the simulation of its input at the earliest point that its
>> input demonstrates non-halting behavior.
>>
>>
>
>
--
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-20 09:29 -0600 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <sd6q4t$2a9$1@dont-email.me> |
| In reply to | #36706 |
On 2021-07-20 09:18, olcott wrote:
> On 7/20/2021 9:40 AM, André G. Isaak wrote:
>> On 2021-07-20 08:22, olcott wrote:
>>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> You said :
>>>>>>>>>> you've told us that your H gets this case wrong:
>>>>> You know damn well that I never said that H gets this case wrong.
>>>>
>>>> You know it gets this case wrong, and you told us exactly how and why:
>>>>
>>>> Me: Every computation that halts, for whatever reason, is a halting
>>>> computation.
>>>>
>>>> You: OK
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> P((u32)P);
>>>>> }
>>>>>
>>>>> The fact is that the above computation never ever halts unless...
>>>>
>>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>>> to you). That is wrong, and you've known it's wrong for a very long
>>>> time.
>>>>
>>>
>>> The above computation that is not under the supervision of H is an
>>> entirely different computation than the one that is under the
>>> supervision of H.
>>
>> In this case your H is answering the wrong question. A halt decider is
>> supposed to decide whether its input halts. That means H(P, P) is
>> supposed to determine whether P(P) halts. It isn't supposed to
>> determine whether some separate computation, "P(P) being supervised by
>> H" halts.
>>
>> André
>>
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> int main()
> {
> P((u32)P);
> }
>
> The fact is that the above computation never ever halts unless some H
> aborts some P thus proving beyond all possible doubt that H[0] does
> correctly decide that P[2] (zero based addressing) never halts.
That's completely non-responsive. You are now claiming that this
computation is entirely different from P(P) run outside of H. If this is
the case, then your H(P, P) isn't answering a question about P(P), but
about some other computation "P(P) being supervised by H".
Why should anyone care about that other computation if it has nothing to
do with P(P) run as an independent computation?
And there's no need to continuously repeat these lengthy partial traces.
We've all already seen them and they don't actually constitute of proof
of anything. When P(P) is run independently, it halts. That's the only
legitimate criteria by which the halting status of P(P) can be
determined. If I post a trace showing how my program calculates that 8*2
equals 17, it doesn't make 8*2 equal to 17.
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pehoushek <pehoushek1@gmail.com> |
|---|---|
| Date | 2021-07-20 09:45 -0700 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <840426a3-c00f-4953-847c-3113f76f75b9n@googlegroups.com> |
| In reply to | #36707 |
+the above computation "never halts unless"
+some H aborts
+some P
+proving that H[0]
+does correctly decide that P[2] (zero based addressing)
+never halts.
vaguely ten negations in ten words or something
my software is about solving polynomial space reasoning
as a twentythree eighty
negation is foreign material to my mentality
i cannot with my mind tell any lie
olcott's crap is so filled
with negations double negations
and blithe universal quantification
that parsing his writing makes me nauseous
but yet i want reviews of my code for bob
so i do troll a little
On Tuesday, July 20, 2021 at 11:29:36 AM UTC-4, André G. Isaak wrote:
> On 2021-07-20 09:18, olcott wrote:
> > On 7/20/2021 9:40 AM, André G. Isaak wrote:
> >> On 2021-07-20 08:22, olcott wrote:
> >>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
> >>>> olcott <No...@NoWhere.com> writes:
> >>>>
> >>>>> You said :
> >>>>>>>>>> you've told us that your H gets this case wrong:
> >>>>> You know damn well that I never said that H gets this case wrong.
> >>>>
> >>>> You know it gets this case wrong, and you told us exactly how and why:
> >>>>
> >>>> Me: Every computation that halts, for whatever reason, is a halting
> >>>> computation.
> >>>>
> >>>> You: OK
> >>>>
> >>>>> void P(u32 x)
> >>>>> {
> >>>>> if (H(x, x))
> >>>>> HERE: goto HERE;
> >>>>> }
> >>>>>
> >>>>> int main()
> >>>>> {
> >>>>> P((u32)P);
> >>>>> }
> >>>>>
> >>>>> The fact is that the above computation never ever halts unless...
> >>>>
> >>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
> >>>> to you). That is wrong, and you've known it's wrong for a very long
> >>>> time.
> >>>>
> >>>
> >>> The above computation that is not under the supervision of H is an
> >>> entirely different computation than the one that is under the
> >>> supervision of H.
> >>
> >> In this case your H is answering the wrong question. A halt decider is
> >> supposed to decide whether its input halts. That means H(P, P) is
> >> supposed to determine whether P(P) halts. It isn't supposed to
> >> determine whether some separate computation, "P(P) being supervised by
> >> H" halts.
> >>
> >> André
> >>
> >
> > void P(u32 x)
> > {
> > if (H(x, x))
> > HERE: goto HERE;
> > }
> >
> > int main()
> > {
> > P((u32)P);
> > }
> >
> > The fact is that the above computation never ever halts unless some H
> > aborts some P thus proving beyond all possible doubt that H[0] does
> > correctly decide that P[2] (zero based addressing) never halts.
> That's completely non-responsive. You are now claiming that this
> computation is entirely different from P(P) run outside of H. If this is
> the case, then your H(P, P) isn't answering a question about P(P), but
> about some other computation "P(P) being supervised by H".
>
> Why should anyone care about that other computation if it has nothing to
> do with P(P) run as an independent computation?
>
> And there's no need to continuously repeat these lengthy partial traces.
> We've all already seen them and they don't actually constitute of proof
> of anything. When P(P) is run independently, it halts. That's the only
> legitimate criteria by which the halting status of P(P) can be
> determined. If I post a trace showing how my program calculates that 8*2
> equals 17, it doesn't make 8*2 equal to 17.
>
> André
> --
> To email remove 'invalid' & replace 'gm' with well known Google mail
> service.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-20 10:33 -0700 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <GNDJI.5266$gE.4586@fx21.iad> |
| In reply to | #36706 |
On 7/20/21 8:18 AM, olcott wrote:
> On 7/20/2021 9:40 AM, André G. Isaak wrote:
>> On 2021-07-20 08:22, olcott wrote:
>>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> You said :
>>>>>>>>>> you've told us that your H gets this case wrong:
>>>>> You know damn well that I never said that H gets this case wrong.
>>>>
>>>> You know it gets this case wrong, and you told us exactly how and why:
>>>>
>>>> Me: Every computation that halts, for whatever reason, is a halting
>>>> computation.
>>>>
>>>> You: OK
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> P((u32)P);
>>>>> }
>>>>>
>>>>> The fact is that the above computation never ever halts unless...
>>>>
>>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>>> to you). That is wrong, and you've known it's wrong for a very long
>>>> time.
>>>>
>>>
>>> The above computation that is not under the supervision of H is an
>>> entirely different computation than the one that is under the
>>> supervision of H.
>>
>> In this case your H is answering the wrong question. A halt decider is
>> supposed to decide whether its input halts. That means H(P, P) is
>> supposed to determine whether P(P) halts. It isn't supposed to
>> determine whether some separate computation, "P(P) being supervised by
>> H" halts.
>>
>> André
>>
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> int main()
> {
> P((u32)P);
> }
>
> The fact is that the above computation never ever halts unless some H
> aborts some P thus proving beyond all possible doubt that H[0] does
> correctly decide that P[2] (zero based addressing) never halts.
You confuse the source code entities with the execution entities.
The Machine P INCLUDES a copy of the algorithm of the machine H.
Note, the since the algorithm of H WILL abort its simulation of P, we
see that P[0] Halts because H(0) aborted its simulation of P(1) and thus
because all identical computation behave the same, we know that P(1)
Would halt if it had not had its simulation stopped (because H(1) would
have also aborted is simulation of P(2)).
Thus EVERY P is a halting computation because the H that is part of it
will abort the simulation of the copy of P that is given to it.
>
> _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) H[0] aborts P[2].
Right, H(0) is part of P(0) so the algorithm of the full Turing machine
P shows that it is a finite computation.
And actually H(0) is aborting its simulation of P(1) not P(2), P(2) is
actually being simulated by H(1) whos trace you aren't showing.
>
> [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
SEE RIGHT HERE P Halted. Thus P(P) is a halting computation BY DEFINITION.
> [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)
>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-21 01:28 +0100 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] |
| Message-ID | <87y2a0ldcq.fsf@bsb.me.uk> |
| In reply to | #36702 |
olcott <NoOne@NoWhere.com> writes:
> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> You said :
>>>>>>>> you've told us that your H gets this case wrong:
>>> You know damn well that I never said that H gets this case wrong.
>> You know it gets this case wrong, and you told us exactly how and why:
>> Me: Every computation that halts, for whatever reason, is a halting
>> computation.
>> You: OK
>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>> P((u32)P);
>>> }
>>>
>>> The fact is that the above computation never ever halts unless...
>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>> to you). That is wrong, and you've known it's wrong for a very long
>> time.
>
> The above computation that is not under the supervision of H is an
> entirely different computation than the one that is under the
> supervision of H.
Of course. But that does not tell me which of the facts are you now
disputing:
(a) P(P) halts.
(b) H(P, P) == 0.
(c) H(P, I) == 0 is only correct if P(I) does not halt.
I hope it's (c) so that we can all ignore what say from now on.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-21 09:48 -0500 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] |
| Message-ID | <sNqdnZ0iReomrmX9nZ2dnUU7-V3NnZ2d@giganews.com> |
| In reply to | #36742 |
On 7/20/2021 7:28 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> You said :
>>>>>>>>> you've told us that your H gets this case wrong:
>>>> You know damn well that I never said that H gets this case wrong.
>>> You know it gets this case wrong, and you told us exactly how and why:
>>> Me: Every computation that halts, for whatever reason, is a halting
>>> computation.
>>> You: OK
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> The fact is that the above computation never ever halts unless...
>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>> to you). That is wrong, and you've known it's wrong for a very long
>>> time.
>>
>> The above computation that is not under the supervision of H is an
>> entirely different computation than the one that is under the
>> supervision of H.
>
> Of course. But that does not tell me which of the facts are you now
> disputing:
>
> (a) P(P) halts.
> (b) H(P, P) == 0.
> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>
> I hope it's (c) so that we can all ignore what say from now on.
>
Even though the outermost P does reach its final state it only reaches
it final state because H correctly decided that its input never halts.
Because of this the argument that the outer P reaches its final state
contradicts that H decided its input correctly DOES NOT HOLD.
There is never a case where H(P,P)==0 is incorrect.
This only applies to people knowing the x86 language:
It can be easily verified that that input to H(P,P) never reaches its
final state whether or not H aborts its simulation of this input.
This conclusively proves that its input never halts thus conclusively
proving that H does correctly decide that this input never halts.
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-21 09:41 -0700 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] |
| Message-ID | <Z6YJI.16211$_fgb.3382@fx01.iad> |
| In reply to | #36777 |
On 7/21/21 7:48 AM, olcott wrote:
> On 7/20/2021 7:28 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> You said :
>>>>>>>>>> you've told us that your H gets this case wrong:
>>>>> You know damn well that I never said that H gets this case wrong.
>>>> You know it gets this case wrong, and you told us exactly how and why:
>>>> Me: Every computation that halts, for whatever reason, is a halting
>>>> computation.
>>>> You: OK
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> P((u32)P);
>>>>> }
>>>>>
>>>>> The fact is that the above computation never ever halts unless...
>>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>>> to you). That is wrong, and you've known it's wrong for a very long
>>>> time.
>>>
>>> The above computation that is not under the supervision of H is an
>>> entirely different computation than the one that is under the
>>> supervision of H.
>>
>> Of course. But that does not tell me which of the facts are you now
>> disputing:
>>
>> (a) P(P) halts.
>> (b) H(P, P) == 0.
>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>
>> I hope it's (c) so that we can all ignore what say from now on.
>>
>
> Even though the outermost P does reach its final state it only reaches
> it final state because H correctly decided that its input never halts.
It reaches its final halting state because H decided to halt its
simulation. This doesn't make it right. H is what H is. Change H and you
get a DIFFERENT P. ANY argument based on changing the H that P is built
on doesn't say anything about that original P, and thus is unsound to
prove what that original P does.
That P(P) reaches a Halting state is ALL that is needed to PROVE that
P(P) is a Halting Computation.
Yes, the other P built on an H that doesn't abort is non-halting, but
that is a different P.
>
> Because of this the argument that the outer P reaches its final state
> contradicts that H decided its input correctly DOES NOT HOLD.
>
Why? The DEFINITION of a Halting Computation is one that reaches a
Halting State in a finite number of steps. P(P) does this, so it IS a
Halting Computation. Where
> There is never a case where H(P,P)==0 is incorrect.
WRONG. By this same logic I can say there is never a case where Peter
Olcott is correct.
>
> This only applies to people knowing the x86 language:
> It can be easily verified that that input to H(P,P) never reaches its
> final state whether or not H aborts its simulation of this input.
>
Yes, you can show that unless H does abort some simulation then P will
not halt, which shows that we have two classes. So we can divide the
classes of H into Hn that doesn't abort its Pn and Ha that does abort
its Pa.
By your proof, Pn is a non-halting Computation, but Hn won't be able to
return an answer to say that Pn is non-Halting so is still wrong.
Pa on the other hand, IS a Halting computation becaue Ha will abort its
simulation and return non-halting to Pa and Pa will then Halt. (And thus
Ha is wrong).
You logic does show that Ha can correctly decide that Pn is non-halting,
but that isn't the case you need to show, so doesn't advance your proof.
> This conclusively proves that its input never halts thus conclusively
> proving that H does correctly decide that this input never halts.
No, it just proves that H never runs its simulation far enough to get to
the point where the machine it is simulating will halt.
Since P IS a computation, and P(P) as the top level computation reaches
a Halting state in finite time, ALL copies of P(P) will reach a halting
state in exactly that same number of steps (which is more than H will
simulate).
You claim that P(P) Halting as a top level computation doesn't show that
P(P) is a Halting Computation is just a totally ridiculous claim that
violates the plain definition of Halting.
As BEST, it shows that you logic is inconsistent, as you can prove
something and its converse.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-22 01:12 +0100 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] |
| Message-ID | <87bl6vjjed.fsf@bsb.me.uk> |
| In reply to | #36777 |
olcott <NoOne@NoWhere.com> writes:
> On 7/20/2021 7:28 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> You said :
>>>>>>>>>> you've told us that your H gets this case wrong:
>>>>> You know damn well that I never said that H gets this case wrong.
>>>> You know it gets this case wrong, and you told us exactly how and why:
>>>> Me: Every computation that halts, for whatever reason, is a halting
>>>> computation.
>>>> You: OK
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> P((u32)P);
>>>>> }
>>>>>
>>>>> The fact is that the above computation never ever halts unless...
>>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>>> to you). That is wrong, and you've known it's wrong for a very long
>>>> time.
>>>
>>> The above computation that is not under the supervision of H is an
>>> entirely different computation than the one that is under the
>>> supervision of H.
>> Of course. But that does not tell me which of the facts are you now
>> disputing:
>> (a) P(P) halts.
>> (b) H(P, P) == 0.
>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>> I hope it's (c) so that we can all ignore what say from now on.
>
> Even though the outermost P does reach its final state
P(P) halts. You agree with (a). Not surprising since you've told us
P(P) halts many times.
> it only reaches it final state because H correctly decided that its
> input never halts.
So you agree with (b) that H(P, P) == 0. Again, not really news as
you've said it before.
> Because of this the argument that the outer P reaches its final state
> contradicts that H decided its input correctly DOES NOT HOLD.
So you disagree that H(P, I) == 0 is only correct if P(I) does not halt,
i.e. you disagree with the basic fact of what a halt decider is. Again,
not surprising you've ducked and dived and squirmed and wriggled to
avoid agreeing to this simple of the problem.
This is just simple dishonesty. You keep quoting Linz so you know what
a halt decider should do. You once claimed to have an H "exactly and
precisely as in Linz" (we'll never see that TM will we?). When you post
those lines from Linz you don't say "but this is wrong, H can reject
some halting computations". You disingenuously present them as the
definition of a halt decider with which you tacitly agree.
And it's not just when you quote Linz that you are being disingenuous.
I once presented a challenge with exactly the above notion of what a
halt decider is. Did you say "I disagree that H(P, I) == 0 is only
correct if P(I) does not halt"? No, you just waffled and then pretended
to meet the challenge by posting a code sketch for a function called
Halts that got the answer wrong. I think you've know for ages that you
must hide the fact that you are not talking about proper halting.
You must know by now that you have nothing -- just a
function/TM/algorithm that does not meet the basic definition of being a
halt decider. How many years have you wasted to get this
not-a-halt-decider?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-21 20:27 -0500 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] |
| Message-ID | <GbOdnW1mY4oOVGX9nZ2dnUU7-QnNnZ2d@giganews.com> |
| In reply to | #36822 |
On 7/21/2021 7:12 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/20/2021 7:28 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> You said :
>>>>>>>>>>> you've told us that your H gets this case wrong:
>>>>>> You know damn well that I never said that H gets this case wrong.
>>>>> You know it gets this case wrong, and you told us exactly how and why:
>>>>> Me: Every computation that halts, for whatever reason, is a halting
>>>>> computation.
>>>>> You: OK
>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> P((u32)P);
>>>>>> }
>>>>>>
>>>>>> The fact is that the above computation never ever halts unless...
>>>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>>>> to you). That is wrong, and you've known it's wrong for a very long
>>>>> time.
>>>>
>>>> The above computation that is not under the supervision of H is an
>>>> entirely different computation than the one that is under the
>>>> supervision of H.
>>> Of course. But that does not tell me which of the facts are you now
>>> disputing:
>>> (a) P(P) halts.
>>> (b) H(P, P) == 0.
>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>> I hope it's (c) so that we can all ignore what say from now on.
>>
>> Even though the outermost P does reach its final state
>
> P(P) halts. You agree with (a). Not surprising since you've told us
> P(P) halts many times.
>
>> it only reaches it final state because H correctly decided that its
>> input never halts.
>
> So you agree with (b) that H(P, P) == 0. Again, not really news as
> you've said it before.
>
>> Because of this the argument that the outer P reaches its final state
>> contradicts that H decided its input correctly DOES NOT HOLD.
>
> So you disagree that H(P, I) == 0 is only correct if P(I) does not halt,
> i.e. you disagree with the basic fact of what a halt decider is. Again,
> not surprising you've ducked and dived and squirmed and wriggled to
> avoid agreeing to this simple of the problem.
>
> This is just simple dishonesty. You keep quoting Linz so you know what
> a halt decider should do. You once claimed to have an H "exactly and
> precisely as in Linz" (we'll never see that TM will we?). When you post
> those lines from Linz you don't say "but this is wrong, H can reject
> some halting computations". You disingenuously present them as the
> definition of a halt decider with which you tacitly agree.
>
> And it's not just when you quote Linz that you are being disingenuous.
> I once presented a challenge with exactly the above notion of what a
> halt decider is. Did you say "I disagree that H(P, I) == 0 is only
> correct if P(I) does not halt"? No, you just waffled and then pretended
> to meet the challenge by posting a code sketch for a function called
> Halts that got the answer wrong. I think you've know for ages that you
> must hide the fact that you are not talking about proper halting.
>
> You must know by now that you have nothing -- just a
> function/TM/algorithm that does not meet the basic definition of being a
> halt decider. How many years have you wasted to get this
> not-a-halt-decider?
>
I did not even glance at any of the words of that because it all
pertains to a view that has been superseded and greatly improved:
I explained that H <is> a x86 pure simulator of its input until after it
makes its halt status decision. From this one detail we can know that
this source-code of P specifies infinitely nested simulation at its
machine address c30.
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]
--
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 18:37 -0700 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] |
| Message-ID | <GZ3KI.9637$wG6.6624@fx18.iad> |
| In reply to | #36824 |
On 7/21/21 6:27 PM, olcott wrote:
> On 7/21/2021 7:12 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/20/2021 7:28 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> You said :
>>>>>>>>>>>> you've told us that your H gets this case wrong:
>>>>>>> You know damn well that I never said that H gets this case wrong.
>>>>>> You know it gets this case wrong, and you told us exactly how and
>>>>>> why:
>>>>>> Me: Every computation that halts, for whatever reason, is a halting
>>>>>> computation.
>>>>>> You: OK
>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> P((u32)P);
>>>>>>> }
>>>>>>>
>>>>>>> The fact is that the above computation never ever halts unless...
>>>>>> The fact is that P(P) halts (according to you). H(P,P) == 0
>>>>>> (according
>>>>>> to you). That is wrong, and you've known it's wrong for a very long
>>>>>> time.
>>>>>
>>>>> The above computation that is not under the supervision of H is an
>>>>> entirely different computation than the one that is under the
>>>>> supervision of H.
>>>> Of course. But that does not tell me which of the facts are you now
>>>> disputing:
>>>> (a) P(P) halts.
>>>> (b) H(P, P) == 0.
>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>> I hope it's (c) so that we can all ignore what say from now on.
>>>
>>> Even though the outermost P does reach its final state
>>
>> P(P) halts. You agree with (a). Not surprising since you've told us
>> P(P) halts many times.
>>
>>> it only reaches it final state because H correctly decided that its
>>> input never halts.
>>
>> So you agree with (b) that H(P, P) == 0. Again, not really news as
>> you've said it before.
>>
>>> Because of this the argument that the outer P reaches its final state
>>> contradicts that H decided its input correctly DOES NOT HOLD.
>>
>> So you disagree that H(P, I) == 0 is only correct if P(I) does not halt,
>> i.e. you disagree with the basic fact of what a halt decider is. Again,
>> not surprising you've ducked and dived and squirmed and wriggled to
>> avoid agreeing to this simple of the problem.
>>
>> This is just simple dishonesty. You keep quoting Linz so you know what
>> a halt decider should do. You once claimed to have an H "exactly and
>> precisely as in Linz" (we'll never see that TM will we?). When you post
>> those lines from Linz you don't say "but this is wrong, H can reject
>> some halting computations". You disingenuously present them as the
>> definition of a halt decider with which you tacitly agree.
>>
>> And it's not just when you quote Linz that you are being disingenuous.
>> I once presented a challenge with exactly the above notion of what a
>> halt decider is. Did you say "I disagree that H(P, I) == 0 is only
>> correct if P(I) does not halt"? No, you just waffled and then pretended
>> to meet the challenge by posting a code sketch for a function called
>> Halts that got the answer wrong. I think you've know for ages that you
>> must hide the fact that you are not talking about proper halting.
>>
>> You must know by now that you have nothing -- just a
>> function/TM/algorithm that does not meet the basic definition of being a
>> halt decider. How many years have you wasted to get this
>> not-a-halt-decider?
>>
>
> I did not even glance at any of the words of that because it all
> pertains to a view that has been superseded and greatly improved:
>
> I explained that H <is> a x86 pure simulator of its input until after it
> makes its halt status decision. From this one detail we can know that
> this source-code of P specifies infinitely nested simulation at its
> machine address c30.
WRONG. DISPROVEN, and you KNOW it.
UNSOUND LOGIC.
I won't bother explaining why, since you won't read it anyway.
>
> 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 | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-21 20:49 -0500 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] |
| Message-ID | <J7ydnVeb86gBU2X9nZ2dnUU7-SPNnZ2d@giganews.com> |
| In reply to | #36825 |
On 7/21/2021 8:37 PM, Richard Damon wrote:
> On 7/21/21 6:27 PM, olcott wrote:
>> On 7/21/2021 7:12 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/20/2021 7:28 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> You said :
>>>>>>>>>>>>> you've told us that your H gets this case wrong:
>>>>>>>> You know damn well that I never said that H gets this case wrong.
>>>>>>> You know it gets this case wrong, and you told us exactly how and
>>>>>>> why:
>>>>>>> Me: Every computation that halts, for whatever reason, is a halting
>>>>>>> computation.
>>>>>>> You: OK
>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> P((u32)P);
>>>>>>>> }
>>>>>>>>
>>>>>>>> The fact is that the above computation never ever halts unless...
>>>>>>> The fact is that P(P) halts (according to you). H(P,P) == 0
>>>>>>> (according
>>>>>>> to you). That is wrong, and you've known it's wrong for a very long
>>>>>>> time.
>>>>>>
>>>>>> The above computation that is not under the supervision of H is an
>>>>>> entirely different computation than the one that is under the
>>>>>> supervision of H.
>>>>> Of course. But that does not tell me which of the facts are you now
>>>>> disputing:
>>>>> (a) P(P) halts.
>>>>> (b) H(P, P) == 0.
>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>> I hope it's (c) so that we can all ignore what say from now on.
>>>>
>>>> Even though the outermost P does reach its final state
>>>
>>> P(P) halts. You agree with (a). Not surprising since you've told us
>>> P(P) halts many times.
>>>
>>>> it only reaches it final state because H correctly decided that its
>>>> input never halts.
>>>
>>> So you agree with (b) that H(P, P) == 0. Again, not really news as
>>> you've said it before.
>>>
>>>> Because of this the argument that the outer P reaches its final state
>>>> contradicts that H decided its input correctly DOES NOT HOLD.
>>>
>>> So you disagree that H(P, I) == 0 is only correct if P(I) does not halt,
>>> i.e. you disagree with the basic fact of what a halt decider is. Again,
>>> not surprising you've ducked and dived and squirmed and wriggled to
>>> avoid agreeing to this simple of the problem.
>>>
>>> This is just simple dishonesty. You keep quoting Linz so you know what
>>> a halt decider should do. You once claimed to have an H "exactly and
>>> precisely as in Linz" (we'll never see that TM will we?). When you post
>>> those lines from Linz you don't say "but this is wrong, H can reject
>>> some halting computations". You disingenuously present them as the
>>> definition of a halt decider with which you tacitly agree.
>>>
>>> And it's not just when you quote Linz that you are being disingenuous.
>>> I once presented a challenge with exactly the above notion of what a
>>> halt decider is. Did you say "I disagree that H(P, I) == 0 is only
>>> correct if P(I) does not halt"? No, you just waffled and then pretended
>>> to meet the challenge by posting a code sketch for a function called
>>> Halts that got the answer wrong. I think you've know for ages that you
>>> must hide the fact that you are not talking about proper halting.
>>>
>>> You must know by now that you have nothing -- just a
>>> function/TM/algorithm that does not meet the basic definition of being a
>>> halt decider. How many years have you wasted to get this
>>> not-a-halt-decider?
>>>
>>
>> I did not even glance at any of the words of that because it all
>> pertains to a view that has been superseded and greatly improved:
>>
>> I explained that H <is> a x86 pure simulator of its input until after it
>> makes its halt status decision. From this one detail we can know that
>> this source-code of P specifies infinitely nested simulation at its
>> machine address c30.
>
> WRONG. DISPROVEN, and you KNOW it.
>
> UNSOUND LOGIC.
>
> I won't bother explaining why, since you won't read it anyway.
>
I don't respond to you because you almost always never pay any attention
to what I am saying at all unless I repeat it at least 50 times.
--
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 19:01 -0700 |
| Subject | Re: Halting Problem Solved [ Ben admits that he lied ] [ H(P,P)==0 is correct ] |
| Message-ID | <pk4KI.28797$qk6.6043@fx36.iad> |
| In reply to | #36827 |
On 7/21/21 6:49 PM, olcott wrote: > On 7/21/2021 8:37 PM, Richard Damon wrote: >> WRONG. DISPROVEN, and you KNOW it. >> >> UNSOUND LOGIC. >> >> I won't bother explaining why, since you won't read it anyway. >> > > I don't respond to you because you almost always never pay any attention > to what I am saying at all unless I repeat it at least 50 times. > > I think you don't want to respond to me because a clearly point out the errors in your logic. Your whole argument is failed. It is clear that you aren't going to learn anything by trying to 'discuss' it, as you aren't really reading what people are saying. I will say it again, maybe you just need to write your paper and submit it and get it rejected (as you KNOW it will be). You fundamentally reject the principles of Sound Logic and are into some strange gobbledygook that claims to be based on the meaning of words, but which doesn't REALLY work with consistent meanings. Your whole logic system has long ago been proven unusable with its internal inconsistency, but that doesn't seem to bother you. Maybe you shouldn't be aiming the paper for a Journal on Mathemeatics or Computer Theory, but for some Philosophical rag that doesn't really care about actual proof but just wants a mixed up argument. Those people might fall for your drivel.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-22 02:49 +0100 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <87wnpji0dn.fsf_-_@bsb.me.uk> |
| In reply to | #36824 |
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.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-21 20:57 -0500 |
| Subject | Re: Halting Problem Solved |
| Message-ID | <BtmdncOmW_HjTWX9nZ2dnUU7-IPNnZ2d@giganews.com> |
| In reply to | #36826 |
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.
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]
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.theory
csiph-web