Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #166629 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2022-07-11 00:44 -0500 |
| Last post | 2022-07-13 11:25 -0700 |
| Articles | 20 on this page of 74 — 21 participants |
Back to article view | Back to comp.lang.c
"C: Everyone's favourite programming language isn't a programming language" Lynn McGuire <lynnmcguire5@gmail.com> - 2022-07-11 00:44 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-11 09:33 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-11 00:58 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-11 15:39 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" Ben Collver <bencollver@tilde.pink> - 2022-07-11 14:17 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" scott@slp53.sl.home (Scott Lurndal) - 2022-07-11 14:38 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Thiago Adams <thiago.adams@gmail.com> - 2022-07-11 10:48 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" scott@slp53.sl.home (Scott Lurndal) - 2022-07-11 20:59 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Mark Bluemel <mark.bluemel@gmail.com> - 2022-07-11 03:28 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Lynn McGuire <lynnmcguire5@gmail.com> - 2022-07-11 14:24 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Michael S <already5chosen@yahoo.com> - 2022-07-11 12:40 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Lynn McGuire <lynnmcguire5@gmail.com> - 2022-07-11 19:34 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Michael S <already5chosen@yahoo.com> - 2022-07-12 12:33 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Albert Arkwright <Albert.Arkwright@gmail.com> - 2022-07-11 22:13 +0100
H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-11 18:14 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Freethinker <freethinker@mymail.com> - 2022-07-12 16:14 +0200
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-12 20:49 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-12 22:26 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-12 21:29 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-12 22:39 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-12 21:52 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 07:51 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 07:19 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-13 18:27 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 19:51 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 19:06 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 21:20 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 20:34 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 21:55 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 21:08 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 22:21 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 21:55 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 05:18 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 23:27 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 07:53 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-14 05:43 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 07:08 -0400
Re: H(P,P) is pure software engineering that correctly refutes the Muttley@dastardlyhq.com - 2022-07-14 16:06 +0000
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 23:29 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 07:52 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-14 05:49 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 07:12 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 17:48 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 07:07 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem om@iki.fi (Otto J. Makela) - 2022-07-18 17:51 +0300
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 22:29 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-13 19:41 -0700
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Jens Schweikhardt <usenet@schweikhardt.net> - 2022-07-13 21:08 +0000
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 19:33 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Freethinker <freethinker@mymail.com> - 2022-07-14 23:46 +0200
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-14 17:04 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Juha Nieminen <nospam@thanks.invalid> - 2022-07-12 09:52 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Vir Campestris <vir.campestris@invalid.invalid> - 2022-07-12 11:27 +0100
Re: "C: Everyone's favourite programming language isn't a programming language" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-12 13:01 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Manu Raju <MR@invalid.invalid> - 2022-07-12 22:19 +0100
Re: "C: Everyone's favourite programming language isn't a programming language" [Olcott] olcott <NoOne@NoWhere.com> - 2022-07-12 21:04 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Juha Nieminen <nospam@thanks.invalid> - 2022-07-13 10:02 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Muttley@dastardlyhq.com - 2022-07-13 15:24 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Manu Raju <MR@invalid.invalid> - 2022-07-13 19:00 +0100
Re: "C: Everyone's favourite programming language isn't a programming language" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-13 15:31 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-12 14:29 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-12 14:46 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" olcott <NoOne@NoWhere.com> - 2022-07-12 07:48 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Richard Damon <Richard@Damon-Family.org> - 2022-07-12 21:45 -0400
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-17 08:18 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" olcott <NoOne@NoWhere.com> - 2022-07-12 07:45 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Richard Damon <Richard@Damon-Family.org> - 2022-07-12 21:39 -0400
Re: "C: Everyone's favourite programming language isn't a programming language" olcott <NoOne@NoWhere.com> - 2022-07-12 07:45 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Mark Bluemel <mark.bluemel@gmail.com> - 2022-07-12 02:56 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-12 11:01 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Lynn McGuire <lynnmcguire5@gmail.com> - 2022-07-12 13:54 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Mark Bluemel <mark.bluemel@gmail.com> - 2022-07-13 01:13 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-13 10:23 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" pure SE - Olcott <polcott2@gmail.com> - 2022-07-13 11:25 -0700
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-14 05:49 -0500 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <TPqdnZvCw81MaVL_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #166702 |
On 7/14/2022 1:52 AM, Mr Flibble wrote:
> On Wed, 13 Jul 2022 23:29:53 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/13/2022 11:18 PM, Mr Flibble wrote:
>>> On Wed, 13 Jul 2022 21:55:25 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/13/2022 9:21 PM, Richard Damon wrote:
>>>>>
>>>>> On 7/13/22 10:08 PM, olcott wrote:
>>>>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
>>>>>>> On 7/13/22 9:34 PM, olcott wrote:
>>>>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 7/13/22 8:06 PM, olcott wrote:
>>>>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
>>>>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
>>>>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this
>>>>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months ago
>>>>>>>>>>>>>>>>>>>>>> when the article came out.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot
>>>>>>>>>>>>>>>>>>>>> called Olcott? He keeps
>>>>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there
>>>>>>>>>>>>>>>>>>>>> are two guys here who
>>>>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing
>>>>>>>>>>>>>>>>>>>>> him.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a
>>>>>>>>>>>>>>>>>>>>> response; Olcott won't go
>>>>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him
>>>>>>>>>>>>>>>>>>>>> completely. Just ignore him;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated
>>>>>>>>>>>>>>>>>>>> whether or not anyone responds. I just had a very
>>>>>>>>>>>>>>>>>>>> extensive review (23 emails) by a leading computer
>>>>>>>>>>>>>>>>>>>> scientist.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my
>>>>>>>>>>>>>>>>>>>> presentation so that everyone here can easily
>>>>>>>>>>>>>>>>>>>> verify that I have correctly refuted the halting
>>>>>>>>>>>>>>>>>>>> theorem on this pure software engineering basis:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> OK, so now that we have easily verified that, would
>>>>>>>>>>>>>>>>>>> you please stop posting this same thing millions of
>>>>>>>>>>>>>>>>>>> times?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For any program H that might determine if programs
>>>>>>>>>>>>>>>>>> halt, a "pathological" program P, called with some
>>>>>>>>>>>>>>>>>> input, can pass its own source and its input to H and
>>>>>>>>>>>>>>>>>> then specifically do the opposite of what H predicts
>>>>>>>>>>>>>>>>>> P will do. *No H can exist that handles this case*
>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is not verified until it is understood that P and
>>>>>>>>>>>>>>>>>> H implement the classical halting problem "impossible
>>>>>>>>>>>>>>>>>> input" template (as shown above) and refutes this
>>>>>>>>>>>>>>>>>> template in that H(P,P) correctly determines that its
>>>>>>>>>>>>>>>>>> input never terminates normally.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *This is the key software engineering that I need
>>>>>>>>>>>>>>>>>> validated* Most anyone here can easily verify that
>>>>>>>>>>>>>>>>>> the simulated input to H(P,P) cannot possibly
>>>>>>>>>>>>>>>>>> terminate normally.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The next level of pure software engineering is that
>>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input
>>>>>>>>>>>>>>>>>> cannot possibly terminate normally. It may be the
>>>>>>>>>>>>>>>>>> case that only the top 5% of software engineers can
>>>>>>>>>>>>>>>>>> validate this point.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Simulating halt decider H detects that its simulated
>>>>>>>>>>>>>>>>>> input is essentially calling H in infinite recursion.
>>>>>>>>>>>>>>>>>> H aborts its simulation on this basis and rejects
>>>>>>>>>>>>>>>>>> this input as non-halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The execution trace of function P() simulated by
>>>>>>>>>>>>>>>>>> function H() shows:
>>>>>>>>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly
>>>>>>>>>>>>>>>>>> escape this infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *That was all of the software engineering that I need
>>>>>>>>>>>>>>>>>> validated*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of
>>>>>>>>>>>>>>>>>> software engineering
>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And your property (3) is incorrect the way you use it.
>>>>>>>>>>>>>>>>> The CORRECT version of (3) looks ALL the way through
>>>>>>>>>>>>>>>>> the loop, which includes in H, and will find the
>>>>>>>>>>>>>>>>> condtional there.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot
>>>>>>>>>>>>>>>> possibly terminate normally. (I have better words now).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except that the program represented by the input, P(P)
>>>>>>>>>>>>>>> DOES terminate normally if H(P,P) returns 0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
>>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
>>>>>>>>>>>>>> its correctly simulated input cannot possibly terminate
>>>>>>>>>>>>>> normally.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WHAT Change of subject?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> IT IS A VERIFIED FACT THAT
>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>>>>>>> correctly
>>>>>>>>>>>> simulated input cannot possibly terminate normally.
>>>>>>>>>>>>
>>>>>>>>>>>> The only possible correct rebuttal must show all the steps
>>>>>>>>>>>> of exactly how the input to simulating halt decider H(P,P)
>>>>>>>>>>>> does terminate normally when H correctly simulates this
>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> Since I already proved that this is false entirely on the
>>>>>>>>>>>> basis of verified fact this is impossible.
>>>>>>>>>>>>
>>>>>>>>>>>> This requires that a function called in essentially
>>>>>>>>>>>> infinite recursion to return a value to its caller this is
>>>>>>>>>>>> impossible.
>>>>>>>>>>>>
>>>>>>>>>>>> Most everyone here knows that every function called in
>>>>>>>>>>>> infinite recursion never returns any value to its caller.
>>>>>>>>>>>> There is no gibberish that you can say that would convince
>>>>>>>>>>>> them otherwise.
>>>>>>>>>>> That can't be a verified fact because the opposite is a
>>>>>>>>>>> verified fact, that the CORRECT simulation of the input to
>>>>>>>>>>> H(P,P), which is the correct simulation of P(P) will
>>>>>>>>>>> actually Halt if H(P,P) returns 0, as you claim it does.
>>>>>>>>>>
>>>>>>>>>> I already gave Paul N a great explanation of that on
>>>>>>>>>> comp.theory. I won't be able to see your reply there because
>>>>>>>>>> I have you blocked there.
>>>>>>>>>>
>>>>>>>>>> My explanation to wjj even sums it up better:
>>>>>>>>>>
>>>>>>>>>> On 7/13/2022 3:51 PM, olcott wrote:
>>>>>>>>>> > On 7/13/2022 3:47 PM, wij wrote:
>>>>>>>>>> >> The property that an arbitrary program P will finish
>>>>>>>>>> >> running or not is determined by running P as an
>>>>>>>>>> >> independent program
>>>>>>>>>>
>>>>>>>>>> Because that would require that a halt decider must sometimes
>>>>>>>>>> make its
>>>>>>>>>> halt status decision on a basis other than the actual
>>>>>>>>>> behavior of its actual input that long standing
>>>>>>>>>> misconception has been refuted.
>>>>>>>>>
>>>>>>>>> No, because all the behavior of that program exists will be
>>>>>>>>> encoded in the representation of the program given to the
>>>>>>>>> decider.
>>>>>>>>
>>>>>>>> The reason that I stop talking to you is that you make false
>>>>>>>> assumptions that are utterly impervious to all reasoning.
>>>>>>>>
>>>>>>>> It is a verified fact that the input that is correctly
>>>>>>>> simulated by H(P,P) cannot possibly terminate normally. It is
>>>>>>>> also a verified fact that the direct execution of P(P) does
>>>>>>>> terminate normally.
>>>>>>>>
>>>>>>>> It is also common knowledge that the correct simulation of a
>>>>>>>> program is a correct measure of the behavior of this program.
>>>>>>>>
>>>>>>>> This conclusively proves that H(P,P) is correct to reject its
>>>>>>>> input as non-halting and the behavior of a non-input cannot
>>>>>>>> possibly contradict this.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly
>>>>>>> simulate the input (since it aborts it to return 0) so it
>>>>>>> doesn't MATTER that if it was a different program it wouldn't
>>>>>>> be able to simulate to a final state.
>>>>>>
>>>>>>
>>>>>> That you (and others) continue to lack the technical capacity to
>>>>>> comprehend that H does correctly predict that its complete and
>>>>>> correct simulation of its input would never result in this input
>>>>>> terminating normally is far less than no rebuttal at all. Until
>>>>>> you (and others) gain this technical capacity there is no sense
>>>>>> continuing a dialogue.
>>>>>
>>>>> How is it correct when H(P,P) sayts P(P) is non-halting when a
>>>>> direct exectuion of P(P) or a correct simulation by simualte(P,P)
>>>>> (where P still calls the previous H) show that it halts.
>>>>
>>>> Most everyone here can see: (from my updated simplified paper)
>>>> It is a verified fact that the input that is correctly simulated by
>>>> H(P,P) cannot possibly terminate normally.
>>>
>>> I have shown that a simulating halting decider needn't be recursive
>>> in nature thus can terminate normally. You are wrong on all fronts.
>>>
>>> /Flibble
>>>
>>
>> You have shown that you don't fully understand the concept of
>> unreachable code.
>
> Of course I understand the concept of unreachable code in fact I recall
> giving you several examples of it.
>
> /Flibble
>
I did not say that you have no idea what unreachable code is, you simply
do not understand that infinite recursion prevents all the code below
the infinitely recursive function call to ever be reached.
There are a sequence of many posts that prove this where you believe
that removing the infinite loop eliminates the pathological relationship.
You and Richard are at the bottom 10% of technical competence in this
forum most everyone else could validate that I am correct.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-14 07:12 -0400 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <ISSzK.95514$%i2.19303@fx48.iad> |
| In reply to | #166705 |
On 7/14/22 6:49 AM, olcott wrote:
> On 7/14/2022 1:52 AM, Mr Flibble wrote:
>> On Wed, 13 Jul 2022 23:29:53 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 7/13/2022 11:18 PM, Mr Flibble wrote:
>>>> On Wed, 13 Jul 2022 21:55:25 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 7/13/2022 9:21 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/13/22 10:08 PM, olcott wrote:
>>>>>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
>>>>>>>> On 7/13/22 9:34 PM, olcott wrote:
>>>>>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 7/13/22 8:06 PM, olcott wrote:
>>>>>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
>>>>>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
>>>>>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>>>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this
>>>>>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months ago
>>>>>>>>>>>>>>>>>>>>>>> when the article came out.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot
>>>>>>>>>>>>>>>>>>>>>> called Olcott? He keeps
>>>>>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there
>>>>>>>>>>>>>>>>>>>>>> are two guys here who
>>>>>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing
>>>>>>>>>>>>>>>>>>>>>> him.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a
>>>>>>>>>>>>>>>>>>>>>> response; Olcott won't go
>>>>>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him
>>>>>>>>>>>>>>>>>>>>>> completely. Just ignore him;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated
>>>>>>>>>>>>>>>>>>>>> whether or not anyone responds. I just had a very
>>>>>>>>>>>>>>>>>>>>> extensive review (23 emails) by a leading computer
>>>>>>>>>>>>>>>>>>>>> scientist.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my
>>>>>>>>>>>>>>>>>>>>> presentation so that everyone here can easily
>>>>>>>>>>>>>>>>>>>>> verify that I have correctly refuted the halting
>>>>>>>>>>>>>>>>>>>>> theorem on this pure software engineering basis:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> OK, so now that we have easily verified that, would
>>>>>>>>>>>>>>>>>>>> you please stop posting this same thing millions of
>>>>>>>>>>>>>>>>>>>> times?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For any program H that might determine if programs
>>>>>>>>>>>>>>>>>>> halt, a "pathological" program P, called with some
>>>>>>>>>>>>>>>>>>> input, can pass its own source and its input to H and
>>>>>>>>>>>>>>>>>>> then specifically do the opposite of what H predicts
>>>>>>>>>>>>>>>>>>> P will do. *No H can exist that handles this case*
>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is not verified until it is understood that P and
>>>>>>>>>>>>>>>>>>> H implement the classical halting problem "impossible
>>>>>>>>>>>>>>>>>>> input" template (as shown above) and refutes this
>>>>>>>>>>>>>>>>>>> template in that H(P,P) correctly determines that its
>>>>>>>>>>>>>>>>>>> input never terminates normally.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *This is the key software engineering that I need
>>>>>>>>>>>>>>>>>>> validated* Most anyone here can easily verify that
>>>>>>>>>>>>>>>>>>> the simulated input to H(P,P) cannot possibly
>>>>>>>>>>>>>>>>>>> terminate normally.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The next level of pure software engineering is that
>>>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input
>>>>>>>>>>>>>>>>>>> cannot possibly terminate normally. It may be the
>>>>>>>>>>>>>>>>>>> case that only the top 5% of software engineers can
>>>>>>>>>>>>>>>>>>> validate this point.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Simulating halt decider H detects that its simulated
>>>>>>>>>>>>>>>>>>> input is essentially calling H in infinite recursion.
>>>>>>>>>>>>>>>>>>> H aborts its simulation on this basis and rejects
>>>>>>>>>>>>>>>>>>> this input as non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The execution trace of function P() simulated by
>>>>>>>>>>>>>>>>>>> function H() shows:
>>>>>>>>>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly
>>>>>>>>>>>>>>>>>>> escape this infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *That was all of the software engineering that I need
>>>>>>>>>>>>>>>>>>> validated*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of
>>>>>>>>>>>>>>>>>>> software engineering
>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And your property (3) is incorrect the way you use it.
>>>>>>>>>>>>>>>>>> The CORRECT version of (3) looks ALL the way through
>>>>>>>>>>>>>>>>>> the loop, which includes in H, and will find the
>>>>>>>>>>>>>>>>>> condtional there.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot
>>>>>>>>>>>>>>>>> possibly terminate normally. (I have better words now).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that the program represented by the input, P(P)
>>>>>>>>>>>>>>>> DOES terminate normally if H(P,P) returns 0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
>>>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
>>>>>>>>>>>>>>> its correctly simulated input cannot possibly terminate
>>>>>>>>>>>>>>> normally.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WHAT Change of subject?
>>>>>>>>>>>>>
>>>>>>>>>>>>> IT IS A VERIFIED FACT THAT
>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated input cannot possibly terminate normally.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only possible correct rebuttal must show all the steps
>>>>>>>>>>>>> of exactly how the input to simulating halt decider H(P,P)
>>>>>>>>>>>>> does terminate normally when H correctly simulates this
>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since I already proved that this is false entirely on the
>>>>>>>>>>>>> basis of verified fact this is impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This requires that a function called in essentially
>>>>>>>>>>>>> infinite recursion to return a value to its caller this is
>>>>>>>>>>>>> impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Most everyone here knows that every function called in
>>>>>>>>>>>>> infinite recursion never returns any value to its caller.
>>>>>>>>>>>>> There is no gibberish that you can say that would convince
>>>>>>>>>>>>> them otherwise.
>>>>>>>>>>>> That can't be a verified fact because the opposite is a
>>>>>>>>>>>> verified fact, that the CORRECT simulation of the input to
>>>>>>>>>>>> H(P,P), which is the correct simulation of P(P) will
>>>>>>>>>>>> actually Halt if H(P,P) returns 0, as you claim it does.
>>>>>>>>>>>
>>>>>>>>>>> I already gave Paul N a great explanation of that on
>>>>>>>>>>> comp.theory. I won't be able to see your reply there because
>>>>>>>>>>> I have you blocked there.
>>>>>>>>>>>
>>>>>>>>>>> My explanation to wjj even sums it up better:
>>>>>>>>>>>
>>>>>>>>>>> On 7/13/2022 3:51 PM, olcott wrote:
>>>>>>>>>>> > On 7/13/2022 3:47 PM, wij wrote:
>>>>>>>>>>> >> The property that an arbitrary program P will finish
>>>>>>>>>>> >> running or not is determined by running P as an
>>>>>>>>>>> >> independent program
>>>>>>>>>>>
>>>>>>>>>>> Because that would require that a halt decider must sometimes
>>>>>>>>>>> make its
>>>>>>>>>>> halt status decision on a basis other than the actual
>>>>>>>>>>> behavior of its actual input that long standing
>>>>>>>>>>> misconception has been refuted.
>>>>>>>>>>
>>>>>>>>>> No, because all the behavior of that program exists will be
>>>>>>>>>> encoded in the representation of the program given to the
>>>>>>>>>> decider.
>>>>>>>>>
>>>>>>>>> The reason that I stop talking to you is that you make false
>>>>>>>>> assumptions that are utterly impervious to all reasoning.
>>>>>>>>>
>>>>>>>>> It is a verified fact that the input that is correctly
>>>>>>>>> simulated by H(P,P) cannot possibly terminate normally. It is
>>>>>>>>> also a verified fact that the direct execution of P(P) does
>>>>>>>>> terminate normally.
>>>>>>>>>
>>>>>>>>> It is also common knowledge that the correct simulation of a
>>>>>>>>> program is a correct measure of the behavior of this program.
>>>>>>>>>
>>>>>>>>> This conclusively proves that H(P,P) is correct to reject its
>>>>>>>>> input as non-halting and the behavior of a non-input cannot
>>>>>>>>> possibly contradict this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly
>>>>>>>> simulate the input (since it aborts it to return 0) so it
>>>>>>>> doesn't MATTER that if it was a different program it wouldn't
>>>>>>>> be able to simulate to a final state.
>>>>>>>
>>>>>>>
>>>>>>> That you (and others) continue to lack the technical capacity to
>>>>>>> comprehend that H does correctly predict that its complete and
>>>>>>> correct simulation of its input would never result in this input
>>>>>>> terminating normally is far less than no rebuttal at all. Until
>>>>>>> you (and others) gain this technical capacity there is no sense
>>>>>>> continuing a dialogue.
>>>>>>
>>>>>> How is it correct when H(P,P) sayts P(P) is non-halting when a
>>>>>> direct exectuion of P(P) or a correct simulation by simualte(P,P)
>>>>>> (where P still calls the previous H) show that it halts.
>>>>>
>>>>> Most everyone here can see: (from my updated simplified paper)
>>>>> It is a verified fact that the input that is correctly simulated by
>>>>> H(P,P) cannot possibly terminate normally.
>>>>
>>>> I have shown that a simulating halting decider needn't be recursive
>>>> in nature thus can terminate normally. You are wrong on all fronts.
>>>>
>>>> /Flibble
>>>
>>> You have shown that you don't fully understand the concept of
>>> unreachable code.
>>
>> Of course I understand the concept of unreachable code in fact I recall
>> giving you several examples of it.
>>
>> /Flibble
>>
>
> I did not say that you have no idea what unreachable code is, you simply
> do not understand that infinite recursion prevents all the code below
> the infinitely recursive function call to ever be reached.
>
> There are a sequence of many posts that prove this where you believe
> that removing the infinite loop eliminates the pathological relationship.
>
> You and Richard are at the bottom 10% of technical competence in this
> forum most everyone else could validate that I am correct.
>
No, you are in the bottom 0.01 % of technical competence to beleive your
lie that the H that returns 0 for H(P,P) actually generates infinite
recursion.
You believe that you can have simultaneously an immovable object and an
irresistible force that it can be applied to (does it move or is it
resisted?) You think you H can simulate its input forever, but still
finish and answer in finite time.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-07-14 17:48 +0100 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <20220714174829.00006c4a@reddwarf.jmc.corp> |
| In reply to | #166705 |
On Thu, 14 Jul 2022 05:49:52 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/14/2022 1:52 AM, Mr Flibble wrote:
> > On Wed, 13 Jul 2022 23:29:53 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/13/2022 11:18 PM, Mr Flibble wrote:
> >>> On Wed, 13 Jul 2022 21:55:25 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/13/2022 9:21 PM, Richard Damon wrote:
> >>>>>
> >>>>> On 7/13/22 10:08 PM, olcott wrote:
> >>>>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
> >>>>>>> On 7/13/22 9:34 PM, olcott wrote:
> >>>>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
> >>>>>>>>>
> >>>>>>>>> On 7/13/22 8:06 PM, olcott wrote:
> >>>>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
> >>>>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
> >>>>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
> >>>>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
> >>>>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
> >>>>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
> >>>>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
> >>>>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this
> >>>>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months
> >>>>>>>>>>>>>>>>>>>>>> ago when the article came out.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot
> >>>>>>>>>>>>>>>>>>>>> called Olcott? He keeps
> >>>>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there
> >>>>>>>>>>>>>>>>>>>>> are two guys here who
> >>>>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing
> >>>>>>>>>>>>>>>>>>>>> him.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a
> >>>>>>>>>>>>>>>>>>>>> response; Olcott won't go
> >>>>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him
> >>>>>>>>>>>>>>>>>>>>> completely. Just ignore him;
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated
> >>>>>>>>>>>>>>>>>>>> whether or not anyone responds. I just had a very
> >>>>>>>>>>>>>>>>>>>> extensive review (23 emails) by a leading
> >>>>>>>>>>>>>>>>>>>> computer scientist.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my
> >>>>>>>>>>>>>>>>>>>> presentation so that everyone here can easily
> >>>>>>>>>>>>>>>>>>>> verify that I have correctly refuted the halting
> >>>>>>>>>>>>>>>>>>>> theorem on this pure software engineering basis:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> OK, so now that we have easily verified that,
> >>>>>>>>>>>>>>>>>>> would you please stop posting this same thing
> >>>>>>>>>>>>>>>>>>> millions of times?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> For any program H that might determine if programs
> >>>>>>>>>>>>>>>>>> halt, a "pathological" program P, called with some
> >>>>>>>>>>>>>>>>>> input, can pass its own source and its input to H
> >>>>>>>>>>>>>>>>>> and then specifically do the opposite of what H
> >>>>>>>>>>>>>>>>>> predicts P will do. *No H can exist that handles
> >>>>>>>>>>>>>>>>>> this case*
> >>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It is not verified until it is understood that P
> >>>>>>>>>>>>>>>>>> and H implement the classical halting problem
> >>>>>>>>>>>>>>>>>> "impossible input" template (as shown above) and
> >>>>>>>>>>>>>>>>>> refutes this template in that H(P,P) correctly
> >>>>>>>>>>>>>>>>>> determines that its input never terminates
> >>>>>>>>>>>>>>>>>> normally.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *This is the key software engineering that I need
> >>>>>>>>>>>>>>>>>> validated* Most anyone here can easily verify that
> >>>>>>>>>>>>>>>>>> the simulated input to H(P,P) cannot possibly
> >>>>>>>>>>>>>>>>>> terminate normally.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The next level of pure software engineering is that
> >>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input
> >>>>>>>>>>>>>>>>>> cannot possibly terminate normally. It may be the
> >>>>>>>>>>>>>>>>>> case that only the top 5% of software engineers can
> >>>>>>>>>>>>>>>>>> validate this point.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>> int H(ptr p, ptr i);
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Simulating halt decider H detects that its
> >>>>>>>>>>>>>>>>>> simulated input is essentially calling H in
> >>>>>>>>>>>>>>>>>> infinite recursion. H aborts its simulation on
> >>>>>>>>>>>>>>>>>> this basis and rejects this input as non-halting.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The execution trace of function P() simulated by
> >>>>>>>>>>>>>>>>>> function H() shows:
> >>>>>>>>>>>>>>>>>> (1) Function H() is called from P().
> >>>>>>>>>>>>>>>>>> (2) With the same parameters to H().
> >>>>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly
> >>>>>>>>>>>>>>>>>> escape this infinitely recursive simulation.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *That was all of the software engineering that I
> >>>>>>>>>>>>>>>>>> need validated*
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of
> >>>>>>>>>>>>>>>>>> software engineering
> >>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> And your property (3) is incorrect the way you use
> >>>>>>>>>>>>>>>>> it. The CORRECT version of (3) looks ALL the way
> >>>>>>>>>>>>>>>>> through the loop, which includes in H, and will
> >>>>>>>>>>>>>>>>> find the condtional there.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot
> >>>>>>>>>>>>>>>> possibly terminate normally. (I have better words
> >>>>>>>>>>>>>>>> now).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Except that the program represented by the input, P(P)
> >>>>>>>>>>>>>>> DOES terminate normally if H(P,P) returns 0.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
> >>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
> >>>>>>>>>>>>>> its correctly simulated input cannot possibly terminate
> >>>>>>>>>>>>>> normally.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> WHAT Change of subject?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> IT IS A VERIFIED FACT THAT
> >>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
> >>>>>>>>>>>> its correctly
> >>>>>>>>>>>> simulated input cannot possibly terminate normally.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The only possible correct rebuttal must show all the
> >>>>>>>>>>>> steps of exactly how the input to simulating halt
> >>>>>>>>>>>> decider H(P,P) does terminate normally when H correctly
> >>>>>>>>>>>> simulates this input.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Since I already proved that this is false entirely on the
> >>>>>>>>>>>> basis of verified fact this is impossible.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This requires that a function called in essentially
> >>>>>>>>>>>> infinite recursion to return a value to its caller this
> >>>>>>>>>>>> is impossible.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Most everyone here knows that every function called in
> >>>>>>>>>>>> infinite recursion never returns any value to its caller.
> >>>>>>>>>>>> There is no gibberish that you can say that would
> >>>>>>>>>>>> convince them otherwise.
> >>>>>>>>>>> That can't be a verified fact because the opposite is a
> >>>>>>>>>>> verified fact, that the CORRECT simulation of the input to
> >>>>>>>>>>> H(P,P), which is the correct simulation of P(P) will
> >>>>>>>>>>> actually Halt if H(P,P) returns 0, as you claim it does.
> >>>>>>>>>>
> >>>>>>>>>> I already gave Paul N a great explanation of that on
> >>>>>>>>>> comp.theory. I won't be able to see your reply there
> >>>>>>>>>> because I have you blocked there.
> >>>>>>>>>>
> >>>>>>>>>> My explanation to wjj even sums it up better:
> >>>>>>>>>>
> >>>>>>>>>> On 7/13/2022 3:51 PM, olcott wrote:
> >>>>>>>>>> > On 7/13/2022 3:47 PM, wij wrote:
> >>>>>>>>>> >> The property that an arbitrary program P will finish
> >>>>>>>>>> >> running or not is determined by running P as an
> >>>>>>>>>> >> independent program
> >>>>>>>>>>
> >>>>>>>>>> Because that would require that a halt decider must
> >>>>>>>>>> sometimes make its
> >>>>>>>>>> halt status decision on a basis other than the actual
> >>>>>>>>>> behavior of its actual input that long standing
> >>>>>>>>>> misconception has been refuted.
> >>>>>>>>>
> >>>>>>>>> No, because all the behavior of that program exists will be
> >>>>>>>>> encoded in the representation of the program given to the
> >>>>>>>>> decider.
> >>>>>>>>
> >>>>>>>> The reason that I stop talking to you is that you make false
> >>>>>>>> assumptions that are utterly impervious to all reasoning.
> >>>>>>>>
> >>>>>>>> It is a verified fact that the input that is correctly
> >>>>>>>> simulated by H(P,P) cannot possibly terminate normally. It is
> >>>>>>>> also a verified fact that the direct execution of P(P) does
> >>>>>>>> terminate normally.
> >>>>>>>>
> >>>>>>>> It is also common knowledge that the correct simulation of a
> >>>>>>>> program is a correct measure of the behavior of this program.
> >>>>>>>>
> >>>>>>>> This conclusively proves that H(P,P) is correct to reject its
> >>>>>>>> input as non-halting and the behavior of a non-input cannot
> >>>>>>>> possibly contradict this.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly
> >>>>>>> simulate the input (since it aborts it to return 0) so it
> >>>>>>> doesn't MATTER that if it was a different program it wouldn't
> >>>>>>> be able to simulate to a final state.
> >>>>>>
> >>>>>>
> >>>>>> That you (and others) continue to lack the technical capacity
> >>>>>> to comprehend that H does correctly predict that its complete
> >>>>>> and correct simulation of its input would never result in this
> >>>>>> input terminating normally is far less than no rebuttal at
> >>>>>> all. Until you (and others) gain this technical capacity there
> >>>>>> is no sense continuing a dialogue.
> >>>>>
> >>>>> How is it correct when H(P,P) sayts P(P) is non-halting when a
> >>>>> direct exectuion of P(P) or a correct simulation by
> >>>>> simualte(P,P) (where P still calls the previous H) show that it
> >>>>> halts.
> >>>>
> >>>> Most everyone here can see: (from my updated simplified paper)
> >>>> It is a verified fact that the input that is correctly simulated
> >>>> by H(P,P) cannot possibly terminate normally.
> >>>
> >>> I have shown that a simulating halting decider needn't be
> >>> recursive in nature thus can terminate normally. You are wrong
> >>> on all fronts.
> >>>
> >>> /Flibble
> >>>
> >>
> >> You have shown that you don't fully understand the concept of
> >> unreachable code.
> >
> > Of course I understand the concept of unreachable code in fact I
> > recall giving you several examples of it.
> >
> > /Flibble
> >
>
> I did not say that you have no idea what unreachable code is, you
> simply do not understand that infinite recursion prevents all the
> code below the infinitely recursive function call to ever be reached.
Of course I have always understood that code after an infinite
recursion is unreachable, I have never claimed otherwise however what I
have claimed is that [Strachey 1965] is NOT recursive nor are the
proofs based on it; I have claimed that your solution is broken if it
invokes infinite recursion and I have shown that a simulating halting
decider needn't be recursive in nature (see my post in comp.theory).
Why don't you try acknowledging and addressing what people actually say
rather than misrepresenting what they say to try to make it fit with
your ongoing false narrative?
>
> There are a sequence of many posts that prove this where you believe
> that removing the infinite loop eliminates the pathological
> relationship.
Nope; see above - your solution is broken if it has an issue with
infinite recursion.
>
> You and Richard are at the bottom 10% of technical competence in this
> forum most everyone else could validate that I am correct.
Are you going to actually address our arguments or are you just going to
rely on ad hominem attacks?
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-14 07:07 -0400 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <eOSzK.468693$ntj.379590@fx15.iad> |
| In reply to | #166698 |
On 7/13/22 10:55 PM, olcott wrote:
> On 7/13/2022 9:21 PM, Richard Damon wrote:
>>
>> On 7/13/22 10:08 PM, olcott wrote:
>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
>>>> On 7/13/22 9:34 PM, olcott wrote:
>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/13/22 8:06 PM, olcott wrote:
>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this
>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months ago when
>>>>>>>>>>>>>>>>>>> the article came out.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot called
>>>>>>>>>>>>>>>>>> Olcott? He keeps
>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there are
>>>>>>>>>>>>>>>>>> two guys here who
>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing him.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a response;
>>>>>>>>>>>>>>>>>> Olcott won't go
>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him
>>>>>>>>>>>>>>>>>> completely. Just ignore him;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated whether
>>>>>>>>>>>>>>>>> or not anyone responds. I just had a very extensive
>>>>>>>>>>>>>>>>> review (23 emails) by a leading computer scientist.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my
>>>>>>>>>>>>>>>>> presentation so that everyone here can easily verify
>>>>>>>>>>>>>>>>> that I have correctly refuted the halting theorem on
>>>>>>>>>>>>>>>>> this pure software engineering basis:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> OK, so now that we have easily verified that, would you
>>>>>>>>>>>>>>>> please stop posting this same thing millions of times?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For any program H that might determine if programs halt,
>>>>>>>>>>>>>>> a "pathological" program P, called with some input, can
>>>>>>>>>>>>>>> pass its own source and its input to H and then
>>>>>>>>>>>>>>> specifically do the opposite of what H predicts P will
>>>>>>>>>>>>>>> do. *No H can exist that handles this case*
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is not verified until it is understood that P and H
>>>>>>>>>>>>>>> implement the classical halting problem "impossible
>>>>>>>>>>>>>>> input" template (as shown above) and refutes this
>>>>>>>>>>>>>>> template in that H(P,P) correctly determines that its
>>>>>>>>>>>>>>> input never terminates normally.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *This is the key software engineering that I need validated*
>>>>>>>>>>>>>>> Most anyone here can easily verify that the simulated
>>>>>>>>>>>>>>> input to H(P,P) cannot possibly terminate normally.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The next level of pure software engineering is that
>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input cannot
>>>>>>>>>>>>>>> possibly terminate normally. It may be the case that only
>>>>>>>>>>>>>>> the top 5% of software engineers can validate this point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Simulating halt decider H detects that its simulated
>>>>>>>>>>>>>>> input is essentially calling H in infinite recursion. H
>>>>>>>>>>>>>>> aborts its simulation on this basis and rejects this
>>>>>>>>>>>>>>> input as non-halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The execution trace of function P() simulated by function
>>>>>>>>>>>>>>> H() shows:
>>>>>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly
>>>>>>>>>>>>>>> escape this infinitely recursive simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *That was all of the software engineering that I need
>>>>>>>>>>>>>>> validated*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of software
>>>>>>>>>>>>>>> engineering
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And your property (3) is incorrect the way you use it. The
>>>>>>>>>>>>>> CORRECT version of (3) looks ALL the way through the loop,
>>>>>>>>>>>>>> which includes in H, and will find the condtional there.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot possibly
>>>>>>>>>>>>> terminate normally. (I have better words now).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Except that the program represented by the input, P(P) DOES
>>>>>>>>>>>> terminate normally if H(P,P) returns 0.
>>>>>>>>>>>
>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>>>>>> correctly simulated input cannot possibly terminate normally.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WHAT Change of subject?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> IT IS A VERIFIED FACT THAT
>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>>>> correctly
>>>>>>>>> simulated input cannot possibly terminate normally.
>>>>>>>>>
>>>>>>>>> The only possible correct rebuttal must show all the steps of
>>>>>>>>> exactly how the input to simulating halt decider H(P,P) does
>>>>>>>>> terminate normally when H correctly simulates this input.
>>>>>>>>>
>>>>>>>>> Since I already proved that this is false entirely on the basis
>>>>>>>>> of verified fact this is impossible.
>>>>>>>>>
>>>>>>>>> This requires that a function called in essentially infinite
>>>>>>>>> recursion to return a value to its caller this is impossible.
>>>>>>>>>
>>>>>>>>> Most everyone here knows that every function called in infinite
>>>>>>>>> recursion never returns any value to its caller. There is no
>>>>>>>>> gibberish that you can say that would convince them otherwise.
>>>>>>>>>
>>>>>>>> That can't be a verified fact because the opposite is a verified
>>>>>>>> fact, that the CORRECT simulation of the input to H(P,P), which
>>>>>>>> is the correct simulation of P(P) will actually Halt if H(P,P)
>>>>>>>> returns 0, as you claim it does.
>>>>>>>
>>>>>>> I already gave Paul N a great explanation of that on comp.theory.
>>>>>>> I won't be able to see your reply there because I have you
>>>>>>> blocked there.
>>>>>>>
>>>>>>> My explanation to wjj even sums it up better:
>>>>>>>
>>>>>>> On 7/13/2022 3:51 PM, olcott wrote:
>>>>>>> > On 7/13/2022 3:47 PM, wij wrote:
>>>>>>> >> The property that an arbitrary program P will finish
>>>>>>> >> running or not is determined by running P as an
>>>>>>> >> independent program
>>>>>>>
>>>>>>> Because that would require that a halt decider must sometimes
>>>>>>> make its
>>>>>>> halt status decision on a basis other than the actual behavior of
>>>>>>> its
>>>>>>> actual input that long standing misconception has been refuted.
>>>>>>>
>>>>>>
>>>>>> No, because all the behavior of that program exists will be
>>>>>> encoded in the representation of the program given to the decider.
>>>>>>
>>>>>
>>>>> The reason that I stop talking to you is that you make false
>>>>> assumptions that are utterly impervious to all reasoning.
>>>>>
>>>>> It is a verified fact that the input that is correctly simulated by
>>>>> H(P,P) cannot possibly terminate normally. It is also a verified
>>>>> fact that the direct execution of P(P) does terminate normally.
>>>>>
>>>>> It is also common knowledge that the correct simulation of a
>>>>> program is a correct measure of the behavior of this program.
>>>>>
>>>>> This conclusively proves that H(P,P) is correct to reject its input
>>>>> as non-halting and the behavior of a non-input cannot possibly
>>>>> contradict this.
>>>>>
>>>>>
>>>>
>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly simulate
>>>> the input (since it aborts it to return 0) so it doesn't MATTER that
>>>> if it was a different program it wouldn't be able to simulate to a
>>>> final state.
>>>
>>>
>>> That you (and others) continue to lack the technical capacity to
>>> comprehend that H does correctly predict that its complete and
>>> correct simulation of its input would never result in this input
>>> terminating normally is far less than no rebuttal at all. Until you
>>> (and others) gain this technical capacity there is no sense
>>> continuing a dialogue.
>>
>> How is it correct when H(P,P) sayts P(P) is non-halting when a direct
>> exectuion of P(P) or a correct simulation by simualte(P,P) (where P
>> still calls the previous H) show that it halts.
>
> Most everyone here can see: (from my updated simplified paper)
> It is a verified fact that the input that is correctly simulated by
> H(P,P) cannot possibly terminate normally.
>
But then how do you explain that P(P) does halt, as you have even shown
when H(P,P) returns 0?
Your problem is that you show that *IF* H behaves one way, that the
simulation done by H(P,P) can't stop, and then you have H behave
differently.
You hide the logic flaw with glib words, but it is still an error.
The input to H(P,P) MUST refer to the behavior of P(P) or P isn't asking
H the right question to be the "Impossible Program", and P(P) Halt if
H(P,P) says it will be non-halting, so that isn't a correct anseer.
All you are showing is that you call fool some people some of the time.
And I think if you take an honest look arround, it isn't "most everyone"
who thinks you are correct. Yes, it is a fact that *IF* H does simulate
its input until it can actually PROVE that its input is non-halting,
that for THAT H, P(P) will be non-halting.
H can, by assuming that H is such a machine, detect that IF H WAS such a
machine, this P would be non-halting.
The problem is, that by H assuming that it is such a machine, it no
longer is such a machine, and the logic fails.
> The smartest software engineers here can also see that H does correctly
> predict this. People at the bottom 10% of technical competence may not
> see either one of these. No sense continuing to talk to these people.
>
But it isn't true! H(P,P) MUST decide about P(P) or P isn't correct, and
P(P) Halts if H(P,P) says it is non-halting, so H is just wrong with its
answer.
You are the Emperor who is believing his own lie that he has made a
fabulous set of clothes that only important people can see, but in
reality has gone out into the parade naked.
You logic is just BAD, and doesn't actually prove anything that you are
trying to claim.
H does NOT get the answer right, but you refuse to look at the REAL
evidence that even you have created, because you so want to believe your
lie, because you just can't face the actual truth.
> *Halting problem proofs refuted on the basis of software engineering*
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>
[toc] | [prev] | [next] | [standalone]
| From | om@iki.fi (Otto J. Makela) |
|---|---|
| Date | 2022-07-18 17:51 +0300 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <87ilnu8oe8.fsf@tigger.extechop.net> |
| In reply to | #166698 |
olcott <NoOne@NoWhere.com> wrote: > Most everyone here can see: (from my updated simplified paper) > It is a verified fact that the input that is correctly simulated by > H(P,P) cannot possibly terminate normally. "Most everyone" here who sees this, please raise your hand now? Followup-to: comp.theory -- /* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */ /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */ /* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */ /* * * Computers Rule 01001111 01001011 * * * * * * */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-13 22:29 -0400 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <tcLzK.48986$iR.41893@fx44.iad> |
| In reply to | #166692 |
On 7/13/22 9:34 PM, olcott wrote:
> On 7/13/2022 8:20 PM, Richard Damon wrote:
>>
>> On 7/13/22 8:06 PM, olcott wrote:
>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
>>>> On 7/13/22 8:19 AM, olcott wrote:
>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
>>>>>> On 7/12/22 10:52 PM, olcott wrote:
>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>>>>>>>>>>>>> As you'd remember if you actually read this newsgroup, we
>>>>>>>>>>>>>>> discussed this nearly 4 months ago when the article came
>>>>>>>>>>>>>>> out.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot called
>>>>>>>>>>>>>> Olcott? He keeps
>>>>>>>>>>>>>> posting the same thing every two weeks and there are two
>>>>>>>>>>>>>> guys here who
>>>>>>>>>>>>>> keep responding to him, instead of kill-filing him.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Olcott comes here because he is getting a response; Olcott
>>>>>>>>>>>>>> won't go
>>>>>>>>>>>>>> anywhere unless people stop responding to him completely.
>>>>>>>>>>>>>> Just ignore him;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I won't go anywhere until my work is validated whether or
>>>>>>>>>>>>> not anyone responds. I just had a very extensive review (23
>>>>>>>>>>>>> emails) by a leading computer scientist.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because of this review I was able to simplify my
>>>>>>>>>>>>> presentation so that everyone here can easily verify that I
>>>>>>>>>>>>> have correctly refuted the halting theorem on this pure
>>>>>>>>>>>>> software engineering basis:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> OK, so now that we have easily verified that, would you
>>>>>>>>>>>> please stop posting this same thing millions of times?
>>>>>>>>>>>
>>>>>>>>>>> For any program H that might determine if programs halt, a
>>>>>>>>>>> "pathological" program P, called with some input, can pass
>>>>>>>>>>> its own source and its input to H and then specifically do
>>>>>>>>>>> the opposite of what H predicts P will do. *No H can exist
>>>>>>>>>>> that handles this case*
>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>
>>>>>>>>>>> It is not verified until it is understood that P and H
>>>>>>>>>>> implement the classical halting problem "impossible input"
>>>>>>>>>>> template (as shown above) and refutes this template in that
>>>>>>>>>>> H(P,P) correctly determines that its input never terminates
>>>>>>>>>>> normally.
>>>>>>>>>>>
>>>>>>>>>>> *This is the key software engineering that I need validated*
>>>>>>>>>>> Most anyone here can easily verify that the simulated input
>>>>>>>>>>> to H(P,P) cannot possibly terminate normally.
>>>>>>>>>>>
>>>>>>>>>>> The next level of pure software engineering is that H(P,P)
>>>>>>>>>>> correctly predicts that its simulated input cannot possibly
>>>>>>>>>>> terminate normally. It may be the case that only the top 5%
>>>>>>>>>>> of software engineers can validate this point.
>>>>>>>>>>>
>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>>>>>>> essentially calling H in infinite recursion. H aborts its
>>>>>>>>>>> simulation on this basis and rejects this input as non-halting.
>>>>>>>>>>>
>>>>>>>>>>> The execution trace of function P() simulated by function H()
>>>>>>>>>>> shows:
>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>> (3) With no instructions in P() that could possibly escape
>>>>>>>>>>> this infinitely recursive simulation.
>>>>>>>>>>>
>>>>>>>>>>> *That was all of the software engineering that I need validated*
>>>>>>>>>>>
>>>>>>>>>>> Halting problem proofs refuted on the basis of software
>>>>>>>>>>> engineering
>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And your property (3) is incorrect the way you use it. The
>>>>>>>>>> CORRECT version of (3) looks ALL the way through the loop,
>>>>>>>>>> which includes in H, and will find the condtional there.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> H(P,P) correctly predicts that its input cannot possibly
>>>>>>>>> terminate normally. (I have better words now).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except that the program represented by the input, P(P) DOES
>>>>>>>> terminate normally if H(P,P) returns 0.
>>>>>>>
>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>> correctly simulated input cannot possibly terminate normally.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> WHAT Change of subject?
>>>>>>
>>>>>
>>>>> IT IS A VERIFIED FACT THAT
>>>>> Simulating halt decider H(P,P) correctly predicts that its correctly
>>>>> simulated input cannot possibly terminate normally.
>>>>>
>>>>> The only possible correct rebuttal must show all the steps of
>>>>> exactly how the input to simulating halt decider H(P,P) does
>>>>> terminate normally when H correctly simulates this input.
>>>>>
>>>>> Since I already proved that this is false entirely on the basis of
>>>>> verified fact this is impossible.
>>>>>
>>>>> This requires that a function called in essentially infinite
>>>>> recursion to return a value to its caller this is impossible.
>>>>>
>>>>> Most everyone here knows that every function called in infinite
>>>>> recursion never returns any value to its caller. There is no
>>>>> gibberish that you can say that would convince them otherwise.
>>>>>
>>>> That can't be a verified fact because the opposite is a verified
>>>> fact, that the CORRECT simulation of the input to H(P,P), which is
>>>> the correct simulation of P(P) will actually Halt if H(P,P) returns
>>>> 0, as you claim it does.
>>>
>>> I already gave Paul N a great explanation of that on comp.theory.
>>> I won't be able to see your reply there because I have you blocked
>>> there.
>>>
>>> My explanation to wjj even sums it up better:
>>>
>>> On 7/13/2022 3:51 PM, olcott wrote:
>>> > On 7/13/2022 3:47 PM, wij wrote:
>>> >> The property that an arbitrary program P will finish
>>> >> running or not is determined by running P as an
>>> >> independent program
>>>
>>> Because that would require that a halt decider must sometimes make its
>>> halt status decision on a basis other than the actual behavior of its
>>> actual input that long standing misconception has been refuted.
>>>
>>
>> No, because all the behavior of that program exists will be encoded in
>> the representation of the program given to the decider.
>>
>
> The reason that I stop talking to you is that you make false assumptions
> that are utterly impervious to all reasoning.
No, you stop talking to me because I am being too good at pointing out
the errors in your logic.
>
> It is a verified fact that the input that is correctly simulated by
> H(P,P) cannot possibly terminate normally. It is also a verified fact
> that the direct execution of P(P) does terminate normally.
Nope. Pointed out elsewhere, the CORRECT simulation of the input to
H(P,P) by a simulator that DOESN'T abort (but P still calls the H that
does) shows that the input to H(P,P) will Halt if H(P,P) returns 0.
>
> It is also common knowledge that the correct simulation of a program is
> a correct measure of the behavior of this program.
Right CORRECT, as in NOT ABORTED part way.
>
> This conclusively proves that H(P,P) is correct to reject its input as
> non-halting and the behavior of a non-input cannot possibly contradict
> this.
>
Nope. Since the correct (non-aborted) simulation of the input given to
H(P,P) by a simulator that actually does a complete simulation while the
input still calls the original H shows that the input to H(P,P) will
halt if H(P,P) returns 0.
If you try to claim that the correct simulation of the input to H(P,P)
depends on the simulator that is doing the simulation, then you are
showing you just don't understand how computations and simulations work.
Since H doesn't do a complete simulation, you can't use proofs based on
it doing so to show something. That is the DEFINITION of an UNSOUND
argument.
Since H (the one that gives the answer 0 to H(P,P), and that is the onne
that the P we are talkng about is using) doesn't do a complete and
correct simulation, ANY proof that include a condition "If H doesn't
abort ..." is a false premise.
Note, Halting is based on the program that is ACTUALLY there, not the
theoretical one you were trying to write.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-07-13 19:41 -0700 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <875yk05sbv.fsf@nosuchdomain.example.com> |
| In reply to | #166696 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/13/22 9:34 PM, olcott wrote:
[214 lines deleted]
Richard, please stop cross-posting to comp.lang.c and comp.lang.c++.
Followups directed back where they belong.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Jens Schweikhardt <usenet@schweikhardt.net> |
|---|---|
| Date | 2022-07-13 21:08 +0000 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <jj8qhvF45m0U1@mid.individual.net> |
| In reply to | #166670 |
In comp.lang.c olcott <NoOne@nowhere.com> wrote:
[...]
# H(P,P) correctly predicts that its input cannot possibly terminate
# normally. (I have better words now).
Please excuse my ignorance, I'm very late to the discussion, if the
following has already been brought forward.
It is my understanding that a "working" halt decider can be used to
prove or disprove any math theorem that can be expressed as a program
that halts or doesn't halt, depending on whether the proposition is true
or false. Simple example: the Riemann Hypothesis that the non-trivial
zeros of the zeta function have real part 0.5.
A C program could halt if it finds a zero with real part not equal 0.5;
if it can't it will run forever (assuming arbitrary large memory for the
bignums).
int main (void) {
/* mycomplex: An arbitrary precision complex type. */
mycomplex zero = 0.0;
for (;;) {
zero = compute_next_zero(zero); /* elided for brevity */
if (realpart(zero) != 0.5)
break;
}
return 0;
}
So if your claim holds true, feed the program to your machine, if it
says "never halts" the RH is proven true, otherwise false. Too easy. But
how does the knowledge about all zeros come into your halt decider? And
abount all the trillions of other programs to prove or disprove a
theorem? What about some of the other non-tractable problems, such as
P=NP? Can we conceive a C program for this question?
I don't think any finite program could be such a general theorem prover
and therefore I am convinced you are chasing a ghost and there's
something you overlooked. I can't say what exactly, but I don't have to,
because the above to me is an reductio ad absurdum. Given the halting
problem could be solved, theorem proving becomes trivial immediately.
I am aware it's not a strict proof in the mathematical sense, but good
enough for me. It's like you are coming to a physicist with a new
perpetual motion machine. They will not spend time finding the exact
weak point in your contraption. They will simply reject it, like any
patent office worth their salt.
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-13 19:33 -0500 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <TZadnQkXeJXt-VL_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #166686 |
On 7/13/2022 4:08 PM, Jens Schweikhardt wrote:
> In comp.lang.c olcott <NoOne@nowhere.com> wrote:
> [...]
> # H(P,P) correctly predicts that its input cannot possibly terminate
> # normally. (I have better words now).
>
> Please excuse my ignorance, I'm very late to the discussion, if the
> following has already been brought forward.
>
> It is my understanding that a "working" halt decider can be used to
> prove or disprove any math theorem that can be expressed as a program
> that halts or doesn't halt, depending on whether the proposition is true
> or false. Simple example: the Riemann Hypothesis that the non-trivial
> zeros of the zeta function have real part 0.5.
>
> A C program could halt if it finds a zero with real part not equal 0.5;
> if it can't it will run forever (assuming arbitrary large memory for the
> bignums).
>
> int main (void) {
> /* mycomplex: An arbitrary precision complex type. */
> mycomplex zero = 0.0;
> for (;;) {
> zero = compute_next_zero(zero); /* elided for brevity */
> if (realpart(zero) != 0.5)
> break;
> }
> return 0;
> }
>
> So if your claim holds true, feed the program to your machine, if it
> says "never halts" the RH is proven true, otherwise false. Too easy. But
> how does the knowledge about all zeros come into your halt decider? And
> abount all the trillions of other programs to prove or disprove a
> theorem? What about some of the other non-tractable problems, such as
> P=NP? Can we conceive a C program for this question?
>
> I don't think any finite program could be such a general theorem prover
> and therefore I am convinced you are chasing a ghost and there's
> something you overlooked. I can't say what exactly, but I don't have to,
> because the above to me is an reductio ad absurdum. Given the halting
> problem could be solved, theorem proving becomes trivial immediately.
>
> I am aware it's not a strict proof in the mathematical sense, but good
> enough for me. It's like you are coming to a physicist with a new
> perpetual motion machine. They will not spend time finding the exact
> weak point in your contraption. They will simply reject it, like any
> patent office worth their salt.
>
> Regards,
>
> Jens
There is a huge difference between solving the halting problem and
refuting the conventional proofs that solving the halting problem is
impossible. I am only doing the latter.
It may not even be the case that solving the halting problem could
answer currently unknown problems of mathematics. This would require
infallible mathematical reasoning about all of mathematics such that it
could deduce every mathematical unknown. This is a very much broader
scope than simply correctly determining whether or not a computer
program will stop running.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Freethinker <freethinker@mymail.com> |
|---|---|
| Date | 2022-07-14 23:46 +0200 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <taq2ro$125n$1@gioia.aioe.org> |
| In reply to | #166690 |
On 14.07.22 02:33, olcott wrote:
> On 7/13/2022 4:08 PM, Jens Schweikhardt wrote:
>> In comp.lang.c olcott <NoOne@nowhere.com> wrote:
>> [...]
>> # H(P,P) correctly predicts that its input cannot possibly terminate
>> # normally. (I have better words now).
>>
>> Please excuse my ignorance, I'm very late to the discussion, if the
>> following has already been brought forward.
>>
>> It is my understanding that a "working" halt decider can be used to
>> prove or disprove any math theorem that can be expressed as a program
>> that halts or doesn't halt, depending on whether the proposition is true
>> or false. Simple example: the Riemann Hypothesis that the non-trivial
>> zeros of the zeta function have real part 0.5.
>>
>> A C program could halt if it finds a zero with real part not equal 0.5;
>> if it can't it will run forever (assuming arbitrary large memory for the
>> bignums).
>>
>> int main (void) {
>> /* mycomplex: An arbitrary precision complex type. */
>> mycomplex zero = 0.0;
>> for (;;) {
>> zero = compute_next_zero(zero); /* elided for brevity */
>> if (realpart(zero) != 0.5)
>> break;
>> }
>> return 0;
>> }
>>
>> So if your claim holds true, feed the program to your machine, if it
>> says "never halts" the RH is proven true, otherwise false. Too easy. But
>> how does the knowledge about all zeros come into your halt decider? And
>> abount all the trillions of other programs to prove or disprove a
>> theorem? What about some of the other non-tractable problems, such as
>> P=NP? Can we conceive a C program for this question?
>>
>> I don't think any finite program could be such a general theorem prover
>> and therefore I am convinced you are chasing a ghost and there's
>> something you overlooked. I can't say what exactly, but I don't have to,
>> because the above to me is an reductio ad absurdum. Given the halting
>> problem could be solved, theorem proving becomes trivial immediately.
>>possible to
>> I am aware it's not a strict proof in the mathematical sense, but good
>> enough for me. It's like you are coming to a physicist with a new
>> perpetual motion machine. They will not spend time finding the exact
>> weak point in your contraption. They will simply reject it, like any
>> patent office worth their salt.
>>
>> Regards,
>>
>> Jens
>
> There is a huge difference between solving the halting problem and
> refuting the conventional proofs that solving the halting problem is
> impossible. I am only doing the latter.
>
> It may not even be the case that solving the halting problem could
> answer currently unknown problems of mathematics. This would require
> infallible mathematical reasoning about all of mathematics such that it
> could deduce every mathematical unknown. This is a very much broader
> scope than simply correctly determining whether or not a computer
> program will stop running.
>
Oh my God! This is the point where you show (as "IT IS A PROVEN AND
VERIFIED FACT") that you don't understand anything about anything at all.
It would even be impossible to start teaching you anything whatsoever.
Your mind just doesn't work the way it should for it to grasp what it's
being taught.
If I had a pupil like you in school I would call his parents and
recommend them to change school. In your case I recommend to change the
subject: maths and computer science just aren't for you. You would
however make a great artist.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-14 17:04 -0500 |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <d7CdnerfIfN3D03_nZ2dnUU7_81j4p2d@giganews.com> |
| In reply to | #166730 |
On 7/14/2022 4:46 PM, Freethinker wrote:
> On 14.07.22 02:33, olcott wrote:
>> On 7/13/2022 4:08 PM, Jens Schweikhardt wrote:
>>> In comp.lang.c olcott <NoOne@nowhere.com> wrote:
>>> [...]
>>> # H(P,P) correctly predicts that its input cannot possibly terminate
>>> # normally. (I have better words now).
>>>
>>> Please excuse my ignorance, I'm very late to the discussion, if the
>>> following has already been brought forward.
>>>
>>> It is my understanding that a "working" halt decider can be used to
>>> prove or disprove any math theorem that can be expressed as a program
>>> that halts or doesn't halt, depending on whether the proposition is true
>>> or false. Simple example: the Riemann Hypothesis that the non-trivial
>>> zeros of the zeta function have real part 0.5.
>>>
>>> A C program could halt if it finds a zero with real part not equal 0.5;
>>> if it can't it will run forever (assuming arbitrary large memory for the
>>> bignums).
>>>
>>> int main (void) {
>>> /* mycomplex: An arbitrary precision complex type. */
>>> mycomplex zero = 0.0;
>>> for (;;) {
>>> zero = compute_next_zero(zero); /* elided for brevity */
>>> if (realpart(zero) != 0.5)
>>> break;
>>> }
>>> return 0;
>>> }
>>>
>>> So if your claim holds true, feed the program to your machine, if it
>>> says "never halts" the RH is proven true, otherwise false. Too easy. But
>>> how does the knowledge about all zeros come into your halt decider? And
>>> abount all the trillions of other programs to prove or disprove a
>>> theorem? What about some of the other non-tractable problems, such as
>>> P=NP? Can we conceive a C program for this question?
>>>
>>> I don't think any finite program could be such a general theorem prover
>>> and therefore I am convinced you are chasing a ghost and there's
>>> something you overlooked. I can't say what exactly, but I don't have to,
>>> because the above to me is an reductio ad absurdum. Given the halting
>>> problem could be solved, theorem proving becomes trivial immediately.
>>> possible to I am aware it's not a strict proof in the mathematical
>>> sense, but good
>>> enough for me. It's like you are coming to a physicist with a new
>>> perpetual motion machine. They will not spend time finding the exact
>>> weak point in your contraption. They will simply reject it, like any
>>> patent office worth their salt.
>>>
>>> Regards,
>>>
>>> Jens
>>
>> There is a huge difference between solving the halting problem and
>> refuting the conventional proofs that solving the halting problem is
>> impossible. I am only doing the latter.
>>
>> It may not even be the case that solving the halting problem could
>> answer currently unknown problems of mathematics. This would require
>> infallible mathematical reasoning about all of mathematics such that
>> it could deduce every mathematical unknown. This is a very much
>> broader scope than simply correctly determining whether or not a
>> computer program will stop running.
>>
> Oh my God! This is the point where you show (as "IT IS A PROVEN AND
> VERIFIED FACT") that you don't understand anything about anything at all.
>
> It would even be impossible to start teaching you anything whatsoever.
> Your mind just doesn't work the way it should for it to grasp what it's
> being taught.
>
> If I had a pupil like you in school I would call his parents and
> recommend them to change school. In your case I recommend to change the
> subject: maths and computer science just aren't for you. You would
> however make a great artist.
Carefully study the first page of my paper and see if you think the same
thing.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-07-12 09:52 +0000 |
| Message-ID | <tajg9b$1ntj$3@gioia.aioe.org> |
| In reply to | #166643 |
In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote: > Olcott comes here because he is getting a response; Olcott won't go > anywhere unless people stop responding to him completely. Just ignore him; Clearly you don't understand how obsessive compulsion works.
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2022-07-12 11:27 +0100 |
| Message-ID | <tajia1$20v2g$1@dont-email.me> |
| In reply to | #166646 |
On 12/07/2022 10:52, Juha Nieminen wrote: > In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote: >> Olcott comes here because he is getting a response; Olcott won't go >> anywhere unless people stop responding to him completely. Just ignore him; > > Clearly you don't understand how obsessive compulsion works. There are degrees of OCD. By normal standards we've all got it... It's not normal to be able to spend hours at a time staring at code on a screen looking for that annoying little error. But yes, some are worse than others. Andy
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-07-12 13:01 -0700 |
| Message-ID | <takjvl$24cen$1@dont-email.me> |
| In reply to | #166648 |
On 7/12/2022 3:27 AM, Vir Campestris wrote: > On 12/07/2022 10:52, Juha Nieminen wrote: >> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote: >>> Olcott comes here because he is getting a response; Olcott won't go >>> anywhere unless people stop responding to him completely. Just ignore >>> him; >> >> Clearly you don't understand how obsessive compulsion works. > > There are degrees of OCD. By normal standards we've all got it... It's > not normal to be able to spend hours at a time staring at code on a > screen looking for that annoying little error. Yup! However, you are working toward a goal... To slay the error. A little OCD can be "useful", from time to time... > But yes, some are worse than others. Big time. Some people have to wash their hands 42 times a day. No more, no less.
[toc] | [prev] | [next] | [standalone]
| From | Manu Raju <MR@invalid.invalid> |
|---|---|
| Date | 2022-07-12 22:19 +0100 |
| Message-ID | <takojn$24r7o$1@dont-email.me> |
| In reply to | #166661 |
On 12/07/2022 21:01, Chris M. Thomasson wrote: > > Big time. Some people have to wash their hands 42 times a day. No > more, no less. > At college we had a Muslim woman who cleaned the keyboard and laid blank papers on chair before sitting down to use a computer. She was just obsessed with silly things.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-07-12 21:04 -0500 |
| Subject | Re: "C: Everyone's favourite programming language isn't a programming language" [Olcott] |
| Message-ID | <LbydnZl83pWPtVP_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #166661 |
On 7/12/2022 3:01 PM, Chris M. Thomasson wrote: > On 7/12/2022 3:27 AM, Vir Campestris wrote: >> On 12/07/2022 10:52, Juha Nieminen wrote: >>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote: >>>> Olcott comes here because he is getting a response; Olcott won't go >>>> anywhere unless people stop responding to him completely. Just >>>> ignore him; >>> >>> Clearly you don't understand how obsessive compulsion works. >> >> There are degrees of OCD. By normal standards we've all got it... It's >> not normal to be able to spend hours at a time staring at code on a >> screen looking for that annoying little error. > > Yup! However, you are working toward a goal... To slay the error. A > little OCD can be "useful", from time to time... > It works for Elon Musk. > >> But yes, some are worse than others. > > Big time. Some people have to wash their hands 42 times a day. No more, > no less. > -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-07-13 10:02 +0000 |
| Message-ID | <tam57u$18c6$1@gioia.aioe.org> |
| In reply to | #166648 |
In comp.lang.c++ Vir Campestris <vir.campestris@invalid.invalid> wrote: > On 12/07/2022 10:52, Juha Nieminen wrote: >> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote: >>> Olcott comes here because he is getting a response; Olcott won't go >>> anywhere unless people stop responding to him completely. Just ignore him; >> >> Clearly you don't understand how obsessive compulsion works. > > There are degrees of OCD. By normal standards we've all got it... It's > not normal to be able to spend hours at a time staring at code on a > screen looking for that annoying little error. I don't think that fulfills the "D" part (except if in canses where it's arguably unreasonable and has a tangible and chronic negative impact on one's life and social relationships).
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-07-13 15:24 +0000 |
| Message-ID | <tamo2n$4bm$1@gioia.aioe.org> |
| In reply to | #166675 |
On Wed, 13 Jul 2022 10:02:40 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >In comp.lang.c++ Vir Campestris <vir.campestris@invalid.invalid> wrote: >> On 12/07/2022 10:52, Juha Nieminen wrote: >>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote: >>>> Olcott comes here because he is getting a response; Olcott won't go >>>> anywhere unless people stop responding to him completely. Just ignore him; >>> >>> Clearly you don't understand how obsessive compulsion works. >> >> There are degrees of OCD. By normal standards we've all got it... It's >> not normal to be able to spend hours at a time staring at code on a >> screen looking for that annoying little error. > >I don't think that fulfills the "D" part (except if in canses where it's >arguably unreasonable and has a tangible and chronic negative impact on >one's life and social relationships). I wonder if Olcott and that religious nutjob who used to post on here (forget his name) are one and the same. In this thread from 2018: https://groups.google.com/g/comp.theory/c/0i86aQ3WPaA Olcott posts a link to his own website: http://the-pete.org Looks very familiar.
[toc] | [prev] | [next] | [standalone]
| From | Manu Raju <MR@invalid.invalid> |
|---|---|
| Date | 2022-07-13 19:00 +0100 |
| Message-ID | <tan0mo$2e61m$1@dont-email.me> |
| In reply to | #166680 |
On 13/07/2022 16:24, Muttley@dastardlyhq.com wrote: > > > Olcott posts a link to his own website: > Olcott can improve his chances of winning a "Nobel" price by posting his article on <https://www.dreamwidth.org/> and spend as much time as possible to promote it. the problem is Olcott hasn't got the necessary qualification to have any credibility in his work. the guy is a jobless troll dying of "advance stage of cancer". that's what he told us so we should take his word. Please don't send any money to him because his claim of dying of cancer is also dubious. The guy is liar and fraudster. He's is wasting time by posting here because people responding to him are only interested to waste his time and their own time. i doubt if any of them have any interest in advancing anything new here. I don't see any posts from them but I have simply kill-filed them and I try to kill-file anybody who responds to his posts.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-07-13 15:31 -0700 |
| Message-ID | <tanh3v$2frd9$1@dont-email.me> |
| In reply to | #166684 |
On 7/13/2022 11:00 AM, Manu Raju wrote:
> On 13/07/2022 16:24, Muttley@dastardlyhq.com wrote:
>>
>>
>> Olcott posts a link to his own website:
>>
>
> Olcott can improve his chances of winning a "Nobel" price by posting his
> article on <https://www.dreamwidth.org/>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dreamwidth sounds interesting.
https://en.wikipedia.org/wiki/Dreamwidth
The invite code reminds me of SIGGRAPH for some reason...
> and spend as much time as
> possible to promote it. the problem is Olcott hasn't got the necessary
> qualification to have any credibility in his work. the guy is a jobless
> troll dying of "advance stage of cancer". that's what he told us so we
> should take his word. Please don't send any money to him because his
> claim of dying of cancer is also dubious. The guy is liar and fraudster.
>
> He's is wasting time by posting here because people responding to him
> are only interested to waste his time and their own time. i doubt if any
> of them have any interest in advancing anything new here. I don't see
> any posts from them but I have simply kill-filed them and I try to
> kill-file anybody who responds to his posts.
>
>
>
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web