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 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-08 10:55 -0700 |
| Message-ID | <728ace83-eae7-4240-a7ee-7f9e35f5c3db@googlegroups.com> |
| In reply to | #59826 |
imo more interesting than considering integers ic considering computer build on no nomeric states such computer need something like sorta handles (to adress memory), and some oparations to transform states - not necessary numeric like integers - - though when adresing pices quick way is to inc dec operations, if you got inc,, you can repeat and you have +n operation, if you repeat it then you got mul operation, so you have integers - so there as it seem is not so long way leading to integers in computer world, but the base of computers is not necessary numeric 9it may be shorter)
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-04-08 22:27 -0700 |
| Message-ID | <53ddd59d-9065-4568-aaff-85cea1591003@googlegroups.com> |
| In reply to | #59834 |
I have in C++ one class of signed integer, one of unsigned, one for fixed point all limited only from quantity of memory... The float fixed point number are unlimited.precision where one can change precision for all float fixed point using one function Eg. MakePrecision(128) And make all fixed point would be .128, they will have 128 bit after the . They are internally the same data object, change only functions and operation one applying to them But not use that library too much, I don't know if it is really good, because it is a little complicated and can hide errors.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-08 11:13 -0700 |
| Message-ID | <87wq1mv68b.fsf@kst-u.example.com> |
| In reply to | #59824 |
David Brown <david.brown@hesbynett.no> writes:
> On 08/04/15 15:44, Malcolm McLean wrote:
[...]
> We have now established that /data/ comes in to a computer system as
> integers, even if it is created by measuring a real, continuous,
> analogue object. The data is integer or discrete, not real (either in
> the sense of being a real number, or floating point, or a real object).
It's at least possible for data to come into a computer system in a
floating-point format. Of course any such format is made up of discrete
bits, but it's reasonably thought of as a representation of a real
value. I suppose that's probably rare in embedded systems.
[...]
>> Of course we can't have true analogue values in a digital computer. Floating
>> point numbers are to the mathematician rationals (except for infinity / NaN).
>
> No - when you actually need to deal with rationals (which is rare except
> in highly mathematical programs), you use rationals. Floating point
> numbers are convenient approximations to real numbers, not rationals.
I think what Malcolm meant is that all representable floating-point
values are *mathematically* rational numbers. Specifically, for a
typical representation such as IEEE, every representable floating-point
value (other than infinities and NaNs) can be expressed exactly as a
ratio of two integers, with the denominator being a power of 2. They
are not actually represented as a ratio of two integers (that's another
possible way to represent a subset of the real numbers, but it's not
floating-point).
>> Fixed point / scaled integers are also rationals, but with the fractional part
>> handled explicitly by the programmer. But everyone on this NG knows that
>> computers are digital technology.
>> It was worth pointing out that in the embedded world you often represent
>> measurements of underlying real values with scaled integers / fixed point.
>
> The data comes into the system as integers, and is (for the most part)
> stored and/or manipulated as integers. The data is not a "rational",
> and does not typically have a "fractional part" (fixed-point types being
> much less common than integers).
C doesn't have built-in support for fixed-point numeric types, but we
can emulate them. A 16-bit signed integer representing a voltage level,
with 0 representing 0 volts, 1 representing 0.125 volts, etc., can be
thought of either as an integer representing voltage in units of 1/8
volt *or* as a fixed-point value with an implicit radix point 3 bits
from the low end representing fractional volts. They're just two
different ways of thinking about the same thing.
Ada, for example, does have built-in support fixed-point types. In Ada,
you could define either:
type Eigth_Volts is range -2**15 .. 2**15-1; -- an integer type
or
type Volts is delta 0.125 range -4096.0 .. 4095.875;
C doesn't have built-in mechanisms to express that distinction.
[...]
I've taken a brief look at TR-18037-embedded-c.pdf, which adds
fixed-point types to C. The _Fract types represent values from -1.0 to
+1.0 as scaled integers; they have fractional bits and no integral bits.
Each of the _Accum types, if I understand it correctly, has both
fractional and integral bits. The number of integral bits must be at
least 8, but is determined by the whim of the implementation. If type
`unsigned _Accum` is 32 bits, for example, the implementation might
choose to give it 16 integral bits and 16 fractional bits; there is then
no way to define a type with 24 integral bits and 8 fractional bits.
I presume the authors know more about the real-world requirements for
fixed-point types than I do, but I'm having difficulty imagining that
that's a good design. It seems to me that both the width and the
precision of a fixed-point type should depend on the application. I
might need 8 fractional bits for one quantity and 24 fractional bits for
another quantity in the same application. Supporting that would mean
adding new syntax to the language, perhaps something like
unsigned _Fixed<24, 8>;
Mixed-type operations are complicated; perhaps that could be handled by
requiring both operands to have the same type, requiring casts to
resolve ambiguities.
Fixed-by-integer multiplication and division are easily defined and
probably nice to have. Fixed-by-fixed multiplication is more
complicated, and fixed-by-fixed division can be *really* messy.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-08 21:27 +0200 |
| Message-ID | <mg3ve5$4ac$1@dont-email.me> |
| In reply to | #59837 |
On 08/04/15 20:13, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 08/04/15 15:44, Malcolm McLean wrote: > > [...] >> We have now established that /data/ comes in to a computer system as >> integers, even if it is created by measuring a real, continuous, >> analogue object. The data is integer or discrete, not real (either in >> the sense of being a real number, or floating point, or a real object). > > It's at least possible for data to come into a computer system in a > floating-point format. Of course any such format is made up of discrete > bits, but it's reasonably thought of as a representation of a real > value. I suppose that's probably rare in embedded systems. > Certainly. In "big" systems, it is perfectly reasonable to write a program that takes its input in the form of floating point data, effectively "real" numbers. In small embedded systems, floating point input data is, as you say, exceedingly rare. (I realise terms such as "small embedded systems" are vague, but the whole discussion here is in vague terms.) As concrete data points, of all the embedded systems I have programmed over the last 20 years, I can only think off-hand of 3 that made significant use of floating point. In one case it was justified - the control algorithms were significantly clearer in floating point. In one case it was before I had learned better ways of achieving the results needed. And in once case it was to speed up development time (also known as "laziness") because the microcontroller on the board happened to be massively overpowered for the task, so efficiency was irrelevant. In all these cases, the floating point values were for intermediary calculations - not for the data itself. > [...] > >>> Of course we can't have true analogue values in a digital computer. Floating >>> point numbers are to the mathematician rationals (except for infinity / NaN). >> >> No - when you actually need to deal with rationals (which is rare except >> in highly mathematical programs), you use rationals. Floating point >> numbers are convenient approximations to real numbers, not rationals. > > I think what Malcolm meant is that all representable floating-point > values are *mathematically* rational numbers. Specifically, for a > typical representation such as IEEE, every representable floating-point > value (other than infinities and NaNs) can be expressed exactly as a > ratio of two integers, with the denominator being a power of 2. They > are not actually represented as a ratio of two integers (that's another > possible way to represent a subset of the real numbers, but it's not > floating-point). That is technically true, and I think you are probably right that this is what Malcolm meant. But his side-track here was simply another way of dodging the issue under discussion. > >>> Fixed point / scaled integers are also rationals, but with the fractional part >>> handled explicitly by the programmer. But everyone on this NG knows that >>> computers are digital technology. >>> It was worth pointing out that in the embedded world you often represent >>> measurements of underlying real values with scaled integers / fixed point. >> >> The data comes into the system as integers, and is (for the most part) >> stored and/or manipulated as integers. The data is not a "rational", >> and does not typically have a "fractional part" (fixed-point types being >> much less common than integers). > > C doesn't have built-in support for fixed-point numeric types, but we > can emulate them. A 16-bit signed integer representing a voltage level, > with 0 representing 0 volts, 1 representing 0.125 volts, etc., can be > thought of either as an integer representing voltage in units of 1/8 > volt *or* as a fixed-point value with an implicit radix point 3 bits > from the low end representing fractional volts. They're just two > different ways of thinking about the same thing. > However, although the integer in your example /could/ be considered "fixed point", it is akin to calling floating point types "rationals" - technically correct, but not actually helpful. "Fixed point" has a more specific meaning in common use in embedded development and perhaps especially in DSP development, typically expressed in the Q format <http://en.wikipedia.org/wiki/Q_%28number_format%29>. Your voltage data here would normally be considered a "scaled integer" - i.e., an integer, with a particular scale of units - rather than a "fixed-point" type. > Ada, for example, does have built-in support fixed-point types. In Ada, > you could define either: > type Eigth_Volts is range -2**15 .. 2**15-1; -- an integer type > or > type Volts is delta 0.125 range -4096.0 .. 4095.875; > C doesn't have built-in mechanisms to express that distinction. > It would be nice if C had such types. I guess we have to make them as C++ template classes :-) > [...] > > I've taken a brief look at TR-18037-embedded-c.pdf, which adds > fixed-point types to C. The _Fract types represent values from -1.0 to > +1.0 as scaled integers; they have fractional bits and no integral bits. Yes, they implement types like Q16 and Q1.15 > > Each of the _Accum types, if I understand it correctly, has both > fractional and integral bits. The number of integral bits must be at > least 8, but is determined by the whim of the implementation. If type > `unsigned _Accum` is 32 bits, for example, the implementation might > choose to give it 16 integral bits and 16 fractional bits; there is then > no way to define a type with 24 integral bits and 8 fractional bits. > > I presume the authors know more about the real-world requirements for > fixed-point types than I do, but I'm having difficulty imagining that > that's a good design. It seems to me that both the width and the > precision of a fixed-point type should depend on the application. I > might need 8 fractional bits for one quantity and 24 fractional bits for > another quantity in the same application. Supporting that would mean > adding new syntax to the language, perhaps something like > > unsigned _Fixed<24, 8>; You may not be an embedded programmer, but you appear understand the issues a lot better than the TR authors! One would think they would have learned that the most important C99 enhancement in the eyes of embedded developers was the standardisation of fixed-size types in <stdint.h>. > > Mixed-type operations are complicated; perhaps that could be handled by > requiring both operands to have the same type, requiring casts to > resolve ambiguities. Usually mixed-type operations can be implemented as a normal integer operation followed by a shift (for multiply/divide), or a shift followed by the integer operation (for add/subtract). > > Fixed-by-integer multiplication and division are easily defined and > probably nice to have. Fixed-by-fixed multiplication is more > complicated, and fixed-by-fixed division can be *really* messy. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-08 13:12 -0700 |
| Message-ID | <87lhi2v0pf.fsf@kst-u.example.com> |
| In reply to | #59843 |
David Brown <david.brown@hesbynett.no> writes:
> On 08/04/15 20:13, Keith Thompson wrote:
[...]
>> C doesn't have built-in support for fixed-point numeric types, but we
>> can emulate them. A 16-bit signed integer representing a voltage level,
>> with 0 representing 0 volts, 1 representing 0.125 volts, etc., can be
>> thought of either as an integer representing voltage in units of 1/8
>> volt *or* as a fixed-point value with an implicit radix point 3 bits
>> from the low end representing fractional volts. They're just two
>> different ways of thinking about the same thing.
>>
>
> However, although the integer in your example /could/ be considered
> "fixed point", it is akin to calling floating point types "rationals"
> -
> technically correct, but not actually helpful. "Fixed point" has a
> more specific meaning in common use in embedded development and
> perhaps especially in DSP development, typically expressed in the Q
> format <http://en.wikipedia.org/wiki/Q_%28number_format%29>.
Calling floating-point types "rationals" is unhelpful because all
floating-point values are rationals, but not all rationals are
floating-point values. 1/3 cannot be represented exactly in
floating-point, for example (unless you have a trinary system).
The representation I described above seems to match Q12.3 or Q13.3,
depending on which of the two conflicting notations you use (the sign
bit may or may not be included). It only differs from an actual
fixed-point Q12.3 or Q13.3 format in that the language doesn't directly
support it. Is there some important distinction that I'm missing?
> Your voltage data here would normally be considered a "scaled integer"
> -
> i.e., an integer, with a particular scale of units - rather than a
> "fixed-point" type.
In terms of both representation and operations, it seems to me that
fixed-point *is* scaled integers. (If you treat the values as integers,
you have to apply the scaling explicitly; is that what you're referring
to?)
>> Ada, for example, does have built-in support fixed-point types. In Ada,
>> you could define either:
>> type Eigth_Volts is range -2**15 .. 2**15-1; -- an integer type
>> or
>> type Volts is delta 0.125 range -4096.0 .. 4095.875;
>> C doesn't have built-in mechanisms to express that distinction.
>>
>
> It would be nice if C had such types. I guess we have to make them as
> C++ template classes :-)
>
>> [...]
>>
>> I've taken a brief look at TR-18037-embedded-c.pdf, which adds
>> fixed-point types to C. The _Fract types represent values from -1.0 to
>> +1.0 as scaled integers; they have fractional bits and no integral bits.
>
> Yes, they implement types like Q16 and Q1.15
>
>> Each of the _Accum types, if I understand it correctly, has both
>> fractional and integral bits. The number of integral bits must be at
>> least 8, but is determined by the whim of the implementation. If type
>> `unsigned _Accum` is 32 bits, for example, the implementation might
>> choose to give it 16 integral bits and 16 fractional bits; there is then
>> no way to define a type with 24 integral bits and 8 fractional bits.
>>
>> I presume the authors know more about the real-world requirements for
>> fixed-point types than I do, but I'm having difficulty imagining that
>> that's a good design. It seems to me that both the width and the
>> precision of a fixed-point type should depend on the application. I
>> might need 8 fractional bits for one quantity and 24 fractional bits for
>> another quantity in the same application. Supporting that would mean
>> adding new syntax to the language, perhaps something like
>>
>> unsigned _Fixed<24, 8>;
>
> You may not be an embedded programmer, but you appear understand the
> issues a lot better than the TR authors! One would think they would
> have learned that the most important C99 enhancement in the eyes of
> embedded developers was the standardisation of fixed-size types in
> <stdint.h>.
>>
>> Mixed-type operations are complicated; perhaps that could be handled by
>> requiring both operands to have the same type, requiring casts to
>> resolve ambiguities.
>
> Usually mixed-type operations can be implemented as a normal integer
> operation followed by a shift (for multiply/divide), or a shift
> followed by the integer operation (for add/subtract).
But you don't know what shift to apply unless you know the target type
as well as both operand types.
For example, multiplying two UQ12.4 values (unsigned, 16 bits, 12
integral, 4 fractional) would logically yield a UQ24.8 result if you
don't want to lose precision. In Ada, fixed-point multiplication and
division are defined as overloaded operators taking arguments and
yielding results of type *universal-fixed* -- which must always be
converted to some specific type. The context of a fixed-by-fixed
multiplication or division must specify the type to which the result is
converted. The compiler then has to figure out how to generate code to
combine 3 possibly distinct types.
One tricky aspect is that one of the operand types might have more range
but less precision than the other.
In C, assuming something like `unsigned _Fixed<24, 8>` is added, you
could require the result of any fixed-by-fixed multiplication or
division to be cast to some specific fixed-point (or arithmetic?) type.
>> Fixed-by-integer multiplication and division are easily defined and
>> probably nice to have. Fixed-by-fixed multiplication is more
>> complicated, and fixed-by-fixed division can be *really* messy.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-09 09:34 +0200 |
| Message-ID | <mg5a0p$4g5$1@dont-email.me> |
| In reply to | #59845 |
On 08/04/15 22:12, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 08/04/15 20:13, Keith Thompson wrote: > [...] >>> C doesn't have built-in support for fixed-point numeric types, but we >>> can emulate them. A 16-bit signed integer representing a voltage level, >>> with 0 representing 0 volts, 1 representing 0.125 volts, etc., can be >>> thought of either as an integer representing voltage in units of 1/8 >>> volt *or* as a fixed-point value with an implicit radix point 3 bits >>> from the low end representing fractional volts. They're just two >>> different ways of thinking about the same thing. >>> >> >> However, although the integer in your example /could/ be considered >> "fixed point", it is akin to calling floating point types "rationals" >> - >> technically correct, but not actually helpful. "Fixed point" has a >> more specific meaning in common use in embedded development and >> perhaps especially in DSP development, typically expressed in the Q >> format <http://en.wikipedia.org/wiki/Q_%28number_format%29>. > > Calling floating-point types "rationals" is unhelpful because all > floating-point values are rationals, but not all rationals are > floating-point values. 1/3 cannot be represented exactly in > floating-point, for example (unless you have a trinary system). > > The representation I described above seems to match Q12.3 or Q13.3, > depending on which of the two conflicting notations you use (the sign > bit may or may not be included). It only differs from an actual > fixed-point Q12.3 or Q13.3 format in that the language doesn't directly > support it. Is there some important distinction that I'm missing? You are correct that your representation matches Q12.3 (with 15 bits mentioned, an extra sign bit is assumed) or Q13.3 (with this version, the MSB may be a sign bit or an extra unsigned bit - there are conflicting opinions on the notation). What you are missing is that for the majority of real cases, people stick to a few specific types of fixed-point - usually covering just the range 0..1 or -1..1, working mostly with the sizes that their hardware supports. There is also the matter of what the variable means or represents. "Fixed point" variables can be a convenient way to store fractions or percentages, while the actual measurement data would be a "scaled integer". Also, you could only call your voltage here a "fixed point" because the LSB happens to represent exactly 0.125V - if it were 0.12V, it is no longer a "fixed point" number but it is still a "scaled integer". In practice, it is not common to be lucky enough to get a scaling that matches a fixed point format. I am not claiming this nomenclature is clear or consistent, however. It may be possible form good clear rules out of this, but I don't have them at the moment. > >> Your voltage data here would normally be considered a "scaled integer" >> - >> i.e., an integer, with a particular scale of units - rather than a >> "fixed-point" type. > > In terms of both representation and operations, it seems to me that > fixed-point *is* scaled integers. (If you treat the values as integers, > you have to apply the scaling explicitly; is that what you're referring > to?) You could certainly say that fixed-point formats are a type of scaled integers. > >>> Ada, for example, does have built-in support fixed-point types. In Ada, >>> you could define either: >>> type Eigth_Volts is range -2**15 .. 2**15-1; -- an integer type >>> or >>> type Volts is delta 0.125 range -4096.0 .. 4095.875; >>> C doesn't have built-in mechanisms to express that distinction. >>> >> >> It would be nice if C had such types. I guess we have to make them as >> C++ template classes :-) >> >>> [...] >>> >>> I've taken a brief look at TR-18037-embedded-c.pdf, which adds >>> fixed-point types to C. The _Fract types represent values from -1.0 to >>> +1.0 as scaled integers; they have fractional bits and no integral bits. >> >> Yes, they implement types like Q16 and Q1.15 >> >>> Each of the _Accum types, if I understand it correctly, has both >>> fractional and integral bits. The number of integral bits must be at >>> least 8, but is determined by the whim of the implementation. If type >>> `unsigned _Accum` is 32 bits, for example, the implementation might >>> choose to give it 16 integral bits and 16 fractional bits; there is then >>> no way to define a type with 24 integral bits and 8 fractional bits. >>> >>> I presume the authors know more about the real-world requirements for >>> fixed-point types than I do, but I'm having difficulty imagining that >>> that's a good design. It seems to me that both the width and the >>> precision of a fixed-point type should depend on the application. I >>> might need 8 fractional bits for one quantity and 24 fractional bits for >>> another quantity in the same application. Supporting that would mean >>> adding new syntax to the language, perhaps something like >>> >>> unsigned _Fixed<24, 8>; >> >> You may not be an embedded programmer, but you appear understand the >> issues a lot better than the TR authors! One would think they would >> have learned that the most important C99 enhancement in the eyes of >> embedded developers was the standardisation of fixed-size types in >> <stdint.h>. >>> >>> Mixed-type operations are complicated; perhaps that could be handled by >>> requiring both operands to have the same type, requiring casts to >>> resolve ambiguities. >> >> Usually mixed-type operations can be implemented as a normal integer >> operation followed by a shift (for multiply/divide), or a shift >> followed by the integer operation (for add/subtract). > > But you don't know what shift to apply unless you know the target type > as well as both operand types. Correct. When the compiler supports the types (like those in the TR), then the compiler has rules to determine the target type, and knows the operand types. Otherwise the programmer will have to do it manually (typically via named function calls like "mult_q15_q7_q23" or whatever - there is no standard that I know of). > > For example, multiplying two UQ12.4 values (unsigned, 16 bits, 12 > integral, 4 fractional) would logically yield a UQ24.8 result if you > don't want to lose precision. Yes. And the operation here is nothing more than an unsigned 16x16->32 bit multiply - handled in C by casting one of the operands to a uint32_t and the other to a uint32_t or uint16_t, and hopefully the compiler will figure out the best 16x16->32 multiply instruction for the given target. It's the down-conversion from UQ24.8 to U12.4 that requires shifting (and possibly loss of the most significant bits - something you don't get when using the more common formats such as UQ0.16, aka UQ16 or Q16). > In Ada, fixed-point multiplication and > division are defined as overloaded operators taking arguments and > yielding results of type *universal-fixed* -- which must always be > converted to some specific type. The context of a fixed-by-fixed > multiplication or division must specify the type to which the result is > converted. The compiler then has to figure out how to generate code to > combine 3 possibly distinct types. > > One tricky aspect is that one of the operand types might have more range > but less precision than the other. Compilers can be smart, but they can't do magic! A big difficulty in adding this sort of thing to the language is that people want different results from similar-looking code. Sometimes they will want the result of a multiply to be put into a bigger type to retain all the bits - sometimes they want it converted into one of the original types. Sometimes they want an add to saturate, sometimes they want it to wrap. Usually they want it all to map to a minimum of target instructions. There are a huge number of combinations possible, making it very hard to code nicely in the language. > > In C, assuming something like `unsigned _Fixed<24, 8>` is added, you > could require the result of any fixed-by-fixed multiplication or > division to be cast to some specific fixed-point (or arithmetic?) type. > >>> Fixed-by-integer multiplication and division are easily defined and >>> probably nice to have. Fixed-by-fixed multiplication is more >>> complicated, and fixed-by-fixed division can be *really* messy. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-09 00:59 -0700 |
| Message-ID | <eebd9369-0d8b-43c0-bcd3-8e490091fcfa@googlegroups.com> |
| In reply to | #59853 |
On Thursday, April 9, 2015 at 8:34:50 AM UTC+1, David Brown wrote: > > You are correct that your representation matches Q12.3 (with 15 bits > mentioned, an extra sign bit is assumed) or Q13.3 (with this version, > the MSB may be a sign bit or an extra unsigned bit - there are > conflicting opinions on the notation). What you are missing is that for > the majority of real cases, people stick to a few specific types of > fixed-point - usually covering just the range 0..1 or -1..1, working > mostly with the sizes that their hardware supports. There is also the > matter of what the variable means or represents. "Fixed point" > variables can be a convenient way to store fractions or percentages, > while the actual measurement data would be a "scaled integer". Also, > you could only call your voltage here a "fixed point" because the LSB > happens to represent exactly 0.125V - if it were 0.12V, it is no longer > a "fixed point" number but it is still a "scaled integer". In practice, > it is not common to be lucky enough to get a scaling that matches a > fixed point format. > > I am not claiming this nomenclature is clear or consistent, however. It > may be possible form good clear rules out of this, but I don't have them > at the moment. > Often you'll want all bits set to represent unity, and it's important that unity is exactly unity. But it's also convenient to have the step size a power of two. Then you can simply take the most significant bits of an integer multiplication. So it can be quite involved to treat fixed point correctly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-09 12:31 +0200 |
| Message-ID | <mg5kcp$7u0$1@dont-email.me> |
| In reply to | #59855 |
On 09/04/15 09:59, Malcolm McLean wrote: > On Thursday, April 9, 2015 at 8:34:50 AM UTC+1, David Brown wrote: >> >> You are correct that your representation matches Q12.3 (with 15 bits >> mentioned, an extra sign bit is assumed) or Q13.3 (with this version, >> the MSB may be a sign bit or an extra unsigned bit - there are >> conflicting opinions on the notation). What you are missing is that for >> the majority of real cases, people stick to a few specific types of >> fixed-point - usually covering just the range 0..1 or -1..1, working >> mostly with the sizes that their hardware supports. There is also the >> matter of what the variable means or represents. "Fixed point" >> variables can be a convenient way to store fractions or percentages, >> while the actual measurement data would be a "scaled integer". Also, >> you could only call your voltage here a "fixed point" because the LSB >> happens to represent exactly 0.125V - if it were 0.12V, it is no longer >> a "fixed point" number but it is still a "scaled integer". In practice, >> it is not common to be lucky enough to get a scaling that matches a >> fixed point format. >> >> I am not claiming this nomenclature is clear or consistent, however. It >> may be possible form good clear rules out of this, but I don't have them >> at the moment. >> > Often you'll want all bits set to represent unity, and it's important > that unity is exactly unity. But it's also convenient to have the step > size a power of two. Then you can simply take the most significant > bits of an integer multiplication. > > So it can be quite involved to treat fixed point correctly. > Yes - that's part of why it is difficult to make a single fixed-point implementation part of the language. Usually you aim for steps that are a (negative) power of 2 - it makes changes of scale and conversions into shifts rather than divisions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-09 08:41 -0700 |
| Message-ID | <87h9spux56.fsf@kst-u.example.com> |
| In reply to | #59853 |
David Brown <david.brown@hesbynett.no> writes:
> On 08/04/15 22:12, Keith Thompson wrote:
[...]
>> The representation I described above seems to match Q12.3 or Q13.3,
>> depending on which of the two conflicting notations you use (the sign
>> bit may or may not be included). It only differs from an actual
>> fixed-point Q12.3 or Q13.3 format in that the language doesn't directly
>> support it. Is there some important distinction that I'm missing?
>
> You are correct that your representation matches Q12.3 (with 15 bits
> mentioned, an extra sign bit is assumed) or Q13.3 (with this version,
> the MSB may be a sign bit or an extra unsigned bit - there are
> conflicting opinions on the notation). What you are missing is that for
> the majority of real cases, people stick to a few specific types of
> fixed-point - usually covering just the range 0..1 or -1..1, working
> mostly with the sizes that their hardware supports. There is also the
> matter of what the variable means or represents. "Fixed point"
> variables can be a convenient way to store fractions or percentages,
> while the actual measurement data would be a "scaled integer". Also,
> you could only call your voltage here a "fixed point" because the LSB
> happens to represent exactly 0.125V - if it were 0.12V, it is no longer
> a "fixed point" number but it is still a "scaled integer". In practice,
> it is not common to be lucky enough to get a scaling that matches a
> fixed point format.
>
> I am not claiming this nomenclature is clear or consistent, however. It
> may be possible form good clear rules out of this, but I don't have them
> at the moment.
Another data point: Ada has built-in fixed-point types, represented as
scaled integers. The scale factor is a power of 2 by default, but it
doesn't have to be.
For example, if I write:
type Volts is delta 0.12 range -100.0 .. +100.0;
Volts'Delta is the declared "delta" of the type, in this case 0.12.
Volts'Small is the actual value used by the representation, the real
value represented by an object whose representation looks like the
integer 1. By default, the 'Small is the largest power of two no
greater than the declared delta. In this case, Volts'Delta = 0.12, and
Volts'Small = 0.0625 (1.0/16.0).
But you can also specify the 'Small value:
type Volts is delta 0.12 range -100.0 .. +100.0;
for Volts'Small use 0.12;
Now both Volts'Delta and Volts'Small are exactly 0.12 -- and 1.0 cannot
be represented exactly as a value of type volts.
Ada calls this a "fixed-point type" in both cases.
>>> Your voltage data here would normally be considered a "scaled integer"
>>> -
>>> i.e., an integer, with a particular scale of units - rather than a
>>> "fixed-point" type.
>>
>> In terms of both representation and operations, it seems to me that
>> fixed-point *is* scaled integers. (If you treat the values as integers,
>> you have to apply the scaling explicitly; is that what you're referring
>> to?)
>
> You could certainly say that fixed-point formats are a type of scaled
> integers.
And in the terminology I've gotten used to, scaled integers and
fixed-point formats are pretty much the same thing. (Not to say that my
terminology is right and yours is wrong.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-08 22:48 +0100 |
| Message-ID | <mg47mj$5l1$1@dont-email.me> |
| In reply to | #59843 |
On 08/04/2015 20:27, David Brown wrote: > Certainly. In "big" systems, it is perfectly reasonable to write a > program that takes its input in the form of floating point data, > effectively "real" numbers. In small embedded systems, floating point > input data is, as you say, exceedingly rare. (I realise terms such as > "small embedded systems" are vague, but the whole discussion here is in > vague terms.) > > As concrete data points, of all the embedded systems I have programmed > over the last 20 years, I can only think off-hand of 3 that made > significant use of floating point. In one case it was justified - the > control algorithms were significantly clearer in floating point. In one > case it was before I had learned better ways of achieving the results > needed. And in once case it was to speed up development time (also > known as "laziness") because the microcontroller on the board happened > to be massively overpowered for the task, so efficiency was irrelevant. > In all these cases, the floating point values were for intermediary > calculations - not for the data itself. Maybe you haven't work on the right kind of application. It's easy to think of an 'embedded' application that works, for example, with graphics, and that makes natural use of floating point. For example, that implements PostScript inside a printer, or OpenGL on a video card. Possibly, you won't count these as 'small', but maybe that's because there are more powerful devices available now so you wouldn't choose some humble 8-bit cpu which would have to emulate floating point in software. (However, since I first start using 8-bit cpus, which didn't even have integer multiply, I've been using them with floating point code.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-08 19:03 -0500 |
| Message-ID | <mg4fkf$q6r$1@speranza.aioe.org> |
| In reply to | #59847 |
On 4/8/15 4:48 PM, Bartc wrote: > Possibly, you won't count these as 'small', but maybe that's because > there are more powerful devices available now so you wouldn't choose > some humble 8-bit cpu which would have to emulate floating point in > software. I (and others) might if the 8-bitter could do the job for a significantly lower product cost. > (However, since I first start using 8-bit cpus, which didn't even have > integer multiply, I've been using them with floating point code.) Me too, and I’ll add that floating point is my clear choice for trig calculations. :-) -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-09 10:01 +0200 |
| Message-ID | <mg5bjo$9gf$1@dont-email.me> |
| In reply to | #59849 |
On 09/04/15 02:03, Morris Dovey wrote: > On 4/8/15 4:48 PM, Bartc wrote: >> Possibly, you won't count these as 'small', but maybe that's because >> there are more powerful devices available now so you wouldn't choose >> some humble 8-bit cpu which would have to emulate floating point in >> software. > > I (and others) might if the 8-bitter could do the job for a > significantly lower product cost. Embedded development is all about balances between development costs, production costs, features, power requirements, and so on. There are still 4-bit microcontrollers in heavy use (though I believe they are no longer dominant in numbers - 8-bitters are more common). > >> (However, since I first start using 8-bit cpus, which didn't even have >> integer multiply, I've been using them with floating point code.) > > Me too, and I’ll add that floating point is my clear choice for trig > calculations. :-) > I once had a customer who specified a large microcontroller with a floating point unit because they wanted to generate a number of sine waves of varying frequency and amplitude. I ended up writing that part of the system using some lookup tables and DMA channels that made the sine waves without any processor usage at all (it was quite cool watching the sine waves from the DACs on an oscilloscope while debugging and single-stepping the processor!). Even for arbitrary sines, my integer code was some 20 times faster than the floating point library code while still having the accuracy needed - because I could write code that fitted the /real/ requirements (of scaling, accuracy, range, etc.) rather than a general library function. Of course, #include <math.h> is a lot easier and faster to write :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-09 09:50 +0200 |
| Message-ID | <mg5auu$7a2$1@dont-email.me> |
| In reply to | #59847 |
On 08/04/15 23:48, Bartc wrote: > On 08/04/2015 20:27, David Brown wrote: > >> Certainly. In "big" systems, it is perfectly reasonable to write a >> program that takes its input in the form of floating point data, >> effectively "real" numbers. In small embedded systems, floating point >> input data is, as you say, exceedingly rare. (I realise terms such as >> "small embedded systems" are vague, but the whole discussion here is in >> vague terms.) >> >> As concrete data points, of all the embedded systems I have programmed >> over the last 20 years, I can only think off-hand of 3 that made >> significant use of floating point. In one case it was justified - the >> control algorithms were significantly clearer in floating point. In one >> case it was before I had learned better ways of achieving the results >> needed. And in once case it was to speed up development time (also >> known as "laziness") because the microcontroller on the board happened >> to be massively overpowered for the task, so efficiency was irrelevant. >> In all these cases, the floating point values were for intermediary >> calculations - not for the data itself. > > Maybe you haven't work on the right kind of application. I have worked on a very wide variety of embedded systems - but for every kind of embedded app I have done, there are 50 more types that I have never worked with. Yes, there are many kinds of embedded systems that work with floating point data (and buffers, and indexes, and "counting things in memory"). > > It's easy to think of an 'embedded' application that works, for example, > with graphics, and that makes natural use of floating point. > > For example, that implements PostScript inside a printer, or OpenGL on a > video card. > > Possibly, you won't count these as 'small', but maybe that's because > there are more powerful devices available now so you wouldn't choose > some humble 8-bit cpu which would have to emulate floating point in > software. Correct - using my own arbitrary, secret and vague definition of "small", I would count a PostScript printer as a "big embedded system". And I can think of a few systems I have made where I would have used floating point, had the processor been powerful enough (with either an FPU or at least a decent integer ALU for emulating it) - it would have made the code easier and the development time faster. So as we see a lot more 32-bit small microcontrollers (dominated by ARM Cortex-M devices) replacing more limited 8-bit and 16-bit microcontrollers, I expect to see more use of floating point to make calculations easier to code. The /data/ will still be scaled integers, at least at the input/output edges of the system - but things like calibration/compensation and control algorithms will see more floating point code. If it leads to shorter development times and clearer code, customers are happy. Having said that, the project I am currently working on has an FPU (single-precision - it's a Cortex M4F), but I have no use for it. Scaled integers are still the most natural format for the inputs and outputs. > > (However, since I first start using 8-bit cpus, which didn't even have > integer multiply, I've been using them with floating point code.) > As long as the device is Turing complete, you can do anything with it! Yes, sometimes it is perfectly fine to do floating point on such devices, and it doesn't matter that the code is big and very slow. I have nothing against using floating point when it is the sensible choice - I merely disagree with the idea that /all/ "data" is inherently floating point, or that it is always a good choice for "data".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-09 01:18 -0700 |
| Message-ID | <4f764d8b-e9e2-406b-acc7-d34d162de833@googlegroups.com> |
| In reply to | #59854 |
On Thursday, April 9, 2015 at 8:50:55 AM UTC+1, David Brown wrote: > > As long as the device is Turing complete, you can do anything with it! > Yes, sometimes it is perfectly fine to do floating point on such > devices, and it doesn't matter that the code is big and very slow. I > have nothing against using floating point when it is the sensible choice > - I merely disagree with the idea that /all/ "data" is inherently > floating point, or that it is always a good choice for "data". > Data tends to be real. That is, the world is basically an analogue place. Of course we can't manipulate genuine analogue values on digital hardware, so we need a digital representation. You've got a point that floating point can be an over-specification on small systems, or on large systems for special cases like audio waves (conventionally 16 bit) or images (conventionally 24 bit).
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-08 12:32 -0700 |
| Message-ID | <0567ce5b-e680-4540-b1d0-d5c4e159211b@googlegroups.com> |
| In reply to | #59837 |
W dniu środa, 8 kwietnia 2015 20:13:20 UTC+2 użytkownik Keith Thompson napisał: > David Brown <david.brown@hesbynett.no> writes: > > On 08/04/15 15:44, Malcolm McLean wrote: > > [...] > > We have now established that /data/ comes in to a computer system as > > integers, even if it is created by measuring a real, continuous, > > analogue object. The data is integer or discrete, not real (either in > > the sense of being a real number, or floating point, or a real object). > > It's at least possible for data to come into a computer system in a > floating-point format. Of course any such format is made up of discrete > bits, but it's reasonably thought of as a representation of a real > value. I suppose that's probably rare in embedded systems. > > [...] > > >> Of course we can't have true analogue values in a digital computer. Floating > >> point numbers are to the mathematician rationals (except for infinity / NaN). > > > > No - when you actually need to deal with rationals (which is rare except > > in highly mathematical programs), you use rationals. Floating point > > numbers are convenient approximations to real numbers, not rationals. > > I think what Malcolm meant is that all representable floating-point > values are *mathematically* rational numbers. Specifically, for a > typical representation such as IEEE, every representable floating-point > value (other than infinities and NaNs) can be expressed exactly as a > ratio of two integers, with the denominator being a power of 2. They > are not actually represented as a ratio of two integers (that's another > possible way to represent a subset of the real numbers, but it's not > floating-point). > > >> Fixed point / scaled integers are also rationals, but with the fractional part > >> handled explicitly by the programmer. But everyone on this NG knows that > >> computers are digital technology. > >> It was worth pointing out that in the embedded world you often represent > >> measurements of underlying real values with scaled integers / fixed point. > > > > The data comes into the system as integers, and is (for the most part) > > stored and/or manipulated as integers. The data is not a "rational", > > and does not typically have a "fractional part" (fixed-point types being > > much less common than integers). > > C doesn't have built-in support for fixed-point numeric types, but we > can emulate them. A 16-bit signed integer representing a voltage level, > with 0 representing 0 volts, 1 representing 0.125 volts, etc., can be > thought of either as an integer representing voltage in units of 1/8 > volt *or* as a fixed-point value with an implicit radix point 3 bits > from the low end representing fractional volts. They're just two > different ways of thinking about the same thing. > > Ada, for example, does have built-in support fixed-point types. In Ada, > you could define either: > type Eigth_Volts is range -2**15 .. 2**15-1; -- an integer type > or > type Volts is delta 0.125 range -4096.0 .. 4095.875; > C doesn't have built-in mechanisms to express that distinction. > > [...] > > I've taken a brief look at TR-18037-embedded-c.pdf, which adds > fixed-point types to C. The _Fract types represent values from -1.0 to > +1.0 as scaled integers; they have fractional bits and no integral bits. > > Each of the _Accum types, if I understand it correctly, has both > fractional and integral bits. The number of integral bits must be at > least 8, but is determined by the whim of the implementation. If type > `unsigned _Accum` is 32 bits, for example, the implementation might > choose to give it 16 integral bits and 16 fractional bits; there is then > no way to define a type with 24 integral bits and 8 fractional bits. > > I presume the authors know more about the real-world requirements for > fixed-point types than I do, but I'm having difficulty imagining that > that's a good design. It seems to me that both the width and the > precision of a fixed-point type should depend on the application. I > might need 8 fractional bits for one quantity and 24 fractional bits for > another quantity in the same application. Supporting that would mean > adding new syntax to the language, perhaps something like > > unsigned _Fixed<24, 8>; > > Mixed-type operations are complicated; perhaps that could be handled by > requiring both operands to have the same type, requiring casts to > resolve ambiguities. > > Fixed-by-integer multiplication and division are easily defined and > probably nice to have. Fixed-by-fixed multiplication is more > complicated, and fixed-by-fixed division can be *really* messy. > ps as i was insulted by this bore above i wonder if i should play simmetric and ask to not feed this simpleton and bore ** ** ofc in my case it would be more like parody as this level of simpletonism is not even really imaginable for me- (as i really do not want to play simmetric and impersonate 'mirror simpleton ' as this moves me to distaste of oryginal simpleton) but maybe such parodistic activity could a bit cure such insulters syupidity? is it worth it? > -- > Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> > Working, but not speaking, for JetHead Development, Inc. > "We must do something. This is something. Therefore, we must do this." > -- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-04-08 08:49 -0400 |
| Message-ID | <Et9Vw.194227$yX2.44892@fx18.iad> |
| In reply to | #59809 |
On 4/8/15 7:27 AM, Malcolm McLean wrote: > I see. > I would naturally use a double and put the reading into SI units (or whatever the > convention was), at a very early stage. But I see that where you've got small > device, or you don't want to drop a bit of accuracy, it might be better to > work with the raw output values. And make your program run 100x slower, as most of these processors DON'T have native floating point (or 64 bit math) so your double requires a LOT of software to compute with. You are very unlikely to lose accuracy, as you are going to use 50+ bits of precision, many more than the likely 16 bits (maybe pushing to 32 bits for some things) in fixed-point. Yes, there is a slight advantage design wise to just shift to "human" units so it is harder to make certain scale factor errors (but watch out that you ARE consistent here, there have been famous examples where this was goofed on). With fixed-point/scaled units you do have to think about what each number represents and think about the range of values that are expected and possible at each point. In my opinion this can be a good thing as it can point out possible numerical problems, like points where you get loss of precision due to information cancellation. (like subtracting to large numbers that are close, and getting a small number with very little accuracy left, it is easy to forget that in floating point).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-08 06:15 -0700 |
| Message-ID | <87b9cbd3-d5be-422c-8111-229c965e53b3@googlegroups.com> |
| In reply to | #59813 |
On Wednesday, April 8, 2015 at 1:49:48 PM UTC+1, Richard Damon wrote: > On 4/8/15 7:27 AM, Malcolm McLean wrote: > > I see. > > I would naturally use a double and put the reading into SI units (or whatever the > > convention was), at a very early stage. But I see that where you've got small > > device, or you don't want to drop a bit of accuracy, it might be better to > > work with the raw output values. > > And make your program run 100x slower, as most of these processors DON'T > have native floating point (or 64 bit math) so your double requires a > LOT of software to compute with. You are very unlikely to lose accuracy, > as you are going to use 50+ bits of precision, many more than the likely > 16 bits (maybe pushing to 32 bits for some things) in fixed-point. > It all depends how much data you have. If you're doing a frequency transform of an audio sample, you've got to handle 41,000 sound pressure measurements per second, and assuming windows of 1024 samples, about ten multiplications for each. So that will stress a small processor. On the other hand if you're measuring temperature and adjusting a heating control, you only need one temperature measurement every minute or so. > > Yes, there is a slight advantage design wise to just shift to "human" > units so it is harder to make certain scale factor errors (but watch out > that you ARE consistent here, there have been famous examples where this > was goofed on). With fixed-point/scaled units you do have to think about > what each number represents and think about the range of values that are > expected and possible at each point. In my opinion this can be a good > thing as it can point out possible numerical problems, like points where > you get loss of precision due to information cancellation. (like > subtracting to large numbers that are close, and getting a small number > with very little accuracy left, it is easy to forget that in floating > point). > That is a point. If you're used to everything being in SI units, then you're likely to make a mistake when handed a dimension measured in centimetres. If you're used to everything being essentially arbitrary scales, then you'll get into the habit of always reading the documentation. You can lose accuracy in floating point, but generally you know where that is a serious risk, e.g. matrix inversions, or geometrical tests on nearly parallel lines.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-04-10 23:18 -0400 |
| Message-ID | <Co0Ww.105160$%p.64174@fx07.iad> |
| In reply to | #59818 |
On 4/8/15 9:15 AM, Malcolm McLean wrote: > On Wednesday, April 8, 2015 at 1:49:48 PM UTC+1, Richard Damon wrote: >> On 4/8/15 7:27 AM, Malcolm McLean wrote: >>> I see. >>> I would naturally use a double and put the reading into SI units (or whatever the >>> convention was), at a very early stage. But I see that where you've got small >>> device, or you don't want to drop a bit of accuracy, it might be better to >>> work with the raw output values. >> >> And make your program run 100x slower, as most of these processors DON'T >> have native floating point (or 64 bit math) so your double requires a >> LOT of software to compute with. You are very unlikely to lose accuracy, >> as you are going to use 50+ bits of precision, many more than the likely >> 16 bits (maybe pushing to 32 bits for some things) in fixed-point. >> > It all depends how much data you have. If you're doing a frequency transform of > an audio sample, you've got to handle 41,000 sound pressure measurements > per second, and assuming windows of 1024 samples, about ten multiplications > for each. So that will stress a small processor. On the other hand if you're measuring > temperature and adjusting a heating control, you only need one temperature > measurement every minute or so. Interesting example. From my experience, temperatures are very suitable for scaled arithmetic, as generally the ratio between the range of values obtainable to the measurement resolution is rarely a large number (somewhat related to the fact that getting near the "natural" zero value is very unusual). I also find your "minute or so" interval as fairly unlikely. Control loops like to be run significantly faster than the dynamics of the controlled plant, or you need significantly more complicated and carefully configured control methods. A minute is a long time to continue heating most things, so a thermal control loop is likely to run faster than that. You also have that adding delays into control loops lowers stability and lowers performance, so even if you don't run out of raw horsepower, you may be increasing costs of complexity in dealing with the added delay due to using the slow floating point. Even a bigger concern, if you are in a limited power situation (like being battery operated), if you computation takes 100 times as long, is also cost about 100 time the energy, so your battery life is one hundredth what it could have been. >> >> Yes, there is a slight advantage design wise to just shift to "human" >> units so it is harder to make certain scale factor errors (but watch out >> that you ARE consistent here, there have been famous examples where this >> was goofed on). With fixed-point/scaled units you do have to think about >> what each number represents and think about the range of values that are >> expected and possible at each point. In my opinion this can be a good >> thing as it can point out possible numerical problems, like points where >> you get loss of precision due to information cancellation. (like >> subtracting to large numbers that are close, and getting a small number >> with very little accuracy left, it is easy to forget that in floating >> point). >> > That is a point. If you're used to everything being in SI units, then you're likely to > make a mistake when handed a dimension measured in centimetres. If > you're used to everything being essentially arbitrary scales, then you'll get > into the habit of always reading the documentation. > You can lose accuracy in floating point, but generally you know where that is a > serious risk, e.g. matrix inversions, or geometrical tests on nearly parallel > lines. > Generally, from what I have seen, if you start out by converting everything to "standard units", generally the program very rapidly loses sense of what the real accuracy is of the numbers, as you now very much need to keep track of the accuracy as a companion number through the whole calculation. When dealing with scaled/fixed point numbers, you are thinking about how the errors are building at each step, as you are evaluating what parts of the answers are worth keeping. Generally, if you have done it right, the fixed point value is mostly meaningful, but a floating point value carries no natural indication of how much error is apt to be in it.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-10 23:50 -0700 |
| Message-ID | <50614ad3-30d5-42ea-8eb7-4f89ca4b32c8@googlegroups.com> |
| In reply to | #59899 |
On Saturday, April 11, 2015 at 4:19:08 AM UTC+1, Richard Damon wrote: > > Interesting example. From my experience, temperatures are very suitable > for scaled arithmetic, as generally the ratio between the range of > values obtainable to the measurement resolution is rarely a large number > (somewhat related to the fact that getting near the "natural" zero value > is very unusual). I also find your "minute or so" interval as fairly > unlikely. Control loops like to be run significantly faster than the > dynamics of the controlled plant, or you need significantly more > complicated and carefully configured control methods. A minute is a long > time to continue heating most things, so a thermal control loop is > likely to run faster than that. > We're heating something with a given thermal capacity, and we have to maintain its temperature at a given level. So essentially we set the heater to the right level and keep it there. However the ambient temperature might change, the performance of our heater might drift, cold substances might be added or hot substances drawn off. So we'll need to adjust the heater setting occasionally. But unless our tolerances are very fine, or the heat capacity very low, it's unlikely we'll need to change the heater settings more than once per minute. It takes about two minutes to boil a kettle, which gives you some idea of the thermal capacity of water. > > You also have that adding delays into control loops lowers stability and > lowers performance, so even if you don't run out of raw horsepower, you > may be increasing costs of complexity in dealing with the added delay > due to using the slow floating point. > > Even a bigger concern, if you are in a limited power situation (like > being battery operated), if you computation takes 100 times as long, is > also cost about 100 time the energy, so your battery life is one > hundredth what it could have been. > But you can't have both. Either you do lots of calculations because it's easier to simply write an infinite loop and sample the temperature as fast as the processor can pass through it, or you save energy by idling. The two strategies are both reasonable, but contradictory. > > Generally, from what I have seen, if you start out by converting > everything to "standard units", generally the program very rapidly loses > sense of what the real accuracy is of the numbers, as you now very much > need to keep track of the accuracy as a companion number through the > whole calculation. When dealing with scaled/fixed point numbers, you are > thinking about how the errors are building at each step, as you are > evaluating what parts of the answers are worth keeping. > > Generally, if you have done it right, the fixed point value is mostly > meaningful, but a floating point value carries no natural indication of > how much error is apt to be in it. > That is a very good point. It's very hard to measure errors rigorously. If we add two numbers, it depends whether we've got random or systematic errors whether the result is more or less accurate than the two considered independently.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-11 15:02 +0200 |
| Message-ID | <mgb5uh$fon$1@dont-email.me> |
| In reply to | #59902 |
On 11/04/15 08:50, Malcolm McLean wrote: > On Saturday, April 11, 2015 at 4:19:08 AM UTC+1, Richard Damon wrote: >> >> Interesting example. From my experience, temperatures are very suitable >> for scaled arithmetic, as generally the ratio between the range of >> values obtainable to the measurement resolution is rarely a large number >> (somewhat related to the fact that getting near the "natural" zero value >> is very unusual). I also find your "minute or so" interval as fairly >> unlikely. Control loops like to be run significantly faster than the >> dynamics of the controlled plant, or you need significantly more >> complicated and carefully configured control methods. A minute is a long >> time to continue heating most things, so a thermal control loop is >> likely to run faster than that. >> > We're heating something with a given thermal capacity, and we have > to maintain its temperature at a given level. So essentially we > set the heater to the right level and keep it there. However the > ambient temperature might change, the performance of our heater > might drift, cold substances might be added or hot substances drawn > off. So we'll need to adjust the heater setting occasionally. > But unless our tolerances are very fine, or the heat capacity very > low, it's unlikely we'll need to change the heater settings more than > once per minute. It takes about two minutes to boil a kettle, > which gives you some idea of the thermal capacity of water. People write embedded control systems to control the temperature of all sorts of things. It might be a large room taking hours to heat - with intricate systems to get an even heat throughout. It might be the tip of a soldering iron, heating in maybe 5 seconds - but having to regulate in wildly varying conditions (such as free in air, or in close thermal contact to a large thermal mass). There are systems for heating microscopic elements with times measured in microseconds, and systems where you can have a control loop that only runs every few days. Sometimes regulation only needs to be accurate within 10's of degrees - sometimes it needs mK accuracy. And sometimes the outside influences (like ambient temperature) are stable, sometimes they are highly variable. Sometimes you are even using the temperature regulation as a way of measuring these outside influences. If you learn nothing else from this thread, then please learn that embedded programming is a field that you know nothing about, and it is a /huge/ field with a vast range of systems and requirements. You cannot simply pick an example of something /you/ think is a "typical embedded system" and generalise wildly from it. Not all temperature systems are kettles!
[toc] | [prev] | [next] | [standalone]
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web