Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #68344 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2015-08-25 14:14 -0700 |
| Last post | 2015-08-27 13:04 +0200 |
| Articles | 20 on this page of 291 — 30 participants |
Back to article view | Back to comp.lang.c
should c be a subset of c++? G G <gdotone@gmail.com> - 2015-08-25 14:14 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 14:43 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-25 15:26 -0700
Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-08-30 09:51 -0700
Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-08-30 10:46 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-30 20:55 +0100
Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-08-30 13:14 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 00:04 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 03:01 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 12:11 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 06:31 -0700
Re: should c be a subset of c++? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-08-31 10:24 -0400
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-31 18:04 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 11:28 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 00:31 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-31 17:19 -0700
Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-08-31 22:18 -0400
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 13:32 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 05:37 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 16:51 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 09:45 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 20:04 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 12:15 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 20:33 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 12:41 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 21:02 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 13:14 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-02 00:42 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 17:24 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 13:34 -0700
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-02 19:07 +0200
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-02 19:13 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-02 10:25 -0700
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-04 09:58 +0200
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-04 10:06 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 06:44 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-01 14:49 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 07:21 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 07:22 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 07:33 -0700
Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-09-01 08:32 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-01 08:49 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-01 22:58 +0200
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-01 22:07 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-02 13:12 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 16:48 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 09:15 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 20:00 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-01 12:57 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 23:57 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-01 22:57 +0200
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-01 22:04 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-02 13:29 +0200
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-02 12:37 +0100
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-04 04:13 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-03 23:59 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-04 10:13 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 01:23 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-04 09:52 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 02:03 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-04 10:20 +0100
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-04 11:33 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 03:13 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-04 12:53 +0200
Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-09-04 16:31 +0000
Re: should c be a subset of c++? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-04 11:43 -0500
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 15:07 -0700
Re: should c be a subset of c++? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 13:36 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 13:57 -0700
Re: should c be a subset of c++? Geoff <geoff@invalid.invalid> - 2015-09-08 10:36 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 06:02 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-04 16:53 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 09:59 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-04 21:13 +0100
Re: should c be a subset of c++? Melzzzzz <mel@zzzzz.com> - 2015-09-04 22:20 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 13:45 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-04 22:21 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 14:53 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 00:48 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 20:02 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 13:10 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 05:31 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 15:46 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 22:19 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 14:34 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 07:14 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 17:39 +0200
Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-09-06 12:05 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 12:13 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-05 06:05 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 06:11 -0700
Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-09-05 10:10 -0400
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-05 08:51 -0700
Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-09-05 16:30 -0400
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-05 13:52 -0700
Re: should c be a subset of c++? Richard Damon <Richard@Damon-Family.org> - 2015-09-05 21:17 -0400
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-06 05:47 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 00:02 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-06 08:20 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 02:23 -0700
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 16:34 +0000
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 16:17 +0100
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 16:31 +0000
Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-09-05 19:06 +0000
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 21:12 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-05 22:23 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 14:30 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 07:23 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 17:15 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 09:21 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 09:34 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 21:42 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 17:01 -0700
Re: should c be a subset of c++? "Osmium" <r124c4u102@comcast.net> - 2015-09-06 13:46 -0500
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 12:01 -0700
Re: should c be a subset of c++? "Osmium" <r124c4u102@comcast.net> - 2015-09-06 14:22 -0500
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 12:29 -0700
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 12:36 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 22:20 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 13:49 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 23:13 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 14:23 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-07 11:55 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 04:00 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-07 12:44 +0100
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-09-06 22:32 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 14:36 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 00:08 +0200
Re: should c be a subset of c++? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-06 23:33 -0500
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-09-07 12:18 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 21:51 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 21:14 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 13:23 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-06 22:40 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 14:05 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 00:11 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 16:43 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 01:10 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 17:23 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 01:36 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 17:54 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 11:03 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 15:17 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-07 07:49 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 22:43 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 18:22 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 11:00 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 15:10 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 07:42 -0700
Re: should c be a subset of c++? Les Cargill <lcargill99@comcast.com> - 2015-09-07 10:26 -0500
Re: should c be a subset of c++? Ike Naar <ike@iceland.freeshell.org> - 2015-09-07 16:10 +0000
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 22:39 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 15:16 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 17:17 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 08:27 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 21:13 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 16:49 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 10:54 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 02:26 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-09-07 12:26 +0200
Re: should c be a subset of c++? Robert Wessel <robertwessel2@yahoo.com> - 2015-09-06 23:37 -0500
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 00:57 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 16:57 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-06 09:26 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 20:41 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 16:55 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 01:21 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 11:15 -0700
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-09-06 20:03 +0100
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 20:49 +0100
Re: should c be a subset of c++? Rosario19 <Ros@invalid.invalid> - 2015-09-08 07:55 +0200
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 16:27 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-04 15:14 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-05 00:58 +0100
Re: should c be a subset of c++? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-05 01:11 +0000
Re: should c be a subset of c++? raltbos@xs4all.nl (Richard Bos) - 2015-09-05 19:12 +0000
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-26 11:39 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 17:47 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-26 12:55 +1200
Re: should c be a subset of c++? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-26 07:14 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 03:54 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-26 12:01 +0100
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 04:07 -0700
Re: should c be a subset of c++? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-26 13:13 +0000
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 06:28 -0700
Re: should c be a subset of c++? Mark Storkamp <mstorkamp@yahoo.com> - 2015-08-26 09:05 -0500
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 07:18 -0700
Re: should c be a subset of c++? Ken Brody <kenbrody@spamcop.net> - 2015-08-26 13:31 -0400
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-26 18:52 +0100
Re: should c be a subset of c++? James Kuyper <jameskuyper@verizon.net> - 2015-08-26 14:04 -0400
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-27 09:25 +1200
Re: should c be a subset of c++? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-26 21:37 +0000
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 14:49 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-27 13:16 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 18:47 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-27 14:46 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-26 19:58 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 11:31 +0200
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 10:40 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 03:34 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 12:54 +0200
Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-08-27 10:46 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 07:56 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 13:08 -0700
Re: should c be a subset of c++? James Kuyper <jameskuyper@verizon.net> - 2015-08-27 16:36 -0400
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 08:49 +1200
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 10:24 +0200
Re: should c be a subset of c++? Les Cargill <lcargill99@comcast.com> - 2015-08-27 12:00 -0500
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 11:55 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 14:09 +0200
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 15:14 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 11:38 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 07:17 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 16:24 +0100
Re: should c be a subset of c++? Melzzzzz <mel@zzzzz.com> - 2015-08-27 18:58 +0200
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 20:35 +0100
Re: should c be a subset of c++? fir <profesor.fir@gmail.com> - 2015-08-27 13:07 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 21:36 +0100
Re: should c be a subset of c++? fir <profesor.fir@gmail.com> - 2015-08-27 14:31 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 08:25 +1200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 13:30 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 14:49 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-27 22:34 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 16:33 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 00:31 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 18:16 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 10:08 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 04:03 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 23:18 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 04:34 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 08:03 +1200
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 12:02 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 06:02 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 07:52 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 16:14 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 11:26 +1200
Re: should c be a subset of c++? Keith Thompson <kst-u@mib.org> - 2015-08-28 18:06 -0700
Re: should c be a subset of c++? Martin Shobe <martin.shobe@yahoo.com> - 2015-08-28 18:33 -0500
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 11:38 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 17:08 -0700
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 17:12 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 12:15 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 18:20 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-28 17:13 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 12:38 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 04:58 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 15:36 +0200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 07:11 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 10:57 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 16:21 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 11:34 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 17:16 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 13:03 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 18:38 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-27 23:29 +0100
Re: should c be a subset of c++? Melzzzzz <mel@zzzzz.com> - 2015-08-28 01:15 +0200
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 11:25 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 16:39 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 00:56 +0100
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 00:45 +0000
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-28 13:05 +1200
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 10:46 +0100
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 11:38 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 05:23 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 13:51 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 07:20 -0700
Re: should c be a subset of c++? Martin Shobe <martin.shobe@yahoo.com> - 2015-08-28 09:55 -0500
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 15:10 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 09:03 -0700
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 13:38 +0100
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 06:11 -0700
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 13:59 +0000
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-28 07:31 -0700
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-28 20:36 +0100
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-28 15:55 +0200
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 14:57 +0000
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 17:45 +0100
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 22:36 +0100
Re: should c be a subset of c++? jt@toerring.de (Jens Thoms Toerring) - 2015-08-28 23:38 +0000
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-29 09:29 +0200
Re: should c be a subset of c++? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-28 17:52 +0100
Re: should c be a subset of c++? Bartc <bc@freeuk.com> - 2015-08-28 19:27 +0100
Re: should c be a subset of c++? Melzzzzz <mel@zzzzz.com> - 2015-08-28 21:30 +0200
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-29 08:14 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-26 18:51 -0700
Re: should c be a subset of c++? Ian Collins <ian-news@hotmail.com> - 2015-08-27 14:48 +1200
Re: should c be a subset of c++? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-26 20:15 -0700
Re: should c be a subset of c++? Ayan <selfjam@gmail.com> - 2015-08-26 23:59 -0400
Re: should c be a subset of c++? Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-08-27 12:03 +0200
Re: should c be a subset of c++? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-27 03:33 -0700
Re: should c be a subset of c++? David Brown <david.brown@hesbynett.no> - 2015-08-27 13:04 +0200
Page 1 of 15 [1] 2 3 … 15 Next page →
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-08-25 14:14 -0700 |
| Subject | should c be a subset of c++? |
| Message-ID | <32c7b61e-1216-4b5d-8a4d-4c56af7cecf3@googlegroups.com> |
Bjarne Stroustrup: Why the Programming Language C Is Obsolete https://www.youtube.com/watch?v=KlPC3O1DVcg this is dated : 2011 i don't think so. but ...
[toc] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-08-25 14:43 -0700 |
| Message-ID | <cf77a98a-e603-4bbe-a35b-33032347a176@googlegroups.com> |
| In reply to | #68344 |
On Tuesday, August 25, 2015 at 5:14:34 PM UTC-4, G G wrote: > Bjarne Stroustrup: Why the Programming Language C Is Obsolete > https://www.youtube.com/watch?v=KlPC3O1DVcg > > this is dated : 2011 > i don't think so. but ... Bjarne Stroustrup is of the most arrogant people I've ever come across in those folks I've met regarding hardware and software. Not everyone is like that, in fact most people aren't generally, though many very talented people are in some ways, but he's at or near the top of the list on all counts. Every time I see him my stomach literally turns. I think C++ is too complex. I hate looking at C++ code that uses many C++ features. It's like deciphering cryptography. I think C needs to add the simple class, exception handling, strict type conversion, relaxed struct handling, and a few more traits from C++, but maintain its distinct and ongoing independent character and nature. And, that being said, I think C++ should be the language that dies if either of them has to go (though I'm sure that has as much to do with Bjarne himself, as it does the language). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-25 15:26 -0700 |
| Message-ID | <c0723af8-1d59-46c4-8a07-0673d08368eb@googlegroups.com> |
| In reply to | #68345 |
On Tuesday, August 25, 2015 at 10:43:45 PM UTC+1, Rick C. Hodgin wrote: > > Bjarne Stroustrup is of the most arrogant people I've ever come > across in those folks I've met regarding hardware and software. > Not everyone is like that, in fact most people aren't generally, > though many very talented people are in some ways, but he's at or > near the top of the list on all counts. Every time I see him my > stomach literally turns. > There's something about C++ which makes C++ programmers arrogant. Not always. But there's a definite tendency that way. I suspect it's related to the tendency of soft scientists to use incomprehensible jargon. Often, when you read the papers carefully, they're saying something very simple, even simplistic. The jargon is a kind of smokescreen, to create aura of professionalism and learning. Similarly, when you look at what complex C++ code is actually doing, most of the time it's very trivial and routine data manipulation. If a function is doing something that is algorithmically hard, usually you find that it's written in C or very C-like C++.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-08-30 09:51 -0700 |
| Message-ID | <qnc6ual7sp760qqk5jtbt8a9ckg079idhs@4ax.com> |
| In reply to | #68347 |
On Tue, 25 Aug 2015 15:26:57 -0700 (PDT), Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >On Tuesday, August 25, 2015 at 10:43:45 PM UTC+1, Rick C. Hodgin wrote: >> >> Bjarne Stroustrup is of the most arrogant people I've ever come >> across in those folks I've met regarding hardware and software. >> Not everyone is like that, in fact most people aren't generally, >> though many very talented people are in some ways, but he's at or >> near the top of the list on all counts. Every time I see him my >> stomach literally turns. >> >There's something about C++ which makes C++ programmers arrogant. >Not always. But there's a definite tendency that way. > >I suspect it's related to the tendency of soft scientists to use >incomprehensible jargon. Often, when you read the papers carefully, >they're saying something very simple, even simplistic. The jargon >is a kind of smokescreen, to create aura of professionalism and >learning. A very astute observation that I share. The formalities of publishing academic papers seem to require this kind of obfuscation. >Similarly, when you look at what complex C++ code is >actually doing, most of the time it's very trivial and routine >data manipulation. Is this not true of /all/ code? But perhaps the converse is true: Writing trivial and routine data manipulation in C++ makes the code complex. >If a function is doing something that is >algorithmically hard, usually you find that it's written in C or >very C-like C++. Algorithms are essentially procedural so the best method for coding such algorithms is in a procedural language.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-08-30 10:46 -0700 |
| Message-ID | <bif6uat795ouvpqc1hpsbbf43p9mgs230v@4ax.com> |
| In reply to | #68698 |
On 30 Aug 2015 17:14:48 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote: >Geoff <geoff@invalid.invalid> writes: >>Algorithms are essentially procedural so the best method for coding >>such algorithms is in a procedural language. > > When you are growing up in a world where algorithms are > given as procedures with mutable states, you can come to > believe this. But the GCD, which normaly is given using a > mutable state, can be given as a stateless function as well. > >( define( gcd a b )( if( = b 0 )a( gcd b( remainder a b )))) > Algorithm: "A finite set of unambiguous instructions performed in a prescribed sequence to achieve a goal, especially a mathematical rule or procedure used to compute a desired result. Algorithms are the basis for most computer programming." While a function might be expressed statelessly, nevertheless, it must be translated into a sequence of computer instructions by the compiler which will statefully and algorithmically translate the function definition into machine-executable code. The implementation of the function will be, and must necessarily be, stateful.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-30 20:55 +0100 |
| Message-ID | <87oahownyd.fsf@bsb.me.uk> |
| In reply to | #68703 |
Geoff <geoff@invalid.invalid> writes: > On 30 Aug 2015 17:14:48 GMT, ram@zedat.fu-berlin.de (Stefan Ram) > wrote: > >>Geoff <geoff@invalid.invalid> writes: >>>Algorithms are essentially procedural so the best method for coding >>>such algorithms is in a procedural language. >> >> When you are growing up in a world where algorithms are >> given as procedures with mutable states, you can come to >> believe this. But the GCD, which normaly is given using a >> mutable state, can be given as a stateless function as well. >> >>( define( gcd a b )( if( = b 0 )a( gcd b( remainder a b )))) >> > > Algorithm: > "A finite set of unambiguous instructions performed in a prescribed > sequence to achieve a goal, especially a mathematical rule or > procedure used to compute a desired result. Algorithms are the basis > for most computer programming." > > While a function might be expressed statelessly, nevertheless, it must > be translated into a sequence of computer instructions by the compiler > which will statefully and algorithmically translate the function > definition into machine-executable code. The implementation of the > function will be, and must necessarily be, stateful. Is it your contention that the gcd above is therefore not an algorithm but that an algorithm emerges from it when some compiler has does its work or when some other procedural interpretation has been put on the symbols? (I don't want to rehash the whole argument again, I just want to know what your position is.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-08-30 13:14 -0700 |
| Message-ID | <t5o6uap0aao9qphlf4ddv4u1k75lhh73is@4ax.com> |
| In reply to | #68716 |
On Sun, 30 Aug 2015 20:55:38 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >Geoff <geoff@invalid.invalid> writes: > >> On 30 Aug 2015 17:14:48 GMT, ram@zedat.fu-berlin.de (Stefan Ram) >> wrote: >> >>>Geoff <geoff@invalid.invalid> writes: >>>>Algorithms are essentially procedural so the best method for coding >>>>such algorithms is in a procedural language. >>> >>> When you are growing up in a world where algorithms are >>> given as procedures with mutable states, you can come to >>> believe this. But the GCD, which normaly is given using a >>> mutable state, can be given as a stateless function as well. >>> >>>( define( gcd a b )( if( = b 0 )a( gcd b( remainder a b )))) >>> >> >> Algorithm: >> "A finite set of unambiguous instructions performed in a prescribed >> sequence to achieve a goal, especially a mathematical rule or >> procedure used to compute a desired result. Algorithms are the basis >> for most computer programming." >> >> While a function might be expressed statelessly, nevertheless, it must >> be translated into a sequence of computer instructions by the compiler >> which will statefully and algorithmically translate the function >> definition into machine-executable code. The implementation of the >> function will be, and must necessarily be, stateful. > >Is it your contention that the gcd above is therefore not an algorithm >but that an algorithm emerges from it when some compiler has does its >work or when some other procedural interpretation has been put on the >symbols? (I don't want to rehash the whole argument again, I just want >to know what your position is.) To be consistent I would have to state the algorithm arises from the process of creating the instructions. Given the symbols of the function defined above are a true representation of the process of calculating a GCD. A human or machine, tasked with following the instructions implied by the syntax of the algorithm, knowing the syntax and grammar of the language of the statement in question, will enter into a stateful process of evaluating a, b and performing a calculation of b(remainder a b) and the act of performing those calculations affects the state of the "machine" performing the operation. Or is it your assertion that a parser of the above function statement is not stateful?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-31 00:04 +0100 |
| Message-ID | <87si70v0ms.fsf@bsb.me.uk> |
| In reply to | #68719 |
Geoff <geoff@invalid.invalid> writes: > On Sun, 30 Aug 2015 20:55:38 +0100, Ben Bacarisse > <ben.usenet@bsb.me.uk> wrote: > >>Geoff <geoff@invalid.invalid> writes: >> >>> On 30 Aug 2015 17:14:48 GMT, ram@zedat.fu-berlin.de (Stefan Ram) >>> wrote: >>> >>>>Geoff <geoff@invalid.invalid> writes: >>>>>Algorithms are essentially procedural so the best method for coding >>>>>such algorithms is in a procedural language. >>>> >>>> When you are growing up in a world where algorithms are >>>> given as procedures with mutable states, you can come to >>>> believe this. But the GCD, which normaly is given using a >>>> mutable state, can be given as a stateless function as well. >>>> >>>>( define( gcd a b )( if( = b 0 )a( gcd b( remainder a b )))) >>>> >>> >>> Algorithm: >>> "A finite set of unambiguous instructions performed in a prescribed >>> sequence to achieve a goal, especially a mathematical rule or >>> procedure used to compute a desired result. Algorithms are the basis >>> for most computer programming." >>> >>> While a function might be expressed statelessly, nevertheless, it must >>> be translated into a sequence of computer instructions by the compiler >>> which will statefully and algorithmically translate the function >>> definition into machine-executable code. The implementation of the >>> function will be, and must necessarily be, stateful. >> >>Is it your contention that the gcd above is therefore not an algorithm >>but that an algorithm emerges from it when some compiler has does its >>work or when some other procedural interpretation has been put on the >>symbols? (I don't want to rehash the whole argument again, I just want >>to know what your position is.) > > To be consistent I would have to state the algorithm arises from the > process of creating the instructions. Given the symbols of the > function defined above are a true representation of the process of > calculating a GCD. > > A human or machine, tasked with following the instructions implied by > the syntax of the algorithm, knowing the syntax and grammar of the > language of the statement in question, will enter into a stateful > process of evaluating a, b and performing a calculation of b(remainder > a b) and the act of performing those calculations affects the state of > the "machine" performing the operation. That seems to me to need too much. I agree with a key part of what you are saying -- that any notation must be associated with a "meaning" but it does not have to be one that is state-based in the usual sense of the word. For example, the reduction of lambda forms gives meaning to notations like the one above without inducing what more people would call a state-based sequence of calculations. But there's a terminology issue here too. If you think of the sequence of reduction as "states" then you are, of course, correct, but then you have to say that 1+2 is a "stateful" algorithm. > Or is it your assertion that a parser of the above function statement > is not stateful? I'd like to avoid that term altogether. A string written in some notion together with some rules that give the notation meaning constitute an algorithm. The rules are usually implicit, so a while-loop to calculate GCD has implied rules just as the notation above does. Both, to my mind, represent algorithms. The key things is that many of the questions we ask about algorithms have questions that only make sense in terms of these implicit rules. For example, we might want to know if the algorithm is linear in n. The answer will be in terms of the number of reductions, or of loop iterations, or of mod operations or some such. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-31 03:01 -0700 |
| Message-ID | <b0f43029-bede-4fd2-9503-518f1c18e62a@googlegroups.com> |
| In reply to | #68730 |
On Monday, August 31, 2015 at 12:04:50 AM UTC+1, Ben Bacarisse wrote: > Geoff <geoff@invalid.invalid> writes: > > I'd like to avoid that term altogether. A string written in some notion > together with some rules that give the notation meaning constitute an > algorithm. The rules are usually implicit, so a while-loop to calculate > GCD has implied rules just as the notation above does. Both, to my > mind, represent algorithms. > And it's got to by physically realisable. For example, we can produce a formula for probability based on a partial integral of the normal distribution. (The area under the bell curve from the lower bound to the upper). But it doesn't have a closed form, and we can't actually implement infinitesimal steps. We can of course take a lot of very small steps, and that can be our algorithm.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-31 12:11 +0100 |
| Message-ID | <87613vvhki.fsf@bsb.me.uk> |
| In reply to | #68742 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, August 31, 2015 at 12:04:50 AM UTC+1, Ben Bacarisse wrote: >> Geoff <geoff@invalid.invalid> writes: >> >> I'd like to avoid that term altogether. A string written in some notion >> together with some rules that give the notation meaning constitute an >> algorithm. The rules are usually implicit, so a while-loop to calculate >> GCD has implied rules just as the notation above does. Both, to my >> mind, represent algorithms. >> > And it's got to by physically realisable. I don't know what that means. Really I don't. The only restriction that I would make is that the underlying model be Turing equivalent, so that an algorithm is just another terms for an "effective procedure". But this is a theoretical restriction, not a physical one. I think the term "physically realisable" is sometimes used to refer to this theoretical restriction. If that's what you mean, we are in agreement (though I would suggest you use some other term). > For example, we can produce a formula for probability based on a > partial integral of the normal distribution. (The area under the > bell curve from the lower bound to the upper). (I think you mean definite integral.) > But it doesn't have > a closed form, and we can't actually implement infinitesimal steps. > We can of course take a lot of very small steps, and that can be our > algorithm. I don't think we are as far apart as you might think; the sticky part is the term "closed form". It usually comes with an unstated set of basic functions that are permitted, but if erf(x) is one of them (it usually isn't), the definite integral *does* have a closed form. You can examine algorithms that use it in various ways, and you can perform finite computations using it (all good symbolic maths program will do so for example). It does not stop being an algorithm because the result is not a floating point number. In CS you also see the term algorithm used in the context of oracle machines. Such machines permit, for example, polynomial-time algorithms for NP-complete problems, and it seems to me reasonable to study them and call them algorithms, even though the question of whether they are realisable as effective procedures is still open. The same term is also used in the context of oracle machines that are provably *not* Turing-equivalent (such as a machine with a halting oracle). This very general use is not the common one, I agree, but it illustrates my main point: the term algorithm is always relative to some model of computation. I everyday use that model should be Turing-complete. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-31 06:31 -0700 |
| Message-ID | <38e6e21a-701c-4683-a778-a0004f3edd4f@googlegroups.com> |
| In reply to | #68747 |
On Monday, August 31, 2015 at 12:11:20 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > And it's got to by physically realisable. > > I don't know what that means. Really I don't. The only restriction > that I would make is that the underlying model be Turing equivalent, so > that an algorithm is just another terms for an "effective procedure". > But this is a theoretical restriction, not a physical one. > A perfectly adequate definition of PI is "Take a circle, find the length of the circumference and the length of a line passing through the centre with endpoints where it intersects the circumference. Then find their proportion and express it as a denary decimal point number." It's not an algorithm, because it's not physically realisable. If we say Take the series 1 - 1/3 + 1/5 - 1/7 + 1/9 ... we've got an algorithm. It's not much use if we're using pencil and paper, but it's perfectly feasible for decent precision on a computer, even a slow one. Both definitions are mathematically correct. The first can be turned into an algorithm if we specify how the measuring and intersection is to be done, and an algorithm for a computer if we can specify it digitally. We could for example say "Take a raster. Fill every point where (x- width/2)*(x-width/2)+(y-width/2)*(y-width/2) < (width-2)*(width -2). Now take all set pixels with an unset neighbour ... ". The second can trivially be turned into a algorithm if you want to split hairs. > > I think the term "physically realisable" is sometimes used to refer to > this theoretical restriction. If that's what you mean, we are in > agreement (though I would suggest you use some other term). > No, because the second method is ineffective with pencil and paper, but still an algorithm. The difference is that the first method is inherently not physically realisable because it requires something which exists only in the Platonic world of forms. > > > For example, we can produce a formula for probability based on a > > partial integral of the normal distribution. (The area under the > > bell curve from the lower bound to the upper). > > (I think you mean definite integral.) > Sorry, yes. > > But it doesn't have > > a closed form, and we can't actually implement infinitesimal steps. > > We can of course take a lot of very small steps, and that can be our > > algorithm. > > I don't think we are as far apart as you might think; the sticky part is > the term "closed form". It usually comes with an unstated set of basic > functions that are permitted, but if erf(x) is one of them (it usually > isn't), the definite integral *does* have a closed form. You can > examine algorithms that use it in various ways, and you can perform > finite computations using it (all good symbolic maths program will do so > for example). It does not stop being an algorithm because the result is > not a floating point number. > > In CS you also see the term algorithm used in the context of oracle > machines. Such machines permit, for example, polynomial-time algorithms > for NP-complete problems, and it seems to me reasonable to study them > and call them algorithms, even though the question of whether they are > realisable as effective procedures is still open. The same term is also > used in the context of oracle machines that are provably *not* > Turing-equivalent (such as a machine with a halting oracle). > I'd say that's a case of marginal use of a word. The classic joke is "You got two privates, a sergeant, and a commissioned officer, a 50 foot flag pole, a flag, and a 30 foot rope. How do you erect the flagpole?" Answer, the officer says "Sergeant, erect this flagpole" and walks away. It's kind of a solution, but not really answering the question. > > This very general use is not the common one, I agree, but it illustrates > my main point: the term algorithm is always relative to some model of > computation. I everyday use that model should be Turing-complete. > And also relative to some model of understanding. You've got to describe the process at a level that a human can understand it. (It's no use describing the quantum mechanical states of the electrons in the transistor, and then offering that as an "algorithm" for adding two integers).
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-08-31 10:24 -0400 |
| Message-ID | <3tZEx.2161$z91.1355@fx22.iad> |
| In reply to | #68751 |
On Monday August 31 2015 09:31, in comp.lang.c, "Malcolm McLean"
<malcolm.mclean5@btinternet.com> wrote:
> On Monday, August 31, 2015 at 12:11:20 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > And it's got to by physically realisable.
>>
>> I don't know what that means. Really I don't. The only restriction
>> that I would make is that the underlying model be Turing equivalent, so
>> that an algorithm is just another terms for an "effective procedure".
>> But this is a theoretical restriction, not a physical one.
>>
> A perfectly adequate definition of PI is "Take a circle, find the length
> of the circumference and the length of a line passing through the
> centre with endpoints where it intersects the circumference. Then
> find their proportion and express it as a denary decimal point number."
>
> It's not an algorithm,
I disagree.
Using Knuth's metrics for an algorithm ("The Art of Computer Programming
Volume 1: Fundamental Algorithms", Chapter One "Basic Concepts"), what you
have described above /is/ an algorithm, as it satisfies the five requirements
of an algorithm:
1) Finiteness ("An algorithm must always terminate after a finite number of
steps.") The "definition of PI" above satisfies this as it terminates after
a fixed number of steps (5, to my count)
2) Definiteness ("Each step of an algorithm must be precisely defined; the
actions to be carried out must be rigorously and unambiguously specified
for each case.") The above "definition of PI" satisfies this as well.
3) Input ("An algorithm has zero or more inputs, i.e., quantities which are
given to it initially before the algorithm begins.") Enough said there;
your "definition of PI" satisfies this requirement.
4) Output ("An algorithm has one or more outputs, i.e., quantities which have
a specified relation to the inputs.") Again, enough said there;
your "definition of PI" satisfies this requirement with it's last step.
5) Effectiveness ("An algorithm is also generally expected to be effective.
This means that all of the operations to be performed in the algorithm must
be sufficiently basic that they can in principle be done exactly and in a
finite length of time by a man using pencil and paper.") Again,
your "definition of PI" satisfies this requirement.
> because it's not physically realisable.
Define "physically realisable", please. Or, at least, show a simple,
definitive example.
> If we say
> Take the series
>
> 1 - 1/3 + 1/5 - 1/7 + 1/9 ...
>
> we've got an algorithm.
Not according to Knuth's metrics. Above does not satisfy his requirements 1
("Finiteness") and 5 ("Effectiveness"), as what you have expressed is an
infinite series, taking infinite time to compute. Additionally, your output
(requirement 4) seems to be implied, and not explicitly expressed.
[snip]
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-31 18:04 +0100 |
| Message-ID | <8737yzpexn.fsf@bsb.me.uk> |
| In reply to | #68751 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, August 31, 2015 at 12:11:20 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > And it's got to by physically realisable. >> >> I don't know what that means. Really I don't. The only restriction >> that I would make is that the underlying model be Turing equivalent, so >> that an algorithm is just another terms for an "effective procedure". >> But this is a theoretical restriction, not a physical one. >> > A perfectly adequate definition of PI is "Take a circle, find the length > of the circumference and the length of a line passing through the > centre with endpoints where it intersects the circumference. Then > find their proportion and express it as a denary decimal point number." > > It's not an algorithm, because it's not physically realisable. It's not an algorithm because it does not terminate. There is no decimal representation of the pi. Maybe you meant "... to three decimals" or something like that? Anyway, if we somehow fix that, it is an algorithm provided you specify the model of computation. I can specify a model that makes it a fine algorithm, but you will consider it cheating. Because pi *is* the ratio in question, any model of computation that has (a) objects like circles, (b) real-valued lengths and (c) finite-precision representations of these reals already "knows" pi in some sense. But I accept that you'll have a different defintion of algorithm (that's hardly going to come a s surprise to me) but I'm trying here to understand what you mean by "physically realisable" and that example did not help. > If we say > Take the series > > 1 - 1/3 + 1/5 - 1/7 + 1/9 ... > > we've got an algorithm. It's not much use if we're using pencil and > paper, but it's perfectly feasible for decent precision on a computer, > even a slow one. Why is this "physically realisable" and a model of circles and lines is not? But I accept that you'll have a different defintion of algorithm (that's hardly going to come a s surprise to me) but I'm trying here to understand what you mean by "physically realisable" and this example does not help. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-31 11:28 -0700 |
| Message-ID | <fb3fc88c-a00b-4416-b75b-98e29c9df6e7@googlegroups.com> |
| In reply to | #68762 |
On Monday, August 31, 2015 at 6:04:46 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Why is this "physically realisable" and a model of circles and lines is > not? But I accept that you'll have a different defintion of algorithm > (that's hardly going to come a s surprise to me) but I'm trying here to > understand what you mean by "physically realisable" and this example > does not help. > We can't physically create a perfect circle. We can get pretty close to it, but there's always a bit of flexibility in our paper that makes it not quite the Euclidean plane. Even if we could create such a circles, it's not clear how we would set about taking its circumference. However we can can have an exact representation of the ratios 1:1, 1 :3, 1:5, 1:7 1:9 and so on. We can push that arbitrarily far, though not to infinity. The practical implication is that you can code the second algorithm in a few minutes (If you're prepared to accept that machine precision is your limit), the first one you can't.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-01 00:31 +0100 |
| Message-ID | <87wpwbnig7.fsf@bsb.me.uk> |
| In reply to | #68773 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, August 31, 2015 at 6:04:46 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> Why is this "physically realisable" and a model of circles and lines is
>> not? But I accept that you'll have a different defintion of algorithm
>> (that's hardly going to come a s surprise to me) but I'm trying here to
>> understand what you mean by "physically realisable" and this example
>> does not help.
>>
> We can't physically create a perfect circle.
Of course you can -- at least in the same sense that your seem be using
below. The following set of symbols, written in crayon on paper, does
the job:
C(o, r) = { p in RxR | dist(p, o) = r }
> We can get pretty close
> to it, but there's always a bit of flexibility in our paper that
> makes it not quite the Euclidean plane. Even if we could create such
> a circles, it's not clear how we would set about taking its circumference.
> However we can can have an exact representation of the ratios 1:1, 1 :3,
> 1:5, 1:7 1:9 and so on. We can push that arbitrarily far, though not
> to infinity.
What exact physical representation of these ratios do you have in mind
if not a symbolic one like the one you've just used?
The distinguishable voltages and charges used in conventional computers
permit a set of discrete symbols to be defined. These allow
representations of perfect circles to be computed with in the same way
that they permit representations of perfect ratios to be computed with.
What matters is the symbols and the rules about manipulating them which
is why I prefer to stop at the abstract symbolic representation, but
all such discrete systems can be "physically represented" unless I'm
still missing what you mean by the term.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-31 17:19 -0700 |
| Message-ID | <3ddd653e-e884-4042-8c0b-2276e542eb58@googlegroups.com> |
| In reply to | #68786 |
On Tuesday, September 1, 2015 at 12:31:46 AM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > We can't physically create a perfect circle.
>
> Of course you can -- at least in the same sense that your seem be using
> below. The following set of symbols, written in crayon on paper, does
> the job:
>
> C(o, r) = { p in RxR | dist(p, o) = r }
>
> > We can get pretty close
> > to it, but there's always a bit of flexibility in our paper that
> > makes it not quite the Euclidean plane. Even if we could create such
> > a circles, it's not clear how we would set about taking its circumference.
> > However we can can have an exact representation of the ratios 1:1, 1 :3,
> > 1:5, 1:7 1:9 and so on. We can push that arbitrarily far, though not
> > to infinity.
>
> What exact physical representation of these ratios do you have in mind
> if not a symbolic one like the one you've just used?
>
> The distinguishable voltages and charges used in conventional computers
> permit a set of discrete symbols to be defined. These allow
> representations of perfect circles to be computed with in the same way
> that they permit representations of perfect ratios to be computed with.
>
> What matters is the symbols and the rules about manipulating them which
> is why I prefer to stop at the abstract symbolic representation, but
> all such discrete systems can be "physically represented" unless I'm
> still missing what you mean by the term.
>
The "physical representation of the number" is analogous to your
"physical representation of a circle". Fair enough. It's just
some symbols to which we attach a meaning. The difference is that
we can do the manipulations sum and divide, although admittedly
it's very hard to do them perfectly, and we can then convert to
the denary representation which is what we want as our final result.
However it's not clear to me how you manipulate the set notation for
a circle to get the circumference, in denary notation.
(If we drop the requirement for a perfect circle, we can of course
use the circumference / diameter algorithm, we digitise a Cartesian
plane in x, y, and make pixels containing the set white and background
pixels black. We then say that a line from pixel centre to pixel
centre approximates the circumference. That will give us an estimate
of PI. If we were ancient Greeks, unsure of what we were dealing
with, we'd probably explore that sort of approach, as Mandelbrot
did with his set).
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-31 22:18 -0400 |
| Message-ID | <QV7Fx.296$to.78@fx14.iad> |
| In reply to | #68791 |
On 8/31/15 8:19 PM, Malcolm McLean wrote: > The "physical representation of the number" is analogous to your > "physical representation of a circle". Fair enough. It's just > some symbols to which we attach a meaning. The difference is that > we can do the manipulations sum and divide, although admittedly > it's very hard to do them perfectly, and we can then convert to > the denary representation which is what we want as our final result. > > However it's not clear to me how you manipulate the set notation for > a circle to get the circumference, in denary notation. > You may need a slightly different notation, but if you just integrate the distance traveled while navigating around the circle one full revolution. We can do this to get an arbitrary precision just as we can compute to an arbitrary precision the value of sqrt(2).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-01 13:32 +0100 |
| Message-ID | <87fv2ynwux.fsf@bsb.me.uk> |
| In reply to | #68791 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, September 1, 2015 at 12:31:46 AM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > We can't physically create a perfect circle.
>>
>> Of course you can -- at least in the same sense that your seem be using
>> below. The following set of symbols, written in crayon on paper, does
>> the job:
>>
>> C(o, r) = { p in RxR | dist(p, o) = r }
>>
>> > We can get pretty close
>> > to it, but there's always a bit of flexibility in our paper that
>> > makes it not quite the Euclidean plane. Even if we could create such
>> > a circles, it's not clear how we would set about taking its circumference.
>> > However we can can have an exact representation of the ratios 1:1, 1 :3,
>> > 1:5, 1:7 1:9 and so on. We can push that arbitrarily far, though not
>> > to infinity.
>>
>> What exact physical representation of these ratios do you have in mind
>> if not a symbolic one like the one you've just used?
>>
>> The distinguishable voltages and charges used in conventional computers
>> permit a set of discrete symbols to be defined. These allow
>> representations of perfect circles to be computed with in the same way
>> that they permit representations of perfect ratios to be computed with.
>>
>> What matters is the symbols and the rules about manipulating them which
>> is why I prefer to stop at the abstract symbolic representation, but
>> all such discrete systems can be "physically represented" unless I'm
>> still missing what you mean by the term.
>>
> The "physical representation of the number" is analogous to your
> "physical representation of a circle". Fair enough. It's just
> some symbols to which we attach a meaning. The difference is that
> we can do the manipulations sum and divide, although admittedly
> it's very hard to do them perfectly, and we can then convert to
> the denary representation which is what we want as our final result.
>
> However it's not clear to me how you manipulate the set notation for
> a circle to get the circumference, in denary notation.
That's because neither you nor I have presented a model of computation
that manipulates geometric representations. Maybe it can and maybe it
can't (it will always have to terminate with an approximation if it is
to meet the usual definition of algorithm) but if it can't it won't be
because it's limited to something you once called physical
representations.
> (If we drop the requirement for a perfect circle, we can of course
> use the circumference / diameter algorithm, we digitise a Cartesian
> plane in x, y, and make pixels containing the set white and background
> pixels black. We then say that a line from pixel centre to pixel
> centre approximates the circumference. That will give us an estimate
> of PI. If we were ancient Greeks, unsure of what we were dealing
> with, we'd probably explore that sort of approach, as Mandelbrot
> did with his set).
No, the requirement you have to drop is for a perfect answer because pi
has no perfect finite decimal representation. To get a finite answer
you must ask for some specific precision and then the "geometric computer"
could produce it using its representation of a perfect circle.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-09-01 05:37 -0700 |
| Message-ID | <ec811bc1-c363-4bf0-b66e-ce2b7c6e564a@googlegroups.com> |
| In reply to | #68839 |
On Tuesday, September 1, 2015 at 8:32:47 AM UTC-4, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Tuesday, September 1, 2015 at 12:31:46 AM UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>
> >> > We can't physically create a perfect circle.
> >>
> >> Of course you can -- at least in the same sense that your seem be using
> >> below. The following set of symbols, written in crayon on paper, does
> >> the job:
> >>
> >> C(o, r) = { p in RxR | dist(p, o) = r }
> >>
> >> > We can get pretty close
> >> > to it, but there's always a bit of flexibility in our paper that
> >> > makes it not quite the Euclidean plane. Even if we could create such
> >> > a circles, it's not clear how we would set about taking its circumference.
> >> > However we can can have an exact representation of the ratios 1:1, 1 :3,
> >> > 1:5, 1:7 1:9 and so on. We can push that arbitrarily far, though not
> >> > to infinity.
> >>
> >> What exact physical representation of these ratios do you have in mind
> >> if not a symbolic one like the one you've just used?
> >>
> >> The distinguishable voltages and charges used in conventional computers
> >> permit a set of discrete symbols to be defined. These allow
> >> representations of perfect circles to be computed with in the same way
> >> that they permit representations of perfect ratios to be computed with.
> >>
> >> What matters is the symbols and the rules about manipulating them which
> >> is why I prefer to stop at the abstract symbolic representation, but
> >> all such discrete systems can be "physically represented" unless I'm
> >> still missing what you mean by the term.
> >>
> > The "physical representation of the number" is analogous to your
> > "physical representation of a circle". Fair enough. It's just
> > some symbols to which we attach a meaning. The difference is that
> > we can do the manipulations sum and divide, although admittedly
> > it's very hard to do them perfectly, and we can then convert to
> > the denary representation which is what we want as our final result.
> >
> > However it's not clear to me how you manipulate the set notation for
> > a circle to get the circumference, in denary notation.
>
> That's because neither you nor I have presented a model of computation
> that manipulates geometric representations. Maybe it can and maybe it
> can't (it will always have to terminate with an approximation if it is
> to meet the usual definition of algorithm) but if it can't it won't be
> because it's limited to something you once called physical
> representations.
>
> > (If we drop the requirement for a perfect circle, we can of course
> > use the circumference / diameter algorithm, we digitise a Cartesian
> > plane in x, y, and make pixels containing the set white and background
> > pixels black. We then say that a line from pixel centre to pixel
> > centre approximates the circumference. That will give us an estimate
> > of PI. If we were ancient Greeks, unsure of what we were dealing
> > with, we'd probably explore that sort of approach, as Mandelbrot
> > did with his set).
>
> No, the requirement you have to drop is for a perfect answer because pi
> has no perfect finite decimal representation. To get a finite answer
> you must ask for some specific precision and then the "geometric computer"
> could produce it using its representation of a perfect circle.
Do you really not get it, Ben? There are extents which exceed a given
presentation, such as a target resolution. There's no need to have a
perfect circle in any context of our universe because things only go
down to about 10^(-35) or thereabouts. At those levels you're finally
dealing with fundamental physical representations and do not need
infinite precision, but only applicable precision.
Now, in the world of pure math and formulaic manipulation... that's
different. But I was amazed by your responses in this thread:
> > On Tuesday, September 1, 2015 at 12:31:46 AM UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >> > We can't physically create a perfect circle.
> >>
> >> Of course you can...
I honestly thought to myself ... "Wow. He [Ben] doesn't get it."
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-01 16:51 +0100 |
| Message-ID | <87613um92i.fsf@bsb.me.uk> |
| In reply to | #68840 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > Do you really not get it, Ben? No, but since you do maybe you could explain what Malcolm means by "physically realisable" and how I could use that idea to tell what is and is not an algorithm? You might also want to step in and explain why Malcolm is wrong to have conceded the point as he appears to have done (though that may not be the case). I've snipped the rest because it has nothing to do with the argument. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 1 of 15 [1] 2 3 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web