Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #102489 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2017-01-26 12:15 -0800 |
| Last post | 2017-01-28 18:56 +0000 |
| Articles | 20 on this page of 169 — 19 participants |
Back to article view | Back to comp.lang.c
Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-26 12:15 -0800
Re: Passing values from structure arrays to a generic geometrical mean f unction Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-26 21:25 +0000
Re: Passing values from structure arrays to a generic geometrical mean f unction Alla _ <modelling.data@gmail.com> - 2017-01-26 22:48 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-26 22:09 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-27 00:25 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-27 08:35 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-27 01:53 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-27 10:33 +0000
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-27 13:29 +0100
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-27 13:05 +0000
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-27 16:05 +0100
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-27 15:31 +0000
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-27 17:11 +0100
Re: Passing values from structure arrays to a generic geometrical mean function Ian Collins <ian-news@hotmail.com> - 2017-01-28 07:45 +1300
Re: Passing values from structure arrays to a generic geometrical mean function BartC <bc@freeuk.com> - 2017-01-27 15:35 +0000
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-27 17:16 +0100
Re: Passing values from structure arrays to a generic geometrical mean function raltbos@xs4all.nl (Richard Bos) - 2017-01-27 17:13 +0000
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-29 14:26 +0100
Re: Passing values from structure arrays to a generic geometrical mean function BartC <bc@freeuk.com> - 2017-01-29 14:51 +0000
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-29 23:05 +0100
Re: Passing values from structure arrays to a generic geometrical mean function raltbos@xs4all.nl (Richard Bos) - 2017-01-31 11:23 +0000
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-31 13:21 +0100
Re: Passing values from structure arrays to a generic geometrical mean function Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 00:59 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-27 16:57 +0000
Re: Passing values from structure arrays to a generic geometrical mean function raltbos@xs4all.nl (Richard Bos) - 2017-01-27 17:16 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-28 00:41 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-28 05:05 -0800
Re: Passing values from structure arrays to a generic geometrical mean function James Kuyper <jameskuyper@verizon.net> - 2017-01-27 11:29 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-27 09:25 -0800
Re: Passing values from structure arrays to a generic geometrical mean function supercat@casperkitty.com - 2017-01-27 10:00 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-27 11:50 -0800
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-29 14:41 +0100
Re: Passing values from structure arrays to a generic geometrical mean function Manfred <noname@invalid.add> - 2017-01-27 15:36 +0100
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-27 16:22 +0100
Re: Passing values from structure arrays to a generic geometrical mean function Manfred <noname@invalid.add> - 2017-01-27 16:53 +0100
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-27 17:17 +0100
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-27 05:38 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-27 16:44 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-27 16:59 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-27 09:44 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-27 23:42 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-27 21:59 -0800
Re: Passing values from structure arrays to a generic geometrical mean function luser droog <luser.droog@gmail.com> - 2017-01-27 22:23 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-28 11:15 +0000
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-28 09:51 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-28 03:43 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-28 14:49 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-28 10:15 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-28 14:13 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-29 12:55 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 05:11 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-29 14:38 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 09:00 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-29 17:11 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 10:09 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-28 10:45 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-28 10:26 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-28 14:54 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 01:54 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-28 10:38 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-28 14:52 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-28 19:00 -0800
Re: Passing values from structure arrays to a generic geometrical mean function James Kuyper <jameskuyper@verizon.net> - 2017-01-28 22:54 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 01:33 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-29 10:37 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-29 15:57 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 09:19 -0800
Re: Passing values from structure arrays to a generic geometrical mean function fir <profesor.fir@gmail.com> - 2017-01-29 11:49 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 01:40 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-29 10:48 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 09:59 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-29 13:52 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 12:48 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-29 16:27 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-30 04:57 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-30 12:26 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-30 10:04 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-30 10:28 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-30 14:38 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-31 12:45 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-30 10:39 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-30 12:41 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-31 13:02 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-31 13:37 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-02-02 21:36 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-02-03 08:32 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-02-03 10:39 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 19:07 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-02-03 11:40 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-02-03 21:25 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-02-04 09:01 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-02-04 03:13 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-04 11:37 -0500
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-04 11:33 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-02-03 11:02 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-04 11:46 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-30 21:19 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-31 13:10 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-31 21:18 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-31 13:26 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-30 16:29 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-31 13:14 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-31 16:46 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-02-02 21:40 -0800
Re: Passing values from structure arrays to a generic geometrical mean function luser droog <luser.droog@gmail.com> - 2017-01-30 21:26 -0800
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-31 11:15 +0100
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-31 10:35 +0000
Re: Passing values from structure arrays to a generic geometrical mean function mark.bluemel@gmail.com - 2017-01-31 02:59 -0800
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-31 12:20 +0100
Re: Passing values from structure arrays to a generic geometrical mean function raltbos@xs4all.nl (Richard Bos) - 2017-01-31 11:52 +0000
Re: Passing values from structure arrays to a generic geometrical mean function mark.bluemel@gmail.com - 2017-01-31 06:52 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Richard Heathfield <rjh@cpax.org.uk> - 2017-01-31 13:28 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-31 13:20 -0800
Re: Passing values from structure arrays to a generic geometrical mean function BartC <bc@freeuk.com> - 2017-01-31 23:33 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-29 21:55 +0000
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-30 11:48 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-30 09:15 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-30 14:27 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-31 12:41 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-31 16:38 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-30 19:54 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-31 12:51 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-31 16:54 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-30 12:19 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-30 13:54 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-31 12:57 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-31 13:35 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-31 17:01 -0500
Re: Passing values from structure arrays to a generic geometrical mean function raltbos@xs4all.nl (Richard Bos) - 2017-02-06 14:38 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-30 10:09 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-30 10:24 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 01:48 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-29 11:07 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 01:52 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-29 11:25 -0500
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-04 13:26 -0500
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-28 15:08 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 01:20 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-29 11:17 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Barry Schwarz <schwarzb@dqel.com> - 2017-01-29 08:42 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-27 09:58 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-27 22:45 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-28 00:56 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-28 11:46 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-28 05:08 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-28 05:26 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-28 13:01 -0800
Re: Passing values from structure arrays to a generic geometrical mean function supercat@casperkitty.com - 2017-01-30 09:46 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-30 12:45 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-28 15:05 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-28 10:23 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-29 13:06 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 05:17 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-29 14:51 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-29 12:34 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 06:31 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-29 16:03 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-29 10:04 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-30 00:00 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-30 11:06 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-30 00:13 -0800
Re: Passing values from structure arrays to a generic geometrical mean function supercat@casperkitty.com - 2017-01-27 07:39 -0800
Re: Passing values from structure arrays to a generic geometrical mean function David Brown <david.brown@hesbynett.no> - 2017-01-27 17:30 +0100
Re: Passing values from structure arrays to a generic geometrical mean function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-27 16:16 +0000
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-27 11:49 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Alla _ <modelling.data@gmail.com> - 2017-01-28 00:48 -0800
Re: Passing values from structure arrays to a generic geometrical mean function Keith Thompson <kst-u@mib.org> - 2017-01-28 11:02 -0800
Re: Passing values from structure arrays to a generic geometrical mean function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-28 11:09 -0500
Re: Passing values from structure arrays to a generic geometrical mean function Ike Naar <ike@iceland.freeshell.org> - 2017-01-28 18:56 +0000
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-26 12:15 -0800 |
| Subject | Passing values from structure arrays to a generic geometrical mean function |
| Message-ID | <def5356e-59fc-4377-aae2-3abb3cbc7c0f@googlegroups.com> |
Hello!
I have written (have not yet run it by compiler, so it is still
a theoretical, on-paper function) a geomean function. I would
like it to be a generic one, so it could be suitable for other programs
as well. (This function calls another geomean function, which
compute geomean for only two numbers.)
I am not sure I can write such a generic function, given
the specifics of my task. I still hope to find the solution myself,
but, if it is possible to write such a function given my spec, I will
be grateful for a hint from you (not a solution):
double geomean(income_ptr->dip_amor, ba_ptr->gross_ppe, ba_ptr->intang)
{
double multiply = 0.0;
double gm = 0.0;
for (int i = 1; i < DATA_SIZE; i++)
{
multiply *= (1 + (income_ptr[i].dep_amor)/(geomean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe) + geomean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang)) );
}
gm = pow(multiply, (1/DATA_SIZE));
return gm;
}
Thank you!
[toc] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-26 21:25 +0000 |
| Subject | Re: Passing values from structure arrays to a generic geometrical mean f unction |
| Message-ID | <877f5h1pkd.fsf@bsb.me.uk> |
| In reply to | #102489 |
Alla _ <modelling.data@gmail.com> writes:
> I have written (have not yet run it by compiler, so it is still
> a theoretical, on-paper function) a geomean function. I would
> like it to be a generic one, so it could be suitable for other programs
> as well. (This function calls another geomean function, which
> compute geomean for only two numbers.)
> I am not sure I can write such a generic function, given
> the specifics of my task.
This sentence confuses me. A generic geometric mean function is not
hard (provided it need not be super robust in extreme cases) but what
has the specifics of your task got to do with whether you can write one
or not?
A guess: you need a calculation that is a bit like a geometric mean and
you want to know if it can be written using an actual geometric mean
function. If that's not what you mean, I'm lost. (Even if it is I'm
still lost so I'm not sure that helps.)
> I still hope to find the solution myself,
> but, if it is possible to write such a function given my spec, I will
> be grateful for a hint from you (not a solution):
>
> double geomean(income_ptr->dip_amor, ba_ptr->gross_ppe, ba_ptr->intang)
Yes, no compiler has seen this code!
> {
> double multiply = 0.0;
Really? (Also, product is 'probably' a better name -- multiply is a verb.)
> double gm = 0.0;
In other code, you declare variables when they are used.
> for (int i = 1; i < DATA_SIZE; i++)
> {
> multiply *= (1 + (income_ptr[i].dep_amor)/(geomean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe) + geomean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang)) );
You should help the reader with some say layout (and lose the redundant ()s):
multiply *= 1 + income_ptr[i].dep_amor /
(geomean_twonums(ba_ptr[i-1].gross_ppe,
ba_ptr[ i ].gross_ppe) +
geomean_twonums(ba_ptr[i-1].intang,
ba_ptr[ i ].intang));
> }
> gm = pow(multiply, (1/DATA_SIZE));
>
> return gm;
I'll never understand why writing three lines and using an extra name is
better than just
return pow(product, 1.0/DATA_SIZE);
(I've changed three other things as well as making it one line.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-26 22:48 -0800 |
| Subject | Re: Passing values from structure arrays to a generic geometrical mean f unction |
| Message-ID | <4648e497-24a7-42e5-879c-8b8835369e1c@googlegroups.com> |
| In reply to | #102496 |
On Friday, January 27, 2017 at 12:25:45 AM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > I have written (have not yet run it by compiler, so it is still
> > a theoretical, on-paper function) a geomean function. I would
> > like it to be a generic one, so it could be suitable for other programs
> > as well. (This function calls another geomean function, which
> > compute geomean for only two numbers.)
> > I am not sure I can write such a generic function, given
> > the specifics of my task.
>
> This sentence confuses me. A generic geometric mean function is not
> hard (provided it need not be super robust in extreme cases) but what
> has the specifics of your task got to do with whether you can write one
> or not?
>
> A guess: you need a calculation that is a bit like a geometric mean and
> you want to know if it can be written using an actual geometric mean
> function. If that's not what you mean, I'm lost. (Even if it is I'm
> still lost so I'm not sure that helps.)
>
> > I still hope to find the solution myself,
> > but, if it is possible to write such a function given my spec, I will
> > be grateful for a hint from you (not a solution):
> >
> > double geomean(income_ptr->dip_amor, ba_ptr->gross_ppe, ba_ptr->intang)
>
> Yes, no compiler has seen this code!
Yes, of course ) I didn't use a correct set of arguments here (with types)
because this is the part I wanted to make generic, but most likely I have
to first finish writing the function that computes what I need, and only
then try to make it generic. I was referring to those parameters, because
I have difficulty passing structure members as numbers - I can pass one
number, but within the function I have to loop through an array of
structures, which have that same member.
I will be back once the specific one is done, and then it will be more clear
what I am trying to do ) Sorry )
>
> > {
> > double multiply = 0.0;
>
> Really? (Also, product is 'probably' a better name -- multiply is a verb.)
Yes, I know and agree. It's bad to say that but I didn't think about yet
writing a good name; I was merely trying to convey my point. Apologies.
>
> > double gm = 0.0;
>
> In other code, you declare variables when they are used.
>
> > for (int i = 1; i < DATA_SIZE; i++)
> > {
> > multiply *= (1 + (income_ptr[i].dep_amor)/(geomean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe) + geomean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang)) );
>
> You should help the reader with some say layout (and lose the redundant ()s):
>
> multiply *= 1 + income_ptr[i].dep_amor /
> (geomean_twonums(ba_ptr[i-1].gross_ppe,
> ba_ptr[ i ].gross_ppe) +
> geomean_twonums(ba_ptr[i-1].intang,
> ba_ptr[ i ].intang));
>
> > }
> > gm = pow(multiply, (1/DATA_SIZE));
> >
> > return gm;
>
> I'll never understand why writing three lines and using an extra name is
> better than just
Very easy to explain ) I also like to just return the value, but in this particular
case I have a debugging fprintf before return (I didn't show it in this post),
that should check the value of gm. Once I am done with the function, I will
leave only return pow() :)
I see you have deleted external brackets to compute the product
>
> return pow(product, 1.0/DATA_SIZE);
>
> (I've changed three other things as well as making it one line.)
>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-26 22:09 +0000 |
| Message-ID | <o6ds08$hm$1@dont-email.me> |
| In reply to | #102489 |
On 26/01/17 20:15, Alla _ wrote: > Hello! > > I have written (have not yet run it by compiler, so it is still > a theoretical, on-paper function) a geomean function. Obviously it won't compile yet. But when it does, I offer the following prediction: if DATA_SIZE is 1, then the function will return 0, no matter what arguments you supply. If DATA_SIZE is > 1, the function will return 1, no matter what arguments you supply. Hint: look at the definition of 'multiply'. -- 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 | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-27 00:25 -0800 |
| Message-ID | <b56f0bcf-20d1-492d-a627-10e23f62f0bd@googlegroups.com> |
| In reply to | #102501 |
On Friday, January 27, 2017 at 1:09:56 AM UTC+3, Richard Heathfield wrote: > On 26/01/17 20:15, Alla _ wrote: > > Hello! > > > > I have written (have not yet run it by compiler, so it is still > > a theoretical, on-paper function) a geomean function. > > Obviously it won't compile yet. > > But when it does, I offer the following prediction: if DATA_SIZE is 1, > then the function will return 0, no matter what arguments you supply. If > DATA_SIZE is > 1, the function will return 1, no matter what arguments > you supply. > > Hint: look at the definition of 'multiply'. > Yes ) I have forgotten to add a dot ) 1.0/DATA_SIZE
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-27 08:35 +0000 |
| Message-ID | <o6f0kt$113$1@dont-email.me> |
| In reply to | #102513 |
On 27/01/17 08:25, Alla _ wrote: > On Friday, January 27, 2017 at 1:09:56 AM UTC+3, Richard Heathfield wrote: >> I offer the following prediction: if DATA_SIZE is 1, >> then the function will return 0, no matter what arguments you supply. If >> DATA_SIZE is > 1, the function will return 1, no matter what arguments >> you supply. >> >> Hint: look at the definition of 'multiply'. >> > Yes ) I have forgotten to add a dot ) 1.0/DATA_SIZE Now look at the definition of 'multiply'. -- 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 | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-27 01:53 -0800 |
| Message-ID | <8abfc054-e7c3-498c-a7b4-8e7471f57ac6@googlegroups.com> |
| In reply to | #102515 |
On Friday, January 27, 2017 at 11:35:21 AM UTC+3, Richard Heathfield wrote: > On 27/01/17 08:25, Alla _ wrote: > > On Friday, January 27, 2017 at 1:09:56 AM UTC+3, Richard Heathfield wrote: > >> I offer the following prediction: if DATA_SIZE is 1, > >> then the function will return 0, no matter what arguments you supply. If > >> DATA_SIZE is > 1, the function will return 1, no matter what arguments > >> you supply. > >> > >> Hint: look at the definition of 'multiply'. > >> > > Yes ) I have forgotten to add a dot ) 1.0/DATA_SIZE > > Now look at the definition of 'multiply'. Oh, yes yes - that was corrected last night ) I am so much in a habit of setting everything to zeros or NULLs
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-27 10:33 +0000 |
| Message-ID | <o6f7ji$nfl$1@dont-email.me> |
| In reply to | #102518 |
On 27/01/17 09:53, Alla _ wrote: > On Friday, January 27, 2017 at 11:35:21 AM UTC+3, Richard Heathfield wrote: >> On 27/01/17 08:25, Alla _ wrote: >>> On Friday, January 27, 2017 at 1:09:56 AM UTC+3, Richard Heathfield wrote: >>>> I offer the following prediction: if DATA_SIZE is 1, >>>> then the function will return 0, no matter what arguments you supply. If >>>> DATA_SIZE is > 1, the function will return 1, no matter what arguments >>>> you supply. >>>> >>>> Hint: look at the definition of 'multiply'. >>>> >>> Yes ) I have forgotten to add a dot ) 1.0/DATA_SIZE >> >> Now look at the definition of 'multiply'. > Oh, yes yes - that was corrected last night ) I am so much in > a habit of setting everything to zeros or NULLs That's a good habit to get into, but the habit is "make it zero (or NULL) /unless/ there is a better value you can give it". I have fallen into the same trap in the past with dynamic memory resizing: I increased the size by multiplying: size *= 2; but size was initialised to 0 instead of 1. 0 was fine - the code didn't work, but it was easy to find out why. Had it been left uninitialised, I might never have discovered the error. -- 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 | 2017-01-27 13:29 +0100 |
| Message-ID | <o6fecp$ela$1@dont-email.me> |
| In reply to | #102519 |
On 27/01/17 11:33, Richard Heathfield wrote:
> On 27/01/17 09:53, Alla _ wrote:
>> On Friday, January 27, 2017 at 11:35:21 AM UTC+3, Richard Heathfield
>> wrote:
>>> On 27/01/17 08:25, Alla _ wrote:
>>>> On Friday, January 27, 2017 at 1:09:56 AM UTC+3, Richard Heathfield
>>>> wrote:
>>>>> I offer the following prediction: if DATA_SIZE is 1,
>>>>> then the function will return 0, no matter what arguments you
>>>>> supply. If
>>>>> DATA_SIZE is > 1, the function will return 1, no matter what arguments
>>>>> you supply.
>>>>>
>>>>> Hint: look at the definition of 'multiply'.
>>>>>
>>>> Yes ) I have forgotten to add a dot ) 1.0/DATA_SIZE
>>>
>>> Now look at the definition of 'multiply'.
>> Oh, yes yes - that was corrected last night ) I am so much in
>> a habit of setting everything to zeros or NULLs
>
> That's a good habit to get into, but the habit is "make it zero (or
> NULL) /unless/ there is a better value you can give it".
I would disagree. I think it is a much /better/ habit not to define
anything unless you can give it an appropriate value.
Richard, I know you use C90, and I know you have good reasons for doing
so. But while it might be somewhat useful for a learner to be familiar
with the limitations of C90, it makes more sense to learn and make use
of the features of C99.
In this case, of course, "multiply" was defined in the right place, but
the wrong value. However, your advice of "make it zero" is IMHO wrong
in general. In this function there is no good reason to define "gm" at
the start of the function, nor any good reason to initialise it. If you
have no appropriate value to initialise "gm", as is the case here at the
start of the function, then leave it uninitialised. If you accidentally
use it somewhere before initialisation, then your tools (compiler and/or
static error checker and/or smart editor) can spot your mistake - if you
have given it the completely artificial value of 0, your tools cannot
help you.
Even better is simply to define "gm" when you need to use it:
double geomean(income_ptr->dip_amor, ba_ptr->gross_ppe, ba_ptr->intang)
{
double multiply = 0.0;
for (int i = 1; i < DATA_SIZE; i++)
{
multiply *= (1 + (income_ptr[i].dep_amor) /
(geomean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe) +
geomean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang)) );
}
double gm = pow(multiply, (1/DATA_SIZE));
return gm;
}
There "gm" does not even exist before it is needed, and its definition
is clear and easily found at the point of usage.
>
> I have fallen into the same trap in the past with dynamic memory
> resizing: I increased the size by multiplying: size *= 2; but size was
> initialised to 0 instead of 1. 0 was fine - the code didn't work, but it
> was easy to find out why. Had it been left uninitialised, I might never
> have discovered the error.
>
Had you left it uninitialised and used appropriate compiler warnings,
you would /immediately/ have seen your error even before trying to run
the program.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-27 13:05 +0000 |
| Message-ID | <o6fgfq$lor$1@dont-email.me> |
| In reply to | #102520 |
On 27/01/17 12:29, David Brown wrote:
> On 27/01/17 11:33, Richard Heathfield wrote:
>> On 27/01/17 09:53, Alla _ wrote:
>>> On Friday, January 27, 2017 at 11:35:21 AM UTC+3, Richard Heathfield
>>> wrote:
>>>> On 27/01/17 08:25, Alla _ wrote:
>>>>> On Friday, January 27, 2017 at 1:09:56 AM UTC+3, Richard Heathfield
>>>>> wrote:
>>>>>> I offer the following prediction: if DATA_SIZE is 1,
>>>>>> then the function will return 0, no matter what arguments you
>>>>>> supply. If
>>>>>> DATA_SIZE is > 1, the function will return 1, no matter what arguments
>>>>>> you supply.
>>>>>>
>>>>>> Hint: look at the definition of 'multiply'.
>>>>>>
>>>>> Yes ) I have forgotten to add a dot ) 1.0/DATA_SIZE
>>>>
>>>> Now look at the definition of 'multiply'.
>>> Oh, yes yes - that was corrected last night ) I am so much in
>>> a habit of setting everything to zeros or NULLs
>>
>> That's a good habit to get into, but the habit is "make it zero (or
>> NULL) /unless/ there is a better value you can give it".
>
> I would disagree.
I know. :-)
> I think it is a much /better/ habit not to define
> anything unless you can give it an appropriate value.
Yes. I think I'm right in saying that you think that because you like to
rely on the compiler to pick up any reference to an uninitialised
object. Now, it is true that gcc is quite good at this, but some
compilers are easily fooled:
#include <stdio.h>
static int proc(int *v)
{
int rc = 0;
if(v != NULL)
{
if(*v > 42)
{
rc = 1;
}
}
return rc;
}
int main(void)
{
int var;
int rc = proc(&var);
printf("%d, %d\n", rc, var);
return 0;
}
gcc warns on this behaviour (but the warning goes away if *v is given a
value before the test). Unfortunately, not all compilers are so
accommodating.
> Richard, I know you use C90, and I know you have good reasons for doing
> so. But while it might be somewhat useful for a learner to be familiar
> with the limitations of C90, it makes more sense to learn and make use
> of the features of C99.
Well, it's true that I don't know C99 as well as I perhaps should, but
are you claiming that C99 /requires/ a diagnostic message for the above
code?
> In this case, of course, "multiply" was defined in the right place, but
> the wrong value. However, your advice of "make it zero" is IMHO wrong
> in general. In this function there is no good reason to define "gm" at
> the start of the function, nor any good reason to initialise it. If you
> have no appropriate value to initialise "gm", as is the case here at the
> start of the function, then leave it uninitialised. If you accidentally
> use it somewhere before initialisation, then your tools (compiler and/or
> static error checker and/or smart editor) can spot your mistake - if you
> have given it the completely artificial value of 0, your tools cannot
> help you.
Alas, some users do still use compilers that can't help you even if you
don't. I recognise that mine is a minority viewpoint, but I have found
that the guarantee of deterministic behaviour is a useful one that has
saved me much head-scratching.
--
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 | 2017-01-27 16:05 +0100 |
| Message-ID | <o6fngh$fdv$1@dont-email.me> |
| In reply to | #102521 |
On 27/01/17 14:05, Richard Heathfield wrote:
> On 27/01/17 12:29, David Brown wrote:
>> On 27/01/17 11:33, Richard Heathfield wrote:
>>> On 27/01/17 09:53, Alla _ wrote:
>>>> On Friday, January 27, 2017 at 11:35:21 AM UTC+3, Richard Heathfield
>>>> wrote:
>>>>> On 27/01/17 08:25, Alla _ wrote:
>>>>>> On Friday, January 27, 2017 at 1:09:56 AM UTC+3, Richard Heathfield
>>>>>> wrote:
>>>>>>> I offer the following prediction: if DATA_SIZE is 1,
>>>>>>> then the function will return 0, no matter what arguments you
>>>>>>> supply. If
>>>>>>> DATA_SIZE is > 1, the function will return 1, no matter what
>>>>>>> arguments
>>>>>>> you supply.
>>>>>>>
>>>>>>> Hint: look at the definition of 'multiply'.
>>>>>>>
>>>>>> Yes ) I have forgotten to add a dot ) 1.0/DATA_SIZE
>>>>>
>>>>> Now look at the definition of 'multiply'.
>>>> Oh, yes yes - that was corrected last night ) I am so much in
>>>> a habit of setting everything to zeros or NULLs
>>>
>>> That's a good habit to get into, but the habit is "make it zero (or
>>> NULL) /unless/ there is a better value you can give it".
>>
>> I would disagree.
>
> I know. :-)
>
>> I think it is a much /better/ habit not to define
>> anything unless you can give it an appropriate value.
>
> Yes. I think I'm right in saying that you think that because you like to
> rely on the compiler to pick up any reference to an uninitialised
> object.
That is partly the case, although I would not say that I "rely" on the
compiler here. I like to have my tools spot mistakes in my code - but I
prefer not to make the mistakes in the first place!
I also think it is a bad habit to set a variable in some way when that
initialisation does no useful work - indeed, it hinders useful work (I
count "helping catch your errors faster" as useful work here).
If you can justify a nominal initialisation as helping catch bugs, then
that's fine. Perhaps you initialise your variable to 42 so that when
your program outputs 42, you have a good chance of guessing your
mistake. But if it stops your compiler from telling you /exactly/ where
the problem lies, then it is bad. And if you initialise it to 0 as a
habit, it is unlikely to be particularly useful in bug-catching.
I have a background in maths, and in functional programming.
Re-assignment to a variable always looks slightly wrong to me - if x is
0, then why is it now something else? I need a reason to change a
variable's value - and "I wanted to declare the variable in the wrong
place" is not a good reason.
And I work with small systems, where efficiency is often relevant, as is
understanding what the code is actually doing. If I initialise "x = 0"
at the start of a function, then set "x = foo()" further on, then one of
two things happen. Either the compiler is generating pointless code
that wastes time and space by setting x to 0 at the start, or it is
generating code that is clearly out of sync with the source code by
ignoring the "x = 0" initialisation. Both cases are bad. Neither case
is /very/ bad, usually, but premature pessimisations are almost as evil
as premature optimisations.
So in general, such extra initialisations give no benefit, and can be
harmful.
> Now, it is true that gcc is quite good at this, but some
> compilers are easily fooled:
>
> #include <stdio.h>
>
> static int proc(int *v)
> {
> int rc = 0;
> if(v != NULL)
> {
> if(*v > 42)
> {
> rc = 1;
> }
> }
> return rc;
> }
>
> int main(void)
> {
> int var;
> int rc = proc(&var);
> printf("%d, %d\n", rc, var);
> return 0;
> }
>
> gcc warns on this behaviour (but the warning goes away if *v is given a
> value before the test). Unfortunately, not all compilers are so
> accommodating.
You have been reading too many of Supercat's posts. Yes, you can
construct pathological cases where detecting the use of uninitialised
variables is hard for a compiler. Like most types of undefined
behaviour, there are limits to what a compiler can spot - and different
compilers will be better or worse at it. However, initialising "var"
with 0 will not fix the problem with the code, even though it would make
the behaviour defined. The answer is to avoid writing code with
undefined behaviour - /not/ to write code that has defined but
/incorrect/ behaviour.
>
>> Richard, I know you use C90, and I know you have good reasons for doing
>> so. But while it might be somewhat useful for a learner to be familiar
>> with the limitations of C90, it makes more sense to learn and make use
>> of the features of C99.
>
> Well, it's true that I don't know C99 as well as I perhaps should, but
> are you claiming that C99 /requires/ a diagnostic message for the above
> code?
No, I am merely claiming that a C99 version of Alla's code would not
have to define "gm" at the start of the function - with or without an
initialiser. You could (and in my case at least, "would") define "gm"
at its point of first use.
>
>> In this case, of course, "multiply" was defined in the right place, but
>> the wrong value. However, your advice of "make it zero" is IMHO wrong
>> in general. In this function there is no good reason to define "gm" at
>> the start of the function, nor any good reason to initialise it. If you
>> have no appropriate value to initialise "gm", as is the case here at the
>> start of the function, then leave it uninitialised. If you accidentally
>> use it somewhere before initialisation, then your tools (compiler and/or
>> static error checker and/or smart editor) can spot your mistake - if you
>> have given it the completely artificial value of 0, your tools cannot
>> help you.
>
> Alas, some users do still use compilers that can't help you even if you
> don't.
True. But people rarely /have/ to use such compilers. And when they
do, they rarely have to use such compilers alone without other tools.
I think there is something seriously wrong with recommending a technique
on the basis that it is possibly slightly helpful if you are stuck with
old or inferior tools, and unable or unwilling to take advantage of
better tools, or to learn how to use the tools you have.
Some people do have to use compilers that can't do much in the way of
static error checking. Discounting the people who write their own very
limited tools, and those that spend inordinate effort to make sure they
fail to use available good tools, I expect there are very few people in
this group who actually have to use a compiler that cannot spot a simple
case of reading an uninitialised variable. I am one of these people,
though it's been a while since I have had to use a compiler like that.
And I deal with the problem by using additional tools (such as gcc, but
I've also had occasion to try pc-lint) to catch such errors.
Professional programmers have no excuse for not using reasonable static
error checking in their programming - and hobby programmers have no need
to avoid it because their tools will be gcc, clang, MSVC that all have
such support.
In Alla's case, she already uses a good tool (clang) which /will/ spot
the use of uninitialised local variables in pretty much every case where
the structure is clear enough to the programmer to be "good" code.
Unnecessary initialisation is therefore almost always a hinder, not a help.
> I recognise that mine is a minority viewpoint, but I have found
> that the guarantee of deterministic behaviour is a useful one that has
> saved me much head-scratching.
>
Deterministic incorrect behaviour is certainly better than
non-deterministic incorrect behaviour. But it is not nearly as good as
a compile-time warning about the problem.
However, you have to realise that you are in a position here as Alla's
mentor. It is a position you have earned through a great many helpful
and extraordinarily patient posts. When you give the advice "initialise
your variables to 0 or NULL unless there is a better value", Alla (and
maybe others) will accept that as a solid rule. But it is /not/ a solid
rule - it is a habit that /you/ find helpful, and at least some people
disagree with. It is important to make this clear, so that she make
understand the point and make her own decisions, based on what fits the
most important rule for programming.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-27 15:31 +0000 |
| Message-ID | <o6fp0v$l00$1@dont-email.me> |
| In reply to | #102527 |
On 27/01/17 15:05, David Brown wrote:
> On 27/01/17 14:05, Richard Heathfield wrote:
>> On 27/01/17 12:29, David Brown wrote:
>>> On 27/01/17 11:33, Richard Heathfield wrote:
>>>> On 27/01/17 09:53, Alla _ wrote:
>>>>> On Friday, January 27, 2017 at 11:35:21 AM UTC+3, Richard Heathfield
>>>>> wrote:
>>>>>> On 27/01/17 08:25, Alla _ wrote:
>>>>>>> On Friday, January 27, 2017 at 1:09:56 AM UTC+3, Richard Heathfield
>>>>>>> wrote:
>>>>>>>> I offer the following prediction: if DATA_SIZE is 1,
>>>>>>>> then the function will return 0, no matter what arguments you
>>>>>>>> supply. If
>>>>>>>> DATA_SIZE is > 1, the function will return 1, no matter what
>>>>>>>> arguments
>>>>>>>> you supply.
>>>>>>>>
>>>>>>>> Hint: look at the definition of 'multiply'.
>>>>>>>>
>>>>>>> Yes ) I have forgotten to add a dot ) 1.0/DATA_SIZE
>>>>>>
>>>>>> Now look at the definition of 'multiply'.
>>>>> Oh, yes yes - that was corrected last night ) I am so much in
>>>>> a habit of setting everything to zeros or NULLs
>>>>
>>>> That's a good habit to get into, but the habit is "make it zero (or
>>>> NULL) /unless/ there is a better value you can give it".
>>>
>>> I would disagree.
>>
>> I know. :-)
>>
>>> I think it is a much /better/ habit not to define
>>> anything unless you can give it an appropriate value.
>>
>> Yes. I think I'm right in saying that you think that because you like to
>> rely on the compiler to pick up any reference to an uninitialised
>> object.
>
> That is partly the case, although I would not say that I "rely" on the
> compiler here. I like to have my tools spot mistakes in my code - but I
> prefer not to make the mistakes in the first place!
>
> I also think it is a bad habit to set a variable in some way when that
> initialisation does no useful work - indeed, it hinders useful work (I
> count "helping catch your errors faster" as useful work here).
>
> If you can justify a nominal initialisation as helping catch bugs, then
> that's fine. Perhaps you initialise your variable to 42 so that when
> your program outputs 42, you have a good chance of guessing your
> mistake. But if it stops your compiler from telling you /exactly/ where
> the problem lies, then it is bad. And if you initialise it to 0 as a
> habit, it is unlikely to be particularly useful in bug-catching.
>
> I have a background in maths, and in functional programming.
> Re-assignment to a variable always looks slightly wrong to me - if x is
> 0, then why is it now something else? I need a reason to change a
> variable's value - and "I wanted to declare the variable in the wrong
> place" is not a good reason.
>
> And I work with small systems, where efficiency is often relevant, as is
> understanding what the code is actually doing. If I initialise "x = 0"
> at the start of a function, then set "x = foo()" further on, then one of
> two things happen. Either the compiler is generating pointless code
> that wastes time and space by setting x to 0 at the start, or it is
> generating code that is clearly out of sync with the source code by
> ignoring the "x = 0" initialisation. Both cases are bad. Neither case
> is /very/ bad, usually, but premature pessimisations are almost as evil
> as premature optimisations.
>
>
> So in general, such extra initialisations give no benefit, and can be
> harmful.
>
>> Now, it is true that gcc is quite good at this, but some
>> compilers are easily fooled:
>>
>> #include <stdio.h>
>>
>> static int proc(int *v)
>> {
>> int rc = 0;
>> if(v != NULL)
>> {
>> if(*v > 42)
>> {
>> rc = 1;
>> }
>> }
>> return rc;
>> }
>>
>> int main(void)
>> {
>> int var;
>> int rc = proc(&var);
>> printf("%d, %d\n", rc, var);
>> return 0;
>> }
>>
>> gcc warns on this behaviour (but the warning goes away if *v is given a
>> value before the test). Unfortunately, not all compilers are so
>> accommodating.
>
> You have been reading too many of Supercat's posts.
How can none be too many? :-)
> Yes, you can
> construct pathological cases where detecting the use of uninitialised
> variables is hard for a compiler.
Passing an object's address to a function is hardly /that/ pathological.
(In any case, gcc spotted it just fine, which is a point in favour of
your argument. My case is that not all compilers are as clever as gcc.)
> Like most types of undefined
> behaviour, there are limits to what a compiler can spot - and different
> compilers will be better or worse at it. However, initialising "var"
> with 0 will not fix the problem with the code, even though it would make
> the behaviour defined. The answer is to avoid writing code with
> undefined behaviour - /not/ to write code that has defined but
> /incorrect/ behaviour.
Sure. Until such time as I can guarantee to write perfect code, however,
I will continue to do my best to ensure that my mistakes are at least
/deterministic/ mistakes, because I consider them easier to find that way.
I very nearly gave in, right this second, right after writing that
paragraph. I said to myself, "what the heck? David's way obviously works
for David, so why not give it a try - why not drop the initialisations
completely, and see whether David's way works for me, too?" But, alas,
that only works when I'm using a compiler I can trust to be clever. In
any case, it just smells wrong. (How about /that/ for a compelling
technical argument?)
<excellent argument snipped>
You do make out a very good case. That I am not persuaded by it may be
more to do with my innate Luddism than anything else.
> Deterministic incorrect behaviour is certainly better than
> non-deterministic incorrect behaviour. But it is not nearly as good as
> a compile-time warning about the problem.
Provided that that warning is guaranteed, I would agree.
> However, you have to realise that you are in a position here as Alla's
> mentor. It is a position you have earned through a great many helpful
> and extraordinarily patient posts.
Yes, and so I have a responsibility to give /good/ advice (or, on the
occasions when I give bad advice by mistake, to confess it rapidly).
Now, /in my opinion/, and I do recognise that it is a minority opinion,
the advice I give in this regard /is/ good advice. I realise you
disagree, of course. We may trust that Alla will read this discussion
and make up her own mind. Since you make such a persuasive case, you may
well persuade her. Or, of course, you may not. It's up to her.
> When you give the advice "initialise
> your variables to 0 or NULL unless there is a better value", Alla (and
> maybe others) will accept that as a solid rule. But it is /not/ a solid
> rule - it is a habit that /you/ find helpful, and at least some people
> disagree with. It is important to make this clear, so that she make
> understand the point and make her own decisions, based on what fits the
> most important rule for programming.
I do try to remember to point out, when I give that particular piece of
advice, that the majority of expert C programmers disagree with me. (Not
all, if I recall correctly, but certainly the majority.)
And I (try to remember to) do the same whenever I give any other advice
that I know to be against the consensus.
--
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 | 2017-01-27 17:11 +0100 |
| Message-ID | <o6frbo$up2$1@dont-email.me> |
| In reply to | #102533 |
On 27/01/17 16:31, Richard Heathfield wrote:
> On 27/01/17 15:05, David Brown wrote:
>> On 27/01/17 14:05, Richard Heathfield wrote:
>>> On 27/01/17 12:29, David Brown wrote:
>> You have been reading too many of Supercat's posts.
>
> How can none be too many? :-)
>
>> Yes, you can
>> construct pathological cases where detecting the use of uninitialised
>> variables is hard for a compiler.
>
> Passing an object's address to a function is hardly /that/ pathological.
> (In any case, gcc spotted it just fine, which is a point in favour of
> your argument. My case is that not all compilers are as clever as gcc.)
You might have helped the other compilers by appropriate use of "const".
Certainly you are correct that you can write perfectly
reasonable-looking functions and end up with code that accidentally uses
an uninitialised variable, without even the smartest of compilers
spotting it. But my point is that providing an artificial
initialisation here does not make the code any more correct, and is
unlikely to make it easier for you and/or the compiler to spot the error.
>
>> Like most types of undefined
>> behaviour, there are limits to what a compiler can spot - and different
>> compilers will be better or worse at it. However, initialising "var"
>> with 0 will not fix the problem with the code, even though it would make
>> the behaviour defined. The answer is to avoid writing code with
>> undefined behaviour - /not/ to write code that has defined but
>> /incorrect/ behaviour.
>
> Sure. Until such time as I can guarantee to write perfect code, however,
> I will continue to do my best to ensure that my mistakes are at least
> /deterministic/ mistakes, because I consider them easier to find that way.
/Sometimes/ a deterministic mistake is easier to find. But sometimes it
is not. If a function could reasonably return 0, and you have a bug so
that it is failing to put the calculated value into the correct variable
before returning it, how are you to distinguish returning 0 from your
habitual initialisation from returning 0 as the correct result? A
non-deterministic return that varied from run to run despite identical
input data would be easier to spot. A specific sentinel value ("int x =
123456789;") is likely to be easier to spot. At best, however, you are
merely making the bug slightly easier to find in some ways, while
simultaneously making it harder to find in other ways.
>
> I very nearly gave in, right this second, right after writing that
> paragraph. I said to myself, "what the heck? David's way obviously works
> for David, so why not give it a try - why not drop the initialisations
> completely, and see whether David's way works for me, too?" But, alas,
> that only works when I'm using a compiler I can trust to be clever. In
> any case, it just smells wrong. (How about /that/ for a compelling
> technical argument?)
"Smells wrong" is not a bad argument, actually. It is important that a
programmer feels comfortable with his or her code - code that is
different from "typical" code is more likely to have bugs or hidden
problems.
>
> <excellent argument snipped>
>
> You do make out a very good case. That I am not persuaded by it may be
> more to do with my innate Luddism than anything else.
I expect to have to beat you over the head a good many times before
convincing you. My target is to convince of the benefits of C21 by the
time C33 is published...
Seriously, all I recommend is that you think about the idea, and reach
your own conclusions. And if the conclusion is ever "always write it
/this/ way", it is probably wrong.
>
>> Deterministic incorrect behaviour is certainly better than
>> non-deterministic incorrect behaviour. But it is not nearly as good as
>> a compile-time warning about the problem.
>
> Provided that that warning is guaranteed, I would agree.
It is impossible to guarantee warnings on all such bugs - if it were,
where would be the fun in our jobs?
>
>> However, you have to realise that you are in a position here as Alla's
>> mentor. It is a position you have earned through a great many helpful
>> and extraordinarily patient posts.
>
> Yes, and so I have a responsibility to give /good/ advice (or, on the
> occasions when I give bad advice by mistake, to confess it rapidly).
> Now, /in my opinion/, and I do recognise that it is a minority opinion,
> the advice I give in this regard /is/ good advice. I realise you
> disagree, of course. We may trust that Alla will read this discussion
> and make up her own mind. Since you make such a persuasive case, you may
> well persuade her. Or, of course, you may not. It's up to her.
That's absolutely fine. Give the student the information, present the
different cases, and let her learn for herself.
>
>> When you give the advice "initialise
>> your variables to 0 or NULL unless there is a better value", Alla (and
>> maybe others) will accept that as a solid rule. But it is /not/ a solid
>> rule - it is a habit that /you/ find helpful, and at least some people
>> disagree with. It is important to make this clear, so that she make
>> understand the point and make her own decisions, based on what fits the
>> most important rule for programming.
>
> I do try to remember to point out, when I give that particular piece of
> advice, that the majority of expert C programmers disagree with me. (Not
> all, if I recall correctly, but certainly the majority.)
I am not going to try to guess how many people recommend always
initialising their variables at declaration even if they have nothing
"real" to put in them, and how many people recommend never doing so. I
might guess that a fair number would say "it depends on the
circumstances". It may be I that is in the minority here.
I would note, however, that if you have a habit of only declaring your
variables when you actually need them, rather than all in a lump at the
start of the function, then it is actually quite rare that the issue
comes up - you usually do have a sensible initialisation value, or at
least you will have a value quite soon:
int x;
if (flag) {
...
x = foo();
} else {
...
x = bar();
}
>
> And I (try to remember to) do the same whenever I give any other advice
> that I know to be against the consensus.
>
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-28 07:45 +1300 |
| Message-ID | <ef1iqrFjir4U2@mid.individual.net> |
| In reply to | #102533 |
On 01/28/17 04:31 AM, Richard Heathfield wrote: > > Passing an object's address to a function is hardly /that/ pathological. > (In any case, gcc spotted it just fine, which is a point in favour of > your argument. My case is that not all compilers are as clever as gcc.) A counter argument is even if your target uses a poor compiler, you can still compile your code with gcc or use a checker such as lint to take advantage of better warnings. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-27 15:35 +0000 |
| Message-ID | <o6fp90$m1g$1@dont-email.me> |
| In reply to | #102527 |
On 27/01/2017 15:05, David Brown wrote: > I have a background in maths, and in functional programming. > Re-assignment to a variable always looks slightly wrong to me - if x is > 0, then why is it now something else? Yesterday I had £20 in my wallet, and today it's only £10. Yes it would be nice if it was still £20 even after I'd spent half of it, or my current account balance never got less, but that's not how it works. Some things need to be variable. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-27 17:16 +0100 |
| Message-ID | <o6frlj$b8$1@dont-email.me> |
| In reply to | #102534 |
On 27/01/17 16:35, BartC wrote: > On 27/01/2017 15:05, David Brown wrote: > >> I have a background in maths, and in functional programming. >> Re-assignment to a variable always looks slightly wrong to me - if x is >> 0, then why is it now something else? > > Yesterday I had £20 in my wallet, and today it's only £10. Yes it would > be nice if it was still £20 even after I'd spent half of it, or my > current account balance never got less, but that's not how it works. > When I want a glass of milk, I do not initialise the glass to a base "glass of water" before emptying it and filling it with milk. Analogies are not always relevant. > Some things need to be variable. > That's true, at least in procedural programming languages. But it is a lot easier to reason about objects when they are constant. I've forgotten which one, but at least one of the recent crop of trendy languages (Rust, Go, Swift, or something like that) makes all declarations "const" unless you use a "var" qualifier. I think that is a good idea in language design. C looks a bit ugly if you keep putting "const" everywhere, but some people do it for safer coding.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-27 17:13 +0000 |
| Message-ID | <588b7ef4.19483218@news.xs4all.nl> |
| In reply to | #102543 |
David Brown <david.brown@hesbynett.no> wrote: > On 27/01/17 16:35, BartC wrote: > > On 27/01/2017 15:05, David Brown wrote: > > > >> I have a background in maths, and in functional programming. > >> Re-assignment to a variable always looks slightly wrong to me - if x is > >> 0, then why is it now something else? > > > > Yesterday I had £20 in my wallet, and today it's only £10. Yes it would > > be nice if it was still £20 even after I'd spent half of it, or my > > current account balance never got less, but that's not how it works. > > When I want a glass of milk, I do not initialise the glass to a base > "glass of water" before emptying it and filling it with milk. I do. It's called "rinsing". > Analogies are not always relevant. However, this one was. In the real world outside the ivory tower of academe, most things do change. 99% of us do not have tenure, so we have to deal with the fact that our income may be reassigned to. > > Some things need to be variable. > > That's true, at least in procedural programming languages. But it is a > lot easier to reason about objects when they are constant. Functional programming is easier if you're dealing with theory. IMAO, for dealing with the real world, procedural programming is much superior. > I've forgotten which one, but at least one of the recent crop of trendy > languages (Rust, Go, Swift, or something like that) makes all > declarations "const" unless you use a "var" qualifier. I think that is > a good idea in language design. That, however, is a different matter entirely. It doesn't make variables constant, it just makes objects constant unless you declare them variable. You can still do this "wrong" reassigning to any variable. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-29 14:26 +0100 |
| Message-ID | <o6kqfk$ggs$1@dont-email.me> |
| In reply to | #102558 |
On 27/01/17 18:13, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> On 27/01/17 16:35, BartC wrote: >>> On 27/01/2017 15:05, David Brown wrote: >>> >>>> I have a background in maths, and in functional programming. >>>> Re-assignment to a variable always looks slightly wrong to me - if x is >>>> 0, then why is it now something else? >>> >>> Yesterday I had £20 in my wallet, and today it's only £10. Yes it would >>> be nice if it was still £20 even after I'd spent half of it, or my >>> current account balance never got less, but that's not how it works. >> >> When I want a glass of milk, I do not initialise the glass to a base >> "glass of water" before emptying it and filling it with milk. > > I do. It's called "rinsing". As I said, analogies are not always relevant. And any analogy, no matter how good, will lose its point when you stretch things too far. > >> Analogies are not always relevant. > > However, this one was. In the real world outside the ivory tower of > academe, most things do change. 99% of us do not have tenure, so we have > to deal with the fact that our income may be reassigned to. > In program code, some things change - but not most things. If it makes sense for a variable to change, that's fine. For a loop index, it is hard to avoid changes - you would have to use recursion or make some sort of list structure, which would be a silly idea in most code (at least in a language like C). But assigning a value of 0 to x that is never used, and then assigning a different value later on, is a pointless change. >>> Some things need to be variable. >> >> That's true, at least in procedural programming languages. But it is a >> lot easier to reason about objects when they are constant. > > Functional programming is easier if you're dealing with theory. IMAO, > for dealing with the real world, procedural programming is much > superior. Procedural programming is certainly more common - but there is a surprising amount of "real world" programming done in functional programming. My personal preference is to use the programming paradigm that seems to fit best for the tasks in hand, which for me is mostly procedural programming, but to make use of any ideas or inspiration learned from different programming techniques. An idea may come from the functional programming world, or the object oriented world, or whatever other paradigm - but if it helps my procedural programming, I'll use it there. > >> I've forgotten which one, but at least one of the recent crop of trendy >> languages (Rust, Go, Swift, or something like that) makes all >> declarations "const" unless you use a "var" qualifier. I think that is >> a good idea in language design. > > That, however, is a different matter entirely. It doesn't make variables > constant, it just makes objects constant unless you declare them > variable. You can still do this "wrong" reassigning to any variable. > It certainly does not stop you from putting the wrong values into your variables or constants. It merely makes it clearer what objects will change underway, and helps avoid typos or mistakes where you change something that you had not intended to be variable.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-29 14:51 +0000 |
| Message-ID | <o6kvf2$20p$1@dont-email.me> |
| In reply to | #102690 |
On 29/01/2017 13:26, David Brown wrote: > On 27/01/17 18:13, Richard Bos wrote: >> David Brown <david.brown@hesbynett.no> wrote: >> I do. It's called "rinsing". > > As I said, analogies are not always relevant. And any analogy, no > matter how good, will lose its point when you stretch things too far. > >> >>> Analogies are not always relevant. >> >> However, this one was. In the real world outside the ivory tower of >> academe, most things do change. 99% of us do not have tenure, so we have >> to deal with the fact that our income may be reassigned to. >> > > In program code, some things change - but not most things. > > If it makes sense for a variable to change, that's fine. But with a language doesn't have variables, how would you do it? How would you implement a Wallet object where the contents are constantly changing? I didn't understand Ben's example. And using get/set functions are a cheat. > For a loop > index, it is hard to avoid changes - you would have to use recursion or > make some sort of list structure, which would be a silly idea in most > code (at least in a language like C). Actually, here I would agree it would make sense to not allow explicit changes to a loop index; only what is done by the language to implement the loop. But in C, there is no concept of a loop index that it understands, so this is not practical. > But assigning a value of 0 to x that is never used, and then assigning a > different value later on, is a pointless change. I don't agree. Maybe it's something that can be pointed out on finished, stable code. But when code is in development, anything could change at any time between the assignment of zero, and the other assignment. Or that other assignment could disappear, while leaving a reference to it that will now use zero. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-29 23:05 +0100 |
| Message-ID | <o6losq$6kc$1@dont-email.me> |
| In reply to | #102697 |
On 29/01/17 15:51, BartC wrote:
> On 29/01/2017 13:26, David Brown wrote:
>> On 27/01/17 18:13, Richard Bos wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>
>>> I do. It's called "rinsing".
>>
>> As I said, analogies are not always relevant. And any analogy, no
>> matter how good, will lose its point when you stretch things too far.
>>
>>>
>>>> Analogies are not always relevant.
>>>
>>> However, this one was. In the real world outside the ivory tower of
>>> academe, most things do change. 99% of us do not have tenure, so we have
>>> to deal with the fact that our income may be reassigned to.
>>>
>>
>> In program code, some things change - but not most things.
>>
>> If it makes sense for a variable to change, that's fine.
>
> But with a language doesn't have variables, how would you do it?
>
> How would you implement a Wallet object where the contents are
> constantly changing? I didn't understand Ben's example. And using
> get/set functions are a cheat.
You can use recursion or iterate over sequences rather than use
variables. You might have a function written in "normal" C:
int sumSeq(const int bs[], const int n) {
int sum = 0;
for (int i = 0; i < n; i++) {
sum += bs[i];
}
return sum;
}
"i" and "sum" are both variables. "bs" and "n" are constants.
To avoid variables, you could write:
int sumSeq(const int bs[], const int n) {
return n ? bs[0] + sumSeq(bs + 1, n - 1) : 0;
}
The first version is more common in C, and most compilers will do a good
job of optimising it. For the second version, some compilers will turn
it into much the same iterative code as the first ones - others will
generate slow recursive calls.
>
>> For a loop
>> index, it is hard to avoid changes - you would have to use recursion or
>> make some sort of list structure, which would be a silly idea in most
>> code (at least in a language like C).
>
> Actually, here I would agree it would make sense to not allow explicit
> changes to a loop index; only what is done by the language to implement
> the loop.
The C language allows many things that might not be a good idea in
practice. I would be very sceptical about changing a loop variable
inside a loop for a simple "for" loop. But sometimes you have a more
complex loop, and need to change the controlling variables in more
complex ways.
>
> But in C, there is no concept of a loop index that it understands, so
> this is not practical.
>
>> But assigning a value of 0 to x that is never used, and then assigning a
>> different value later on, is a pointless change.
>
> I don't agree. Maybe it's something that can be pointed out on finished,
> stable code. But when code is in development, anything could change at
> any time between the assignment of zero, and the other assignment. Or
> that other assignment could disappear, while leaving a reference to it
> that will now use zero.
>
I was thinking about completed code. Of course code can be a bit "odd",
or break all sorts of style rules, while it is being developed and debugged.
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web