Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #58109 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2015-03-14 23:05 +0100 |
| Last post | 2015-03-18 08:29 -0700 |
| Articles | 20 on this page of 244 — 30 participants |
Back to article view | Back to comp.lang.c
New directions in C jacob navia <jacob@spamsink.net> - 2015-03-14 23:05 +0100
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-15 13:08 +1300
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 14:49 +0100
Re: New directions in C Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-04-07 10:03 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 01:36 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 02:07 -0700
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 11:10 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 10:36 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 11:43 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 11:01 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 13:11 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 12:51 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 06:11 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 13:37 +0000
Re: New directions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 13:44 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 15:23 +0100
Re: New directions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 15:07 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 10:24 -0700
Re: New directions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 19:36 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 16:19 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-16 15:51 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 20:41 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:23 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:34 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:37 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:48 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:52 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 16:05 +0100
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-17 18:58 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-17 12:15 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-17 12:31 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 16:13 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-17 09:50 -0700
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 17:59 +0100
Re: New directions in C Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 17:16 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 18:24 +0100
Re: New directions in C Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 17:46 +0000
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 18:02 +0000
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-17 18:58 +0000
Re: New directions in C fmassei@gmail.com - 2015-03-17 13:04 -0700
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:17 -0700
Re: New directions in C Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-18 14:58 +0000
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-17 11:38 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-03-17 22:59 -0400
Re: New directions in C jacob navia <jacob@jacob.remcomp.fr> - 2015-03-18 09:05 +0100
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-03-18 08:56 -0400
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-18 10:27 +0100
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-17 09:35 -0700
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 17:44 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:11 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:14 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 05:24 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:50 +1300
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 07:21 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-17 01:50 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 21:22 +1300
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:55 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 22:08 +1300
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 07:01 -0700
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-03-16 08:27 -0400
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 13:31 +0100
Re: New directions in C Martin Shobe <martin.shobe@yahoo.com> - 2015-03-16 09:47 -0500
Re: New directions in C Kaz Kylheku <kaz@kylheku.com> - 2015-03-16 17:16 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:15 +0000
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-03-23 12:41 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 10:20 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-16 12:54 +0100
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-16 09:30 -0700
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-03-16 13:14 -0400
Jacob (Was: New directions in C) gazelle@shell.xmission.com (Kenny McCormack) - 2015-03-16 18:07 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 15:27 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-16 16:26 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 10:09 -0700
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-16 11:14 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-17 13:42 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 14:59 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:27 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:34 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 16:18 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:35 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 01:23 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-22 11:00 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-29 16:56 +0000
Re: New directions in C asetofsymbols@gmail.com - 2015-03-29 10:04 -0700
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 10:56 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-29 19:30 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 12:25 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-29 20:46 +0100
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-29 21:46 +0000
Re: New directions in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:43 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 00:33 +0200
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-06 23:13 +0000
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-07 15:46 +1200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 01:37 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-07 21:08 +1200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 02:52 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-07 11:09 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 13:18 +0200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 13:03 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 06:16 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 16:18 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 07:37 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 23:31 +0200
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-18 00:45 +0000
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-07 22:40 -0400
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-08 16:57 +1200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 09:14 +0200
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:14 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 01:52 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-08 21:36 +1200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 02:51 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-08 22:23 +1200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 13:14 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 04:27 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 14:29 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 06:01 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 15:21 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 06:44 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 16:50 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 08:19 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-08 10:55 -0700
Re: New directions in C asetofsymbols@gmail.com - 2015-04-08 22:27 -0700
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-08 11:13 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 21:27 +0200
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-08 13:12 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 09:34 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-09 00:59 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 12:31 +0200
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-09 08:41 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-08 22:48 +0100
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-08 19:03 -0500
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 10:01 +0200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 09:50 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-09 01:18 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-08 12:32 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-08 08:49 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 06:15 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-10 23:18 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-10 23:50 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-11 15:02 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-11 06:44 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-12 16:53 +0200
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-11 10:01 -0500
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-11 09:23 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-11 13:53 -0400
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-12 02:08 -0500
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-12 03:02 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-12 17:07 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-13 01:59 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-13 08:13 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-13 06:50 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-15 09:12 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 07:33 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-16 22:03 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 04:00 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-18 17:26 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 09:46 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:38 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:16 +0000
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-11 11:57 -0400
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-08 08:36 -0400
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 15:01 +0200
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-07 04:58 -0500
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-07 11:16 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 13:30 +0200
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-07 12:03 +0100
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-07 11:32 -0500
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-07 17:12 +0000
Re: New directions in C jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 19:41 +0200
Re: New directions in C Kaz Kylheku <kaz@kylheku.com> - 2015-03-29 18:21 +0000
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-29 21:29 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 14:26 -0700
Re: New directions in C Les Cargill <lcargill99@comcast.com> - 2015-03-29 19:10 -0500
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-30 09:48 +0000
Re: New directions in C jacob navia <jacob@jacob.remcomp.fr> - 2015-03-30 13:14 +0200
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-04-06 12:39 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-29 10:53 -0700
Re: New directions in C Michael Angelo Ravera <maravera@prodigy.net> - 2015-04-09 18:17 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 01:08 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 17:44 -0700
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-10 02:06 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 10:21 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 10:31 +0100
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 11:26 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 11:53 +0100
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 12:22 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 12:46 +0100
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 13:46 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 13:51 +0100
Re: New directions in C Steve Thompson <stevet810@gmail.com> - 2015-04-10 18:54 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 13:11 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 14:10 -0700
Re: New directions in C Steve Thompson <stevet810@gmail.com> - 2015-04-11 17:46 +0000
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-11 23:38 +0100
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 16:35 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 17:19 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-12 00:54 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-12 01:29 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 17:32 -0700
Re: New directions in C Steve Thompson <stevet810@gmail.com> - 2015-04-11 23:33 +0000
Re: New directions in C Reinhardt Behm <rbehm@hushmail.com> - 2015-04-10 09:23 -0300
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 13:31 +0100
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-10 13:29 -0500
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 12:12 -0700
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-10 13:46 -0700
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-10 18:30 -0500
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-11 12:21 -0700
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-12 01:01 -0500
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-12 13:03 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-12 23:29 +0100
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-12 18:54 -0700
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-13 00:52 -0500
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-04-13 08:39 -0400
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-14 02:44 -0500
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:02 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:07 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-17 16:09 +0100
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:19 +0000
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 18:05 +0000
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-17 15:55 +1300
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 08:48 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-17 03:01 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 10:32 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:32 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 21:33 +1300
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-18 08:55 +0000
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 22:13 +1300
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 21:31 +1300
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 09:35 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 09:49 -0700
Re: New directions in C Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-03-16 10:07 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 10:51 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 10:25 +0000
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-16 11:32 +0000
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-16 13:06 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 05:35 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-16 13:46 +0000
Re: New directions in C Kaz Kylheku <kaz@kylheku.com> - 2015-03-16 17:07 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 10:19 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:37 +1300
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 05:42 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-16 10:55 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 09:41 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-18 08:29 -0700
Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-22 01:23 -0700 |
| Message-ID | <464a3f15-e38e-4812-8da4-48b68a5e7e38@googlegroups.com> |
| In reply to | #58609 |
On Saturday, March 21, 2015 at 10:36:07 PM UTC, Richard Bos wrote: > > Admittedly the above may not be true of all your critics in this > newsgroup. Admittedly some of them may actually love your proposals but > hate C, and be here only to play the /agent provocateur/ and prevent > your genius from, once more, elevating C itself to its rightful place > above their preferred C++. Maybe. But one thing is certain: this is not > true of all of us. Some of us criticise your tack because we _prefer_ C > as it is, and think your ideas look too much, not too little, like C++. > They've been three major attempts to extend C, C++, Objective C, and C sharp. Also numerous minor attempts that got no traction. Now Jacob's proposals avoid many of the pitfalls of those three languages. You'd have to do a significant project in all four to really have a qualified opinion, but I can see myself concluding that Jacob's extensions were the best. But there's also a large niche for plain C. Even if lcc becomes very successful, it's unlikely it will be available for every platform within, say, the next decade. So components that have to be totally portable still need to be written in plain C. Then they can link with C++ projects.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-22 11:00 +0000 |
| Message-ID | <mem7bm$lr0$1@dont-email.me> |
| In reply to | #58630 |
On 22/03/2015 08:23, Malcolm McLean wrote: > On Saturday, March 21, 2015 at 10:36:07 PM UTC, Richard Bos wrote: >> >> Admittedly the above may not be true of all your critics in this >> newsgroup. Admittedly some of them may actually love your proposals but >> hate C, and be here only to play the /agent provocateur/ and prevent >> your genius from, once more, elevating C itself to its rightful place >> above their preferred C++. Maybe. But one thing is certain: this is not >> true of all of us. Some of us criticise your tack because we _prefer_ C >> as it is, and think your ideas look too much, not too little, like C++. >> > They've been three major attempts to extend C, C++, Objective C, and > C sharp. Also numerous minor attempts that got no traction. Didn't two of those at least start life as pre-processors for C? That is, a new C-with-extensions language is processed to produce standard C, then it is compiled as normal. That seems a reasonable intermediate step. (I had been thinking of doing something similar - and have done on a very small scale - but C was too quirky and messy to make it worthwhile for the modest enhancements I wanted to demonstrate. It was also far more appealing to create a new language with no baggage.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-03-29 16:56 +0000 |
| Message-ID | <55182d4b.26626234@news.xs4all.nl> |
| In reply to | #58630 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, March 21, 2015 at 10:36:07 PM UTC, Richard Bos wrote: > > > > Admittedly the above may not be true of all your critics in this > > newsgroup. Admittedly some of them may actually love your proposals but > > hate C, and be here only to play the /agent provocateur/ and prevent > > your genius from, once more, elevating C itself to its rightful place > > above their preferred C++. Maybe. But one thing is certain: this is not > > true of all of us. Some of us criticise your tack because we _prefer_ C > > as it is, and think your ideas look too much, not too little, like C++. > > > They've been three major attempts to extend C, C++, Objective C, and > C sharp. Also numerous minor attempts that got no traction. > > Now Jacob's proposals avoid many of the pitfalls of those three > languages. Yes - and it introduces one major new one which trumps all others. To wit... > But there's also a large niche for plain C. ...that jacob has made it clear that he wants his embrace-and-extend monstrosity to _take over_ that niche, not merely live somewhere else alongside it in the same space as C++ and the others. That's my main problem with his ideas. He doesn't just want to provide a library for some people to use with C; he wants to provide _the_ new library which will _be_ C. What he wants is not for there to be another complex, involved, one-size-fits-all alternative _to_ C; no, he wants his complex, involved, one-size-fits-all library to _replace_ C's existing, simple, sleek, useable one. I wouldn't mind if he'd left C itself alone and focused on his project of NaviaC. But he won't. He wants to destroy C by turning it into not-C++-guv'nor-honest-not-at-all. And there won't be anything left for those of us who like simplicity and the KISS principle. Richard
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-03-29 10:04 -0700 |
| Message-ID | <9aa49ffa-454f-4696-9f1c-8fbb49012fb2@googlegroups.com> |
| In reply to | #59217 |
For strto_etc what would be Kiss principle? Overloading strtoNum() can be overload for use in place of strtou32 Strtou64 Strtoi32 strtoi16 etc Depends of the type of input number
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-29 10:56 -0700 |
| Message-ID | <6f9670dc-9fa6-4304-b7ba-8ac3e4d56bc7@googlegroups.com> |
| In reply to | #59219 |
On Sunday, March 29, 2015 at 6:04:34 PM UTC+1, asetof...@gmail.com wrote: > For strto_etc what would be Kiss principle? > Overloading > > strtoNum() > can be overload for use in place of > strtou32 > Strtou64 > Strtoi32 > strtoi16 etc > Depends of the type of input number > My view is that an int should be the size of the address bus. Or, to be more accurate, it should be able to index an arbitrary array. So on a 64 bit machine, int should be 64 bits. In reality, virtually every integer in a typical program is either an index variable, a count of items in memory, or an intermediate used in calculating index variables. I don't say it isn't possible to artificially construct programs where that isn't the case. But mostly data is real, or it's some sort of category which the program will treat internally as an index into a list. The result is that all you really need is strtol(). 64 bit integers with valid values are never going to go above 2^63.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-29 19:30 +0100 |
| Message-ID | <mf9gau$dl3$1@dont-email.me> |
| In reply to | #59224 |
On 29/03/2015 18:56, Malcolm McLean wrote: > On Sunday, March 29, 2015 at 6:04:34 PM UTC+1, asetof...@gmail.com wrote: >> For strto_etc what would be Kiss principle? >> Overloading >> >> strtoNum() >> can be overload for use in place of >> strtou32 >> Strtou64 >> Strtoi32 >> strtoi16 etc >> Depends of the type of input number >> > My view is that an int should be the size of the address bus. Or, to > be more accurate, it should be able to index an arbitrary array. I'm not sure the address bus size is that relevant any more. There might be (going back a bit) 256KB memory but addressed as words, so only 16 bits are needed. Or, and this is more relevant, the address space of typical task might be a fraction of what can be physically addressed. Or the physical memory actually installed is a fraction of what can be theoretically addressed. > So on a 64 bit machine, int should be 64 bits. I suspect few machines will actually have an address bus 64-bits wide! Because it is a colossal amount of memory. The fact might well be that 99% of programs don't need to address more than 2GB or 4GB of code or data. So using 64-bits instead of 32-bits (which is the choice really) is going to be wasteful. (Also, unless you are always addressing char-arrays, then an int32_t array can be 16GB in size and still need only a uint32_t index.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-29 12:25 -0700 |
| Message-ID | <22f26b44-c4c0-4610-8884-6a966347bf32@googlegroups.com> |
| In reply to | #59227 |
On Sunday, March 29, 2015 at 7:30:52 PM UTC+1, Bart wrote: > > > So on a 64 bit machine, int should be 64 bits. > > I suspect few machines will actually have an address bus 64-bits wide! > Because it is a colossal amount of memory. > > The fact might well be that 99% of programs don't need to address more > than 2GB or 4GB of code or data. So using 64-bits instead of 32-bits > (which is the choice really) is going to be wasteful. > > (Also, unless you are always addressing char-arrays, then an int32_t > array can be 16GB in size and still need only a uint32_t index.) > It is a nuisance that 4GB should eb enough for anybody, but isn't quite. But that's where a high-level language comes in. You want to be able to write index_t i; for(i=0;i<N;i++) tot +=x [i]; and know that it will work whatever the size of the array x. But what should index_t be? The current answer is size_t, but that's a poor choice of name, since i doesn't hold a size. Also, it's size_t is unsigned, which is a real nuisance, because frequently you want to test values +/- and index. You want to write if(i < N - 2) x[i+2] = y; without messing about, and without breaking when N < 2. But I'd say index_t is also a poor name. The best name to use for the index type variable is int.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-29 20:46 +0100 |
| Message-ID | <mf9kp7$v91$1@dont-email.me> |
| In reply to | #59231 |
On 29/03/2015 20:25, Malcolm McLean wrote: > On Sunday, March 29, 2015 at 7:30:52 PM UTC+1, Bart wrote: >> (Also, unless you are always addressing char-arrays, then an int32_t >> array can be 16GB in size and still need only a uint32_t index.) >> > It is a nuisance that 4GB should eb enough for anybody, but isn't > quite. > But that's where a high-level language comes in. You want to be able > to write > > index_t i; > > for(i=0;i<N;i++) > tot +=x [i]; > > and know that it will work whatever the size of the array x. > But what should index_t be? The same size as N might be a start! But a bigger issue is the type of tot. N might fit into 16 bits but tot could easily overflow 32 bits, especially if it doesn't start at 0. I understand the desirability of using an index type that will work for colossal arrays as well as ordinary ones. But suppose using a size larger than necessary slows things down and wastes memory? This can be true on 64-bit hardware as well as 32-bit. > The best name to use for the index type variable is int. Probably a typical range of values for standalone int variables will fit comfortably into 8 bits, let alone 16, 32 or the 64-bit size you're suggesting. This by itself wouldn't cause too many problems where the natural machine size is 32 or 64 bits anyway. But when constructing structs , arrays and arrays of structs, and ints are double the size they need to be, this can bloat the data unnecessarily. It's possible to specify exact widths when a particular width is needed, but I think that 'int' is better used when you don't care what the width is, or where you expect that it will probably be enough. In short, when you don't need to worry about it. Use a specific larger width when you know that it will be needed for bigger values. -- BartC
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-03-29 21:46 +0000 |
| Message-ID | <mf9rs6$v2q$1@speranza.aioe.org> |
| In reply to | #59224 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: (snip on strtol) > My view is that an int should be the size of the address bus. Or, to > be more accurate, it should be able to index an arbitrary array. > So on a 64 bit machine, int should be 64 bits. > In reality, virtually every integer in a typical program is either > an index variable, a count of items in memory, or an intermediate > used in calculating index variables. OK, but there are plenty of things to count and index that you know will never be too big for a 32 bit integer. No year will ever have that many days, for example. I suspect that no company will ever employ more than 2**31 employees, or school will ever have more students. But yes, there are many things that people would not have expected to grow that high some years ago, but now have. > I don't say it isn't possible to > artificially construct programs where that isn't the case. But mostly > data is real, or it's some sort of category which the program > will treat internally as an index into a list. On the other hand, Java defines indexing with 32 bit integers, unless they changed it recently. > The result is that all you really need is strtol(). 64 bit integers > with valid values are never going to go above 2^63. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-30 07:43 -0700 |
| Message-ID | <kfn4mp25ywn.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #59224 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, March 29, 2015 at 6:04:34 PM UTC+1, asetof...@gmail.com wrote: >> For strto_etc what would be Kiss principle? >> Overloading >> >> strtoNum() >> can be overload for use in place of >> strtou32 >> Strtou64 >> Strtoi32 >> strtoi16 etc >> Depends of the type of input number > > My view is that an int should be the size of the address bus. Fortunately the C standard is flexible enough to accommodate other points of view.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-07 00:33 +0200 |
| Message-ID | <mfv1hc$86e$1@dont-email.me> |
| In reply to | #59224 |
On 29/03/15 19:56, Malcolm McLean wrote: > On Sunday, March 29, 2015 at 6:04:34 PM UTC+1, asetof...@gmail.com wrote: >> For strto_etc what would be Kiss principle? >> Overloading >> >> strtoNum() >> can be overload for use in place of >> strtou32 >> Strtou64 >> Strtoi32 >> strtoi16 etc >> Depends of the type of input number >> > My view is that an int should be the size of the address bus. Or, to > be more accurate, it should be able to index an arbitrary array. > > So on a 64 bit machine, int should be 64 bits. > > In reality, virtually every integer in a typical program is either > an index variable, a count of items in memory, or an intermediate > used in calculating index variables. I don't say it isn't possible to > artificially construct programs where that isn't the case. But mostly > data is real, or it's some sort of category which the program > will treat internally as an index into a list. Do you have any kind of reference or justification for this claim, or is it merely a reflection of the kinds of program /you/ write? Certainly it seems that for the past 20 years I have been writing artificially constructed programs, because most of my data is integers of one kind or another (with the majority being unsigned, very often of sizes different to "int" and/or the address bus of the target, and almost always given as a fixed size type). And those integers are rarely indexes, or counts of items in memory. My code is mostly for small embedded systems, which is probably very different from the type of code /you/ write, but it makes me wonder how you come up with your ideas about "virtually every integer in a typical program". > > The result is that all you really need is strtol(). 64 bit integers > with valid values are never going to go above 2^63. >
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-04-06 23:13 +0000 |
| Message-ID | <mfv3u7$4kj$1@speranza.aioe.org> |
| In reply to | #59717 |
David Brown <david.brown@hesbynett.no> wrote: > On 29/03/15 19:56, Malcolm McLean wrote: (snip) >> My view is that an int should be the size of the address bus. Or, to >> be more accurate, it should be able to index an arbitrary array. >> So on a 64 bit machine, int should be 64 bits. >> In reality, virtually every integer in a typical program is either >> an index variable, a count of items in memory, or an intermediate >> used in calculating index variables. I don't say it isn't possible to >> artificially construct programs where that isn't the case. But mostly >> data is real, or it's some sort of category which the program >> will treat internally as an index into a list. > Do you have any kind of reference or justification for this claim, > or is it merely a reflection of the kinds of program /you/ write? Well, if you generalize "count of items in memory" to "count of items" or even "count of things" then maybe. > Certainly it seems that for the past 20 years I have been writing > artificially constructed programs, because most of my data is integers > of one kind or another (with the majority being unsigned, very often of > sizes different to "int" and/or the address bus of the target, and > almost always given as a fixed size type). And those integers are > rarely indexes, or counts of items in memory. I was thinking about this not so long ago, in the context of IBM S/360, and the model 20 in particular. The 360/20, unlike the others, has 16 bit registers. Since the largest core available is 16K, they are big enough. It can add or subtract 16 bit integers, but not multiply or divide. But, like other S/360 models, it can do decimal (BCD) arithmetic up to 31 digits (15 for divisor or multiplier), including add, subtract, multiply, divide, and zero and add. For the usual business computing, binary values are indexes or counts, decimal values are actual data. (RPG is most commonly used for such problems.) For physical sciences and engineering, floating point is commonly used, and fixed point for indexing and counting. But in computational biology, fixed point operations are commonly used, in the usual algorithms for processing DNA and protein sequences. > My code is mostly for small embedded systems, which is probably very > different from the type of code /you/ write, but it makes me wonder how > you come up with your ideas about "virtually every integer in a typical > program". >> The result is that all you really need is strtol(). 64 bit integers >> with valid values are never going to go above 2^63. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-07 15:46 +1200 |
| Message-ID | <coh27uFhgfbU5@mid.individual.net> |
| In reply to | #59717 |
David Brown wrote: > On 29/03/15 19:56, Malcolm McLean wrote: >> On Sunday, March 29, 2015 at 6:04:34 PM UTC+1, asetof...@gmail.com wrote: >>> For strto_etc what would be Kiss principle? >>> Overloading >>> >>> strtoNum() >>> can be overload for use in place of >>> strtou32 >>> Strtou64 >>> Strtoi32 >>> strtoi16 etc >>> Depends of the type of input number >>> >> My view is that an int should be the size of the address bus. Or, to >> be more accurate, it should be able to index an arbitrary array. >> >> So on a 64 bit machine, int should be 64 bits. >> >> In reality, virtually every integer in a typical program is either >> an index variable, a count of items in memory, or an intermediate >> used in calculating index variables. I don't say it isn't possible to >> artificially construct programs where that isn't the case. But mostly >> data is real, or it's some sort of category which the program >> will treat internally as an index into a list. > > Do you have any kind of reference or justification for this claim, or is > it merely a reflection of the kinds of program /you/ write? I'm sure it's the latter. > Certainly it seems that for the past 20 years I have been writing > artificially constructed programs, because most of my data is integers > of one kind or another (with the majority being unsigned, very often of > sizes different to "int" and/or the address bus of the target, and > almost always given as a fixed size type). And those integers are > rarely indexes, or counts of items in memory. > > My code is mostly for small embedded systems, which is probably very > different from the type of code /you/ write, but it makes me wonder how > you come up with your ideas about "virtually every integer in a typical > program". My experience matches yours. Most of the (unsigned) integers in the embedded code I write and maintain represents physical quantities read from our output to digital and analogue inputs. In the driver code I write and maintain, integers mainly represent device states. In the system code I write and maintain, integers mainly represent times and sizes. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-07 01:37 -0700 |
| Message-ID | <e4e1b272-2163-423f-803f-9315013ac2e3@googlegroups.com> |
| In reply to | #59717 |
On Monday, April 6, 2015 at 11:33:16 PM UTC+1, David Brown wrote: > > Certainly it seems that for the past 20 years I have been writing > artificially constructed programs, because most of my data is integers > of one kind or another (with the majority being unsigned, very often of > sizes different to "int" and/or the address bus of the target, and > almost always given as a fixed size type). And those integers are > rarely indexes, or counts of items in memory. > > My code is mostly for small embedded systems, which is probably very > different from the type of code /you/ write, but it makes me wonder how > you come up with your ideas about "virtually every integer in a typical > program". > It's rare for an embedded system to process much data. Data is "what is given" to the program. It could be that the embedded system is a hearing aid, which takes a sound wave sampled as 16 bit integers, processes it, and outputs another sound wave to a speaker which accepts 16 bit integers. So in that case, you'd have an exception. However a more typical embedded system would manage three or four buttons, so really it's only got 4 bits of runtime data. But most data is real. The sound wave example I gave is a discretisation of an underlying continuous reality. Most observations or measurements of things in the world aren't integral. Not all, obviously some data is counts of objects, and sometimes the measuring device attached to the computer produces integers even if it's measuring something like a temperature.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-07 21:08 +1200 |
| Message-ID | <cohl4uFhgfbU6@mid.individual.net> |
| In reply to | #59734 |
Malcolm McLean wrote: > On Monday, April 6, 2015 at 11:33:16 PM UTC+1, David Brown wrote: >> >> Certainly it seems that for the past 20 years I have been writing >> artificially constructed programs, because most of my data is integers >> of one kind or another (with the majority being unsigned, very often of >> sizes different to "int" and/or the address bus of the target, and >> almost always given as a fixed size type). And those integers are >> rarely indexes, or counts of items in memory. >> >> My code is mostly for small embedded systems, which is probably very >> different from the type of code /you/ write, but it makes me wonder how >> you come up with your ideas about "virtually every integer in a typical >> program". >> > It's rare for an embedded system to process much data. Data is "what is given" > to the program. It could be that the embedded system is a hearing aid, > which takes a sound wave sampled as 16 bit integers, processes it, and outputs > another sound wave to a speaker which accepts 16 bit integers. So in that > case, you'd have an exception. However a more typical embedded system > would manage three or four buttons, so really it's only got 4 bits of > runtime data. That, to use a crude Americanism, is utter bullshit. It appears to be the conceited opinion of one who has little or no experience with contemporary embedded systems. A more typical "small" embedded systems these days will be performing some form of real time control, reading data from sensors, processing it and outputting values to actuators or peer systems. Some of the larger embedded systems I've worked on were layer 3 IP switches and routers which process vast quantities of data. > But most data is real. The sound wave example I gave is a discretisation of > an underlying continuous reality. Most observations or measurements of things > in the world aren't integral. Not all, obviously some data is counts of objects, > and sometimes the measuring device attached to the computer produces > integers even if it's measuring something like a temperature. What relevance does that twaddle have to the topic? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-07 02:52 -0700 |
| Message-ID | <bef5aad8-af11-41dc-9d62-a8fde0f14eda@googlegroups.com> |
| In reply to | #59737 |
On Tuesday, April 7, 2015 at 10:08:57 AM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > > But most data is real. The sound wave example I gave is a discretisation of > > an underlying continuous reality. Most observations or measurements of things > > in the world aren't integral. Not all, obviously some data is counts of objects, > > and sometimes the measuring device attached to the computer produces > > integers even if it's measuring something like a temperature. > > What relevance does that twaddle have to the topic? > Data by definition has to represent something in the world, outside of the program. And the world is basically continuous. Not everything, of course, the number of students enrolled on a course will always be discrete, amounts of money that can be measured exactly are also discrete. But sounds, lights, temperatures, times, speeds, lengths, weights, concentrations of chemicals, pretty much everything in the physical world that we measure is continuous. Data tends to be real.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-07 11:09 +0100 |
| Message-ID | <mg0ab1$qb5$1@dont-email.me> |
| In reply to | #59741 |
On 07/04/15 10:52, Malcolm McLean wrote: > On Tuesday, April 7, 2015 at 10:08:57 AM UTC+1, Ian Collins wrote: >> Malcolm McLean wrote: >> >> > But most data is real. The sound wave example I gave is a discretisation of >> > an underlying continuous reality. Most observations or measurements of things >> > in the world aren't integral. Not all, obviously some data is counts of objects, >> > and sometimes the measuring device attached to the computer produces >> > integers even if it's measuring something like a temperature. >> >> What relevance does that twaddle have to the topic? Firstly, congratulations are due, Malcolm, for not rising to the bait. (Ian, it is possible to tell a chap he's wrong without telling him he's talking twaddle.) > Data by definition has to represent something in the world, outside of the program. Not necessarily. For example, the size of a program buffer constitutes data. > And the world is basically continuous. That used to be true, but is true no longer. The world has changed, because the way we look at it has changed. (The act of observing changes that which is observed.) And we have changed the way we look at the world because we are able to make much better measurements nowadays. This is largely due to the advance of digital technology. (The act of observing changes the observer.) Length is no longer continuous. It is a multiple of the Planck length. Time is no longer continuous. It is effectively a multiple of the Planck length too, since time and space are so inextricably entwined. Temperature is no longer continuous. It has a (rather involved) relationship to energy, which is digital (a multiple of the energy in a quantum packet). Velocity is no longer continuous (because neither length nor time is continuous). Mass is no longer continuous, because it's the sum of the masses of particles with discrete masses (electrons, protons, neutrons). Weight (and force in general) is no longer continuous, because it's derived from discrete fundamental quantities. Concentrations of chemicals are of course ratios of discrete quantities, so they're not continuous either. > Not everything, of course, the number of > students enrolled on a course will always be discrete, And, hopefully, an integer. :-) > amounts of money that can > be measured exactly are also discrete. But sounds, lights, temperatures, times, > speeds, lengths, weights, concentrations of chemicals, pretty much everything > in the physical world that we measure is continuous. Data tends to be real. Pretty much everything in the physical world that we measure is discrete, if we can get down far enough into the nitty, and possibly also the gritty. A so-called 'real' number is really just a mathematical construct. The world turns on a digital axis. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-07 13:18 +0200 |
| Message-ID | <mg0eck$b0d$1@dont-email.me> |
| In reply to | #59743 |
On 07/04/15 12:09, Richard Heathfield wrote: > On 07/04/15 10:52, Malcolm McLean wrote: >> On Tuesday, April 7, 2015 at 10:08:57 AM UTC+1, Ian Collins wrote: >>> Malcolm McLean wrote: >>> >>> > But most data is real. The sound wave example I gave is a >>> discretisation of >>> > an underlying continuous reality. Most observations or measurements >>> of things >>> > in the world aren't integral. Not all, obviously some data is >>> counts of objects, >>> > and sometimes the measuring device attached to the computer produces >>> > integers even if it's measuring something like a temperature. >>> >>> What relevance does that twaddle have to the topic? > > Firstly, congratulations are due, Malcolm, for not rising to the bait. > > (Ian, it is possible to tell a chap he's wrong without telling him he's > talking twaddle.) > I think Ian is the one to congratulate here for using such restrained terms as "twaddle" and "utter bullshit". I have plenty of respect for Malcolm's knowledge and experience within his programming niche, but embedded programming, of the sort Ian and I am referring to, is /completely/ alien to him. He is doing himself no favours by digging this hole any deeper.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-07 13:03 +0200 |
| Message-ID | <mg0dh1$7hs$1@dont-email.me> |
| In reply to | #59741 |
On 07/04/15 11:52, Malcolm McLean wrote: > On Tuesday, April 7, 2015 at 10:08:57 AM UTC+1, Ian Collins wrote: >> Malcolm McLean wrote: >> >>> But most data is real. The sound wave example I gave is a discretisation of >>> an underlying continuous reality. Most observations or measurements of things >>> in the world aren't integral. Not all, obviously some data is counts of objects, >>> and sometimes the measuring device attached to the computer produces >>> integers even if it's measuring something like a temperature. >> >> What relevance does that twaddle have to the topic? >> > Data by definition has to represent something in the world, outside of the program. > And the world is basically continuous. Not everything, of course, the number of > students enrolled on a course will always be discrete, amounts of money that can > be measured exactly are also discrete. But sounds, lights, temperatures, times, > speeds, lengths, weights, concentrations of chemicals, pretty much everything > in the physical world that we measure is continuous. Data tends to be real. > No, data does not tend to be "real". Data coming in tends to be either some sort of control data, in which case it is usually discrete (integers, flags, bits, etc.), or it is digitally sampled - in which case it is an integer with some sort of scaling (from a timer, an analogue to digital converter, or whatever). If you think you are working with "real" data just because you are using floating point, or that you have more "accuracy" or "precision" because you use floating point, then you are delusional. You might find that it convenient to convert the integral data into floating point formats because it lets you write code without having to worry about details of scaling the data. But that is nothing more than a programming convenience - it does not improve accuracy, or change the nature of the data. And data out is similarly integral - it is either clearly discrete control data (turn on a value, show a value on a screen, log some data), or practically digital (PWM, digital to analogue converter, etc.).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-07 06:16 -0700 |
| Message-ID | <137b2f84-74b5-440b-a33e-9f683b1a46c7@googlegroups.com> |
| In reply to | #59748 |
On Tuesday, April 7, 2015 at 12:04:00 PM UTC+1, David Brown wrote: > > No, data does not tend to be "real". Data coming in tends to be either > some sort of control data, in which case it is usually discrete > (integers, flags, bits, etc.), or it is digitally sampled - in which > case it is an integer with some sort of scaling (from a timer, an > analogue to digital converter, or whatever). If you think you are > working with "real" data just because you are using floating point, or > that you have more "accuracy" or "precision" because you use floating > point, then you are delusional. > > You might find that it convenient to convert the integral data into > floating point formats because it lets you write code without having to > worry about details of scaling the data. But that is nothing more than > a programming convenience - it does not improve accuracy, or change the > nature of the data. > > And data out is similarly integral - it is either clearly discrete > control data (turn on a value, show a value on a screen, log some data), > or practically digital (PWM, digital to analogue converter, etc.). > Accuracy and resolution aren't the same thing. If you ask a businessman what his company turned over, he might say "about a hundred thousand pounds". You're likely to record that as £100,000. But the actual turnover could be about 75,000 to 150,000 and he's still being truthful. So your resolution is one pound, your accuracy +/- 50%. Digital computers can't deal with analogue values, so in a sense all the data will be rational. But floating point protects you from that. You can use scaled integers (they're not really integers, they're fixed point values), but floats are easier to program, self documenting in terms of scaling, and degrade gracefully when representation limits are approached. You can occasionally get bitten because a float isn't really continuous.
[toc] | [prev] | [next] | [standalone]
Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web