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

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

A small, slightly meta-, question

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

Contents

  A small, slightly meta-, question Mark Bluemel <mark.bluemel@gmail.com> - 2021-03-10 00:18 -0800
    Re: A small, slightly meta-, question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-03-10 00:20 -0800
      Re: A small, slightly meta-, question Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-03-11 21:24 +0000
        Re: A small, slightly meta-, question om@iki.fi (Otto J. Makela) - 2021-03-15 14:40 +0200
    Re: A small, slightly meta-, question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-03-10 00:30 -0800
    Re: A small, slightly meta-, question David Brown <david.brown@hesbynett.no> - 2021-03-10 10:04 +0100
      Re: A small, slightly meta-, question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-03-10 20:40 -0800
      Re: A small, slightly meta-, question John Forkosh <forkosh@panix.com> - 2021-03-11 06:42 +0000
        Re: A small, slightly meta-, question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-03-11 10:48 +0000
          Re: A small, slightly meta-, question Manfred <noname@add.invalid> - 2021-03-11 16:04 +0100
            Re: A small, slightly meta-, question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-03-11 21:57 +0000
          Re: A small, slightly meta-, question John Forkosh <forkosh@panix.com> - 2021-03-12 06:29 +0000
    Re: A small, slightly meta-, question Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-03-10 05:51 -0800
      Re: A small, slightly meta-, question David Brown <david.brown@hesbynett.no> - 2021-03-10 16:03 +0100
    Re: A small, slightly meta-, question Bonita Montero <Bonita.Montero@gmail.com> - 2021-03-10 15:50 +0100
      Re: A small, slightly meta-, question Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-03-10 17:53 +0300
        Re: A small, slightly meta-, question Dolores Filandro <dolfiland8@gmail.com> - 2021-03-13 18:49 -0800
      Re: A small, slightly meta-, question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-03-10 20:41 -0800
    Re: A small, slightly meta-, question Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-03-10 08:54 -0700
    Re: A small, slightly meta-, question "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-03-14 19:33 -0700

#159270 — A small, slightly meta-, question

Is there any value in trying to understand Pete Olcott's posts?

[toc] | [next] | [standalone]

#159271

Mark Bluemel <mark.bluemel@gmail.com> writes:
> Is there any value in trying to understand Pete Olcott's posts?

No.  But if you want to try, please do so in comp.theory and avoid
cross-posting.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#159300

On Wed, 2021-03-10, Keith Thompson wrote:
> Mark Bluemel <mark.bluemel@gmail.com> writes:
>> Is there any value in trying to understand Pete Olcott's posts?
>
> No.  But if you want to try, please do so in comp.theory and avoid
> cross-posting.

Yes, please.

Also see

  Dudley, U.: What To Do When The Trisector Comes
  http://web.mst.edu/~lmhall/WhatToDoWhenTrisectorComes.pdf

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#159349

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

> Also see
>
>   Dudley, U.: What To Do When The Trisector Comes
>   http://web.mst.edu/~lmhall/WhatToDoWhenTrisectorComes.pdf

As a defrocked mathematician this hit me hard, I've read more than one
such claim. A slightly better pdf version (not just a picture, also
containing the text) is downloadable from the publisher's website:

https://link.springer.com/article/10.1007/BF03023502

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

#159272

On 3/10/2021 12:18 AM, Mark Bluemel wrote:
> Is there any value in trying to understand Pete Olcott's posts?
> 

comp.theory if you want to wade into deep swamp of crap.

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

#159273

On 10/03/2021 09:18, Mark Bluemel wrote:
> Is there any value in trying to understand Pete Olcott's posts?
> 

No.  He is wrong.  It's not difficult to prove that the halting problem
cannot be solved, and thus all his work trying to disprove it or create
a halting problem solver is flawed.  Sometimes interesting ideas and
work can come from attempting to solve impossible problems, but that
does not appear to be the case here.

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

#159290

On 3/10/2021 1:04 AM, David Brown wrote:
> On 10/03/2021 09:18, Mark Bluemel wrote:
>> Is there any value in trying to understand Pete Olcott's posts?
>>
> 
> No.  He is wrong.  It's not difficult to prove that the halting problem
> cannot be solved, and thus all his work trying to disprove it or create
> a halting problem solver is flawed.  Sometimes interesting ideas and
> work can come from attempting to solve impossible problems, but that
> does not appear to be the case here.
> 

olcott cannot handle infinite iteration. Let alone infinite recursion.

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

#159293

David Brown <david.brown@hesbynett.no> wrote:
> On 10/03/2021 09:18, Mark Bluemel wrote:
>> Is there any value in trying to understand Pete Olcott's posts?
> 
> No. He is wrong. It's not difficult to prove that the halting problem
> cannot be solved, [...]

And since this is comp.lang.c, here's a little C program to prove it
by contradiction (though it might equally as well be Fortran, etc).
   Suppose you claim to have a function  int ishalts(char *filename)
that reads a C program from filename and returns 1=the program in
filename eventually halts, 0=it never halts, and -1=filename doesn't
contain a valid C program (just so ishalts() is a total function
from all_possible_strings-->{1,0,-1} rather than a partial function).
   And now write the following 5-line C program, save it in doIhalt.c,
having it submit itself to ishalts() as follows.
   /* save this program in file doIhalt.c */
   #include <stdio.h>
   int main ( int argc, char *argv[] ) {
      int ishalts(char *);
      while ( ishalts("doIhalt.c") == 1 ) continue;
      exit; }
   /* end-of-file */
So the program never halts if ishalts() claims that it eventually halts,
and it immediately halts if ishalts() claims it never halts.
Thus no such function ishalts() can exist with the claimed functionality.
(I saw this example somewhere, but don't recall where.)

> [...] and thus all his work trying to disprove it or create
> a halting problem solver is flawed.  Sometimes interesting ideas and
> work can come from attempting to solve impossible problems, but that
> does not appear to be the case here.

-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#159296

John Forkosh <forkosh@panix.com> writes:

> David Brown <david.brown@hesbynett.no> wrote:
>> On 10/03/2021 09:18, Mark Bluemel wrote:
>>> Is there any value in trying to understand Pete Olcott's posts?
>> 
>> No. He is wrong. It's not difficult to prove that the halting problem
>> cannot be solved, [...]
>
> And since this is comp.lang.c, here's a little C program to prove it
> by contradiction (though it might equally as well be Fortran, etc).
>    Suppose you claim to have a function  int ishalts(char *filename)
> that reads a C program from filename and returns 1=the program in
> filename eventually halts, 0=it never halts, and -1=filename doesn't
> contain a valid C program (just so ishalts() is a total function
> from all_possible_strings-->{1,0,-1} rather than a partial function).

Just because detail often get in the way, it's simpler to make it a
total function by saying that it returns 1 if the argument is a halting
C program and 0 otherwise.

>    And now write the following 5-line C program, save it in doIhalt.c,
> having it submit itself to ishalts() as follows.
>    /* save this program in file doIhalt.c */
>    #include <stdio.h>
>    int main ( int argc, char *argv[] ) {
>       int ishalts(char *);
>       while ( ishalts("doIhalt.c") == 1 ) continue;
>       exit; }
>    /* end-of-file */

exit is a function, not a statement.  I'd ditch it, the include and the
parameters to main:

    /* save this program in file doIhalt.c */
    int main(void)
    {
       int ishalts(char *);
       while (ishalts("doIhalt.c") == 1) continue;
    }

again, just to remove as much extraneous detail as possible.

> So the program never halts if ishalts() claims that it eventually halts,
> and it immediately halts if ishalts() claims it never halts.
> Thus no such function ishalts() can exist with the claimed functionality.
> (I saw this example somewhere, but don't recall where.)

I think I have as well.  The trouble is that using the file name to "tie
the knot" is really a cheat.  Not a cheat in a bad way (the argument is
sound and the conclusion is correct) but a student might well wonder if
halting for C programs is due to the fact that programs can be put into
named files, and other models, that don't have named files, would not be
subject to the same argument.

-- 
Ben.

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

#159297

On 3/11/2021 11:48 AM, Ben Bacarisse wrote:
> John Forkosh <forkosh@panix.com> writes:
> 
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 10/03/2021 09:18, Mark Bluemel wrote:
>>>> Is there any value in trying to understand Pete Olcott's posts?
>>>
>>> No. He is wrong. It's not difficult to prove that the halting problem
>>> cannot be solved, [...]
>>
>> And since this is comp.lang.c, here's a little C program to prove it
>> by contradiction (though it might equally as well be Fortran, etc).
>>     Suppose you claim to have a function  int ishalts(char *filename)
>> that reads a C program from filename and returns 1=the program in
>> filename eventually halts, 0=it never halts, and -1=filename doesn't
>> contain a valid C program (just so ishalts() is a total function
>> from all_possible_strings-->{1,0,-1} rather than a partial function).

[...]

> 
>      /* save this program in file doIhalt.c */
>      int main(void)
>      {
>         int ishalts(char *);
>         while (ishalts("doIhalt.c") == 1) continue;
>      }
> 
> again, just to remove as much extraneous detail as possible.
> 
>> So the program never halts if ishalts() claims that it eventually halts,
>> and it immediately halts if ishalts() claims it never halts.
>> Thus no such function ishalts() can exist with the claimed functionality.
>> (I saw this example somewhere, but don't recall where.)
> 
> I think I have as well.  The trouble is that using the file name to "tie
> the knot" is really a cheat.  Not a cheat in a bad way (the argument is
> sound and the conclusion is correct) but a student might well wonder if
> halting for C programs is due to the fact that programs can be put into
> named files, and other models, that don't have named files, would not be
> subject to the same argument.
> 

Interesting objection. However, for an "ishalts()" function to exist a 
necessary condition is that a program can be addressed by some 
identifier. Then the same logic applies by making use of such 
identifier, be it named file or anything else.

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

#159301

Manfred <noname@add.invalid> writes:

> On 3/11/2021 11:48 AM, Ben Bacarisse wrote:
>> John Forkosh <forkosh@panix.com> writes:
>>
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 10/03/2021 09:18, Mark Bluemel wrote:
>>>>> Is there any value in trying to understand Pete Olcott's posts?
>>>>
>>>> No. He is wrong. It's not difficult to prove that the halting problem
>>>> cannot be solved, [...]
>>>
>>> And since this is comp.lang.c, here's a little C program to prove it
>>> by contradiction (though it might equally as well be Fortran, etc).
>>>     Suppose you claim to have a function  int ishalts(char *filename)
>>> that reads a C program from filename and returns 1=the program in
>>> filename eventually halts, 0=it never halts, and -1=filename doesn't
>>> contain a valid C program (just so ishalts() is a total function
>>> from all_possible_strings-->{1,0,-1} rather than a partial function).
>
> [...]
>
>>
>>      /* save this program in file doIhalt.c */
>>      int main(void)
>>      {
>>         int ishalts(char *);
>>         while (ishalts("doIhalt.c") == 1) continue;
>>      }
>>
>> again, just to remove as much extraneous detail as possible.
>>
>>> So the program never halts if ishalts() claims that it eventually halts,
>>> and it immediately halts if ishalts() claims it never halts.
>>> Thus no such function ishalts() can exist with the claimed functionality.
>>> (I saw this example somewhere, but don't recall where.)
>>
>> I think I have as well.  The trouble is that using the file name to "tie
>> the knot" is really a cheat.  Not a cheat in a bad way (the argument is
>> sound and the conclusion is correct) but a student might well wonder if
>> halting for C programs is due to the fact that programs can be put into
>> named files, and other models, that don't have named files, would not be
>> subject to the same argument.
>
> Interesting objection. However, for an "ishalts()" function to exist a
> necessary condition is that a program can be addressed by some
> identifier. Then the same logic applies by making use of such
> identifier, be it named file or anything else.

Only if you stretch the meaning of the term "identifier".  In the
classical presentation, some direct encoding of the computation is
"passed".  For Turing machines, there is not way to refer a computation
using an identifier.  Instead a number is used that encodes (à la Gödel)
the state transition function of the subject TM.

-- 
Ben.

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

#159303

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> John Forkosh <forkosh@panix.com> writes:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> Mark Bluemel wrote:
>>>> Is there any value in trying to understand Pete Olcott's posts?
>>> 
>>> No. He is wrong. It's not difficult to prove that the halting problem
>>> cannot be solved, [...]
>>
>> And since this is comp.lang.c, here's a little C program to prove it
>> by contradiction (though it might equally as well be Fortran, etc).
>>    Suppose you claim to have a function  int ishalts(char *filename)
>> that reads a C program from filename and returns 1=the program in
>> filename eventually halts, 0=it never halts, and -1=filename doesn't
>> contain a valid C program (just so ishalts() is a total function
>> from all_possible_strings-->{1,0,-1} rather than a partial function).
> 
> Just because detail often get in the way, it's simpler to make it a
> total function by saying that it returns 1 if the argument is a halting
> C program and 0 otherwise.
> 
>>    And now write the following 5-line C program, save it in doIhalt.c,
>> having it submit itself to ishalts() as follows.
>>    /* save this program in file doIhalt.c */
>>    #include <stdio.h>
>>    int main ( int argc, char *argv[] ) {
>>       int ishalts(char *);
>>       while ( ishalts("doIhalt.c") == 1 ) continue;
>>       exit; }
>>    /* end-of-file */

> exit is a function, not a statement.
Yeah, as mentioned below, I saw this somewhere but (still) can't
recall where. And I was trying to recall it while writing all this,
and seemed to recall the original example was in Fortran
(is that what you also recall seeing???). And I must have been
subconsciously channeling "CALL EXIT" when I wrote that (without
the "()").

> I'd ditch it, the include and the parameters to main:
>     /* save this program in file doIhalt.c */
>     int main(void) {
>        int ishalts(char *);
>        while (ishalts("doIhalt.c") == 1) continue; }
> again, just to remove as much extraneous detail as possible.
> 
>> So the program never halts if ishalts() claims that it eventually halts,
>> and it immediately halts if ishalts() claims it never halts.
>> Thus no such function ishalts() can exist with the claimed functionality.
>> (I saw this example somewhere, but don't recall where.)
> 
> I think I have as well.  The trouble is that using the file name to "tie
> the knot" is really a cheat.  Not a cheat in a bad way (the argument is
> sound and the conclusion is correct) but a student might well wonder if
> halting for C programs is due to the fact that programs can be put into
> named files, and other models, that don't have named files, would not be
> subject to the same argument.

With your repeated interest in students, my original thought about
all this (which I didn't originally mention since, as I did mention,
this is comp.lang.c) is that it's a nice segue to the curry-howard
isomorphism,
   https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#159274

On Wednesday, 10 March 2021 at 08:18:19 UTC, Mark Bluemel wrote:
> Is there any value in trying to understand Pete Olcott's posts?
>
If you don't know anything about Turing machines or the halting problem, 
then there's a value in finding out, though it won't have many implications
for practical C programming. However Peter Olcott's discussions are not
the best introduction. If Peter Olcott's ideas spark an interest in computational
theory, then that's all to the good.

If you do have a basic understanding of these things, then there's maybe
a value in understanding where someone is coming from. Communication
and social skills are very important in professional programming, which is
usually collaborative. 

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

#159277

On 10/03/2021 14:51, Malcolm McLean wrote:
> On Wednesday, 10 March 2021 at 08:18:19 UTC, Mark Bluemel wrote:
>> Is there any value in trying to understand Pete Olcott's posts?
>>
> If you don't know anything about Turing machines or the halting problem, 
> then there's a value in finding out, though it won't have many implications
> for practical C programming. However Peter Olcott's discussions are not
> the best introduction. If Peter Olcott's ideas spark an interest in computational
> theory, then that's all to the good.
> 

It's not a matter of Olcott's posts ("discussions" is too grand a term
for them) being the "best introduction" - they have no use whatsoever as
an introduction.  One of the biggest problems he has is this obsession
with x86 systems instead of using Turing machines - I think it has led
him down a blind alley.

> If you do have a basic understanding of these things, then there's maybe
> a value in understanding where someone is coming from. Communication
> and social skills are very important in professional programming, which is
> usually collaborative. 
> 

If Olcott tried to collaborate, then I'd agree.  But he has no interest
in reading or understanding what people say, or discussing anything in a
collaborative manner - he just posts the same errors and
misunderstandings again and again, and provides no answers to people's
questions or challenges.  This is combined with a total lack of
consideration for the groups he posts in, their conventions, preferences
and topicality.

I'm happy with interesting discussions on computational theory (though
they are off-topic in this group, I believe the occasional related topic
thread is okay), but after having tried to follow his posts, and tried
to engage him, I have to conclude that his posts are pointless.

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

#159275

People who are interested in theoretical computer
science cannot program at all. ;-)

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

#159276

Bonita Montero:

> People who are interested in theoretical computer
> science cannot program at all. ;-)

Yeah, Dijkstra, Knuth, and Wirth can not program at all.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#159328

On Wednesday, March 10, 2021 at 9:53:47 AM UTC-5, Anton Shepelev wrote:
> Bonita Montero:
> > People who are interested in theoretical computer 
> > science cannot program at all. ;-)
> Yeah, Dijkstra, Knuth, and Wirth can not program at all.



https://staff.fnwi.uva.nl/p.vanemdeboas/

``Beware of bugs in the above code; I have only proved it correct, not tried it.'' 

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

#159291

On 3/10/2021 6:50 AM, Bonita Montero wrote:
> People who are interested in theoretical computer
> science cannot program at all. ;-)

LOL!

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

#159278

Mark Bluemel <mark.bluemel@gmail.com> writes:

> Is there any value in trying to understand Pete Olcott's posts?

No.

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

#159339

On 3/10/2021 12:18 AM, Mark Bluemel wrote:
> Is there any value in trying to understand Pete Olcott's posts?
> 

I can't go for that:

https://youtu.be/Y380bkHlye8

[toc] | [prev] | [standalone]

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

csiph-web