Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #166629 > unrolled thread

"C: Everyone's favourite programming language isn't a programming language"

Back to article view | Back to comp.lang.c

Contents

  "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 4 of 4 — ← Prev page 1 2 3 [4]

#166649

Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
> 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.

I don't think he has OCD per se, because people like
that don't have that delusional sense of mission.

[toc] | [prev] | [next] | [standalone]

#166650

Am 12.07.2022 um 14:29 schrieb Bonita Montero:
> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>> 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.
> 
> I don't think he has OCD per se, because people like
> that don't have that delusional sense of mission.

What it has in common with OCD is that Pete only sees details
and is unable to see the big picture. This is also something
that there is in common with circles of thought.

[toc] | [prev] | [next] | [standalone]

#166653

On 7/12/2022 7:46 AM, Bonita Montero wrote:
> Am 12.07.2022 um 14:29 schrieb Bonita Montero:
>> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>>> 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.
>>
>> I don't think he has OCD per se, because people like
>> that don't have that delusional sense of mission.
> 
> What it has in common with OCD is that Pete only sees details
> and is unable to see the big picture. This is also something
> that there is in common with circles of thought.

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

The big picture is that H(P,P) correctly determines that its input would 
never terminate normally and H(P,P) does handle the above "impossible" 
case.

-- 
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]

#166665

On 7/12/22 8:48 AM, olcott wrote:
> On 7/12/2022 7:46 AM, Bonita Montero wrote:
>> Am 12.07.2022 um 14:29 schrieb Bonita Montero:
>>> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>>>> 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.
>>>
>>> I don't think he has OCD per se, because people like
>>> that don't have that delusional sense of mission.
>>
>> What it has in common with OCD is that Pete only sees details
>> and is unable to see the big picture. This is also something
>> that there is in common with circles of thought.
> 
> 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
> 
> The big picture is that H(P,P) correctly determines that its input would 
> never terminate normally and H(P,P) does handle the above "impossible" 
> case.
> 


Except that it doesn't, at least if it is trying to meet the actual 
requirements of the Halting Problem.

Remember the DEFINITION:

H(M,x) accepts its input (returns 1) if M(x) will Halt (return), and
H(M,x) rejects its input (returns 0) if M(x) will NEVER Halt (return).

Thus H(P,P) to correctly return 0, means that P(P) must never return, 
but by construction, P(P) WILL return if H(P,P) returns 0.

Your dishonest dodge of saying that the input to H(P,P) somehow doesn't 
represent P(P) fails, because that says that P wasn't defined correctly, 
as P was defined in the proof to be given an input so P asks H what it 
will do when called with its input, and sincd your P(x) calls H(x,x), 
athat means that P(P) calls H(P,P) which needs to mean that P is asking 
about P(P), and not something else.

Thus, your claim is just an admission that you didn't write P correctly 
(or are just lying that H is actually able to do what you claim).

[toc] | [prev] | [next] | [standalone]

#166871

Am 12.07.2022 um 14:48 schrieb olcott:

> The big picture is that H(P,P) correctly determines that its input would 
> never terminate normally and H(P,P) does handle the above "impossible" 
> case.

Seeing the big picture here means that it is pointless
to deal with this topic so fruitlessly for years.

[toc] | [prev] | [next] | [standalone]

#166651

On 7/12/2022 7:29 AM, Bonita Montero wrote:
> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>> 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.
> 
> I don't think he has OCD per se, because people like
> that don't have that delusional sense of mission.

Do you really have to go around and around with all this ad hominen 
stuff instead of simply validating that the simulated input to H(P,P) 
would never terminate normally ???

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 and would never terminate 
normally. H aborts its simulation on this basis and rejects this input 
as non-halting.


-- 
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]

#166664

On 7/12/22 8:45 AM, olcott wrote:
> On 7/12/2022 7:29 AM, Bonita Montero wrote:
>> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>>> 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.
>>
>> I don't think he has OCD per se, because people like
>> that don't have that delusional sense of mission.
> 
> Do you really have to go around and around with all this ad hominen 
> stuff instead of simply validating that the simulated input to H(P,P) 
> would never terminate normally ???
> 
> 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 and would never terminate 
> normally. H aborts its simulation on this basis and rejects this input 
> as non-halting.
> 
> 

And is WRONG, because you have just shown that a call to H(P,P) returns 
0 and NOT get into infinite recursion, BECAUSE H is smarter than H gives 
it credit for, and know enough to abort its simulation, but isn't smart 
enough to know that it will do so.

The ONLY way that H is correct that the call fo H(P,P) inside P(P) leads 
to infinite recursion is if H isn't actually a Pure Function, at which 
point it fails to be the equivalent of the Turing Machine required by 
the proof, or to be a proper decider.

Note, you needed to add the "essentially" to you statment, because it 
isn't actually infinite recursion, at least not if H makes the decision 
to ever abort its simulation.

H, to be correct, needs to judge P based on the ACTUAL H that exists, 
not some close approximation like the essentially tries to let in.

[toc] | [prev] | [next] | [standalone]

#166652

On 7/12/2022 7:29 AM, Bonita Montero wrote:
> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>> 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.
> 
> I don't think he has OCD per se, because people like
> that don't have that delusional sense of mission.

Do you really have to go around and around with all this ad hominen 
stuff instead of simply validating that the simulated input to H(P,P) 
would never terminate normally ???

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 and would never terminate 
normally. H aborts its simulation on this basis and rejects this input 
as non-halting.


-- 
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]

#166647

On Monday, 11 July 2022 at 22:16:29 UTC+1, 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 have some hope Lynn may take some notice. It's clear that Olcott won't.

[toc] | [prev] | [next] | [standalone]

#166657

Mark Bluemel <mark.bluemel@gmail.com> writes:
> On Monday, 11 July 2022 at 22:16:29 UTC+1, 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 have some hope Lynn may take some notice. It's clear that Olcott won't.

Lynn clearly made an honest mistake, posting a relevant link without
realizing that it had been discussed previously.

Olcott is a crank (take a look at comp.theory if you're curious).  They
are not comparable.

My personal solution is to killfile olcott in this newsgroup, so I never
see his posts here.  What I do see is other posters replying to him.

If you must reply to olcott here, at least don't quote his entire
article and continue arguing with him.

-- 
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]

#166658

On 7/12/2022 1:01 PM, Keith Thompson wrote:
> Mark Bluemel <mark.bluemel@gmail.com> writes:
>> On Monday, 11 July 2022 at 22:16:29 UTC+1, 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 have some hope Lynn may take some notice. It's clear that Olcott won't.
> 
> Lynn clearly made an honest mistake, posting a relevant link without
> realizing that it had been discussed previously.
..
Thank you.  I did not realize that the article was old and had already 
been posted.

Lynn

[toc] | [prev] | [next] | [standalone]

#166674

On Tuesday, 12 July 2022 at 19:01:52 UTC+1, Keith Thompson wrote:
> Mark Bluemel <mark.b...@gmail.com> writes: 

> > I have some hope Lynn may take some notice. It's clear that Olcott won't.
> Lynn clearly made an honest mistake, posting a relevant link without 
> realizing that it had been discussed previously. 

My response to Lynn was possibly a little brusque, but my perception
is that she pops up from time-to-time to post some link or other, but 
doesn't really participate in discussions.

> Olcott is a crank (take a look at comp.theory if you're curious). They 
> are not comparable. 

I know, and no thank you, I'm not curious.

> If you must reply to olcott here, at least don't quote his entire 
> article and continue arguing with him. 

You must be mistaking me for someone else - I don't reply to 
olcott, let alone quote his drivel.

I note that he and Richard (who should surely know better) have 
now hijacked this thread.

[toc] | [prev] | [next] | [standalone]

#166681

Mark Bluemel <mark.bluemel@gmail.com> writes:
> On Tuesday, 12 July 2022 at 19:01:52 UTC+1, Keith Thompson wrote:
[...]
>> If you must reply to olcott here, at least don't quote his entire 
>> article and continue arguing with him. 
>
> You must be mistaking me for someone else - I don't reply to 
> olcott, let alone quote his drivel.

Sorry, that wasn't addressed to you specifically.

> I note that he and Richard (who should surely know better) have 
> now hijacked this thread.

Yes, Richard should know better.

-- 
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]

#166685 — Re: "C: Everyone's favourite programming language isn't a programming language" pure SE

On Wednesday, July 13, 2022 at 12:24:04 PM UTC-5, Keith Thompson wrote:
> Mark Bluemel <mark.b...@gmail.com> writes: 
> > On Tuesday, 12 July 2022 at 19:01:52 UTC+1, Keith Thompson wrote:
> [...]
> >> If you must reply to olcott here, at least don't quote his entire 
> >> article and continue arguing with him. 
> > 
> > You must be mistaking me for someone else - I don't reply to 
> > olcott, let alone quote his drivel.
> Sorry, that wasn't addressed to you specifically.
> > I note that he and Richard (who should surely know better) have 
> > now hijacked this thread.
> Yes, Richard should know better.
> -- 
> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com 
> Working, but not speaking, for Philips 
> void Void(void) { Void(); } /* The recursive call of the void */

5.5 years of feedback have made my words much clearer. 
My words are so much more plausible now that a leading
computer scientist extensively reviewed my work in a 23 email
dialogue last weekend. 

You are certainly competent enough to validate the software engineering of this

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

H Simulates its input until it correctly predicts that this simulated input 
would never terminate normally then rejects this input as non-halting. 

void P(ptr x) 
{
  if (H(x, x)) 
    HERE: goto HERE; 
  return; 
} 
    
int main() 
{ 
  Output("Input_Halts = ", H(P, P)); 
} 

The simulated P essentially calls H in infinite recursion. 
Because basic software engineering knows that no function 
called in infinite recursion ever returns to its caller we know 
that the simulated P never terminates normally for these reasons:

*When the execution trace of function P() simulated by function H() shows:*
(1) Function H() is called from P().<br>
(2) With the same parameters to H().<br>
(3) With no instructions in P() that could escape this infinitely recursive 
simulation: {index jump, conditional branch, return}

As soon as H correctly predicts that its simulated P would never terminate 
normally it aborted its simulation of P and rejects this input a s non-haling. 

Then the function call from P() to H() would never terminate normally. 
In this case H aborts its simulation of P and rejects its input as non-halting. 

       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 

Because H(P,P) does handle this case the above halting problem undecidable input template has been refuted. 

*When this halt deciding principle understood to be correct*
A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually specified by these inputs.

*Then (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until it correctly predicts that this simulated input would never terminate normally, correctly rejects this input as non-halting.

H is a *Pure function* https://en.wikipedia.org/wiki/Pure_function
thus implements a *Computable function*
https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c

csiph-web