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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-27 09:58 -0800 |
| Message-ID | <3a8dc13f-3e11-4e38-9717-152d7ee7666d@googlegroups.com> |
| In reply to | #102552 |
On Friday, January 27, 2017 at 7:44:33 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > ><snip> > > > > /** Function to fill assumptions: rates > > for depreciation, interest **/ > > void assump_rates_2(income_st *income_ptr, assets *ba_ptr, assumptions *rates) > > Putting aside the parameters, the function name is wrong. There is very > rarely any reason to call a function something_2. If you are doing that > it suggests you are not really sure what the purpose if the function is. > I know the purpose of the function :) I will change the name. Honestly, I also dislike such types of names, and never tend to use them. Especially I could never understand why would someone have an email address, for instance, with name1223@something.com :) As to parameters, I can't put them aside because now I have to repeat at least two of these mean computing functions twice only because I need to pass a different structure member :( Oh, and about offsets - I assume that once all the rest is good, and once I learn that enum topic, I will be able to change the code in relative places. <snip>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-27 22:45 +0000 |
| Message-ID | <8737g4xgtk.fsf@bsb.me.uk> |
| In reply to | #102568 |
Alla _ <modelling.data@gmail.com> writes: <snip> > Oh, and about offsets - I assume that once all the rest is good, > and once I learn that enum topic, I will be able to change the > code in relative places. I don't think so. This code is doing simple arithmetic (it looks more complex than it needs to be but that's not the point -- it's just a calculation). No function that does a simple calculation should ever need offsetof nor use any alternative using enums. The offsetof concept is causing you to mix up the roles of the caller and called function. The called function should not know or care where it's value is going. Most code that does calculations should look like this: array[i].some_member = calculate(some_other_data, data[j].xyz); The called function should not need to know what to put anything. If it absolutely does need to know (and there are cases) the location should be given as a pointer parameter. Unfortunately I'm finding it hard to give alternative advice. The calculations look overly complex and because of the sketching of the parameters I don't know how these functions are supposed to be used. That was the part of the program that was never specified (publicly at least). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-28 00:56 -0800 |
| Message-ID | <d44f70d8-4eae-434b-9101-6a8be105a576@googlegroups.com> |
| In reply to | #102611 |
On Saturday, January 28, 2017 at 1:45:50 AM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> <snip>
> > Oh, and about offsets - I assume that once all the rest is good,
> > and once I learn that enum topic, I will be able to change the
> > code in relative places.
>
> I don't think so. This code is doing simple arithmetic (it looks more
> complex than it needs to be but that's not the point -- it's just a
> calculation). No function that does a simple calculation should ever
> need offsetof nor use any alternative using enums.
>
> The offsetof concept is causing you to mix up the roles of the caller
> and called function. The called function should not know or care where
> it's value is going. Most code that does calculations should look like
> this:
>
> array[i].some_member = calculate(some_other_data, data[j].xyz);
>
> The called function should not need to know what to put anything. If it
> absolutely does need to know (and there are cases) the location should
> be given as a pointer parameter.
>
> Unfortunately I'm finding it hard to give alternative advice. The
> calculations look overly complex and because of the sketching of the
> parameters I don't know how these functions are supposed to be used.
> That was the part of the program that was never specified (publicly at
> least).
I have written few times, in words and with numbers, how these calculations
will be done. I guess, I had to add those here before posting the code.
But, as you correctly say, these calculations are very simple:
given, say, 5 years 2012 2013 2014 2015 2016
product of four elements, each having the structure
1 + value_1 at 2013 from income st-t
________________________________
sum of (mean of value_2 2012 and value 2013
on the balance sheet + mean of value_3 2012
and value 2013)
on the balance sheet
repeated for each year;
rate = product ^(1 / 5)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-28 11:46 +0000 |
| Message-ID | <87y3xvv237.fsf@bsb.me.uk> |
| In reply to | #102623 |
Alla _ <modelling.data@gmail.com> writes:
> On Saturday, January 28, 2017 at 1:45:50 AM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>> <snip>
>> > Oh, and about offsets - I assume that once all the rest is good,
>> > and once I learn that enum topic, I will be able to change the
>> > code in relative places.
>>
>> I don't think so. This code is doing simple arithmetic (it looks more
>> complex than it needs to be but that's not the point -- it's just a
>> calculation). No function that does a simple calculation should ever
>> need offsetof nor use any alternative using enums.
>>
>> The offsetof concept is causing you to mix up the roles of the caller
>> and called function. The called function should not know or care where
>> it's value is going. Most code that does calculations should look like
>> this:
>>
>> array[i].some_member = calculate(some_other_data, data[j].xyz);
>>
>> The called function should not need to know what to put anything. If it
>> absolutely does need to know (and there are cases) the location should
>> be given as a pointer parameter.
>>
>> Unfortunately I'm finding it hard to give alternative advice. The
>> calculations look overly complex and because of the sketching of the
>> parameters I don't know how these functions are supposed to be used.
>> That was the part of the program that was never specified (publicly at
>> least).
> I have written few times, in words and with numbers, how these calculations
> will be done. I guess, I had to add those here before posting the
> code.
The details of the calculation hardly matter at all, what matters is the
data flow in the program -- how the data comes in, how it is stored, how
it is passed about between functions and how the program's ultimate
output gets produced.
A key step in the design is how the data are stored and the key factor
in deciding that is how the data get used. With a program like this,
once you specify it, you will have (almost) designed it because the
structures and flows will be obvious (to an experienced programmer).
> But, as you correctly say, these calculations are very simple:
> given, say, 5 years 2012 2013 2014 2015 2016
> product of four elements, each having the structure
> 1 + value_1 at 2013 from income st-t
> ________________________________
> sum of (mean of value_2 2012 and value 2013
> on the balance sheet + mean of value_3 2012
> and value 2013)
> on the balance sheet
>
> repeated for each year;
> rate = product ^(1 / 5)
It's not easy to implement that from the description because I think
you've assumed I know what st-t and value_2 and so on are. Does this
calculation have a name? I want to look it up.
I *think* the calculation is done on three arrays of numbers. I'd
expect the code to look a bit like this:
double i_need_a_name(int n, double *v1, double *v2, double *v3)
{
double product = 1;
for (int i = 1; i < n; i++)
product *= 1 + v1[i] / (mean(v2[i-1], v2[i]) + mean(v3[i-1], v3[i]));
return pow(product, 1.0/n);
}
Your 'mean' calculation was also very complex. Does it have a name?
I've just written 'mean' here because I don't know that name.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-28 05:08 -0800 |
| Message-ID | <d6588802-7051-4a99-88d0-9ddbde28f7fc@googlegroups.com> |
| In reply to | #102628 |
On Saturday, January 28, 2017 at 2:46:59 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Saturday, January 28, 2017 at 1:45:50 AM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >> <snip>
> >> > Oh, and about offsets - I assume that once all the rest is good,
> >> > and once I learn that enum topic, I will be able to change the
> >> > code in relative places.
> >>
> >> I don't think so. This code is doing simple arithmetic (it looks more
> >> complex than it needs to be but that's not the point -- it's just a
> >> calculation). No function that does a simple calculation should ever
> >> need offsetof nor use any alternative using enums.
> >>
> >> The offsetof concept is causing you to mix up the roles of the caller
> >> and called function. The called function should not know or care where
> >> it's value is going. Most code that does calculations should look like
> >> this:
> >>
> >> array[i].some_member = calculate(some_other_data, data[j].xyz);
> >>
> >> The called function should not need to know what to put anything. If it
> >> absolutely does need to know (and there are cases) the location should
> >> be given as a pointer parameter.
> >>
> >> Unfortunately I'm finding it hard to give alternative advice. The
> >> calculations look overly complex and because of the sketching of the
> >> parameters I don't know how these functions are supposed to be used.
> >> That was the part of the program that was never specified (publicly at
> >> least).
> > I have written few times, in words and with numbers, how these calculations
> > will be done. I guess, I had to add those here before posting the
> > code.
>
> The details of the calculation hardly matter at all, what matters is the
> data flow in the program -- how the data comes in, how it is stored, how
> it is passed about between functions and how the program's ultimate
> output gets produced.
>
> A key step in the design is how the data are stored and the key factor
> in deciding that is how the data get used. With a program like this,
> once you specify it, you will have (almost) designed it because the
> structures and flows will be obvious (to an experienced programmer).
>
> > But, as you correctly say, these calculations are very simple:
> > given, say, 5 years 2012 2013 2014 2015 2016
> > product of four elements, each having the structure
> > 1 + value_1 at 2013 from income st-t
> > ________________________________
> > sum of (mean of value_2 2012 and value 2013
> > on the balance sheet + mean of value_3 2012
> > and value 2013)
> > on the balance sheet
> >
> > repeated for each year;
> > rate = product ^(1 / 5)
>
> It's not easy to implement that from the description because I think
> you've assumed I know what st-t and value_2 and so on are. Does this
> calculation have a name? I want to look it up.
>
> I *think* the calculation is done on three arrays of numbers. I'd
> expect the code to look a bit like this:
>
> double i_need_a_name(int n, double *v1, double *v2, double *v3)
> {
> double product = 1;
> for (int i = 1; i < n; i++)
> product *= 1 + v1[i] / (mean(v2[i-1], v2[i]) + mean(v3[i-1], v3[i]));
> return pow(product, 1.0/n);
> }
It would truly great if this worked. This is what I am looking for -
defining a function with clear generic parameters, and then passing
certain values to it by the calling routine. But I don't know how to
pass parameters to it, and as Keith has confirmed there is not
neat way of doing it.
Based on your example what should I pass to a function?
Shall the call look like this:
double gr_dep = mean(&income_ptr->dep_amor, &bs_ptr->gross_ppe, &bs_ptr->intang);
?
But this won't work apparently because the mean function will
loop through the same structure changing members, but not
through an array of structures always calling the same member
in each of those structures, hence it is a vertical loop, not a
horizontal one.
v2[i-1], for example if i = 1, will be gross ppe, and v2[i] will
be the next member of the same structure, so it will be acc_dep
typedef struct balance_sheet {
double cash;
double ar;
double inv;
double o_cur_a;
double t_cur_a;
double gross_ppe;
double acc_dep;
double net_ppe;
double intang;
double ta;
double ap;
double tp;
double o_cur_l;
double t_cur_l;
double ltd;
double o_l;
double tl;
double se;
double tle;
} balance;
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-28 05:26 -0800 |
| Message-ID | <5abf342b-6381-4b6e-b77d-2ffb3cc31666@googlegroups.com> |
| In reply to | #102631 |
On Saturday, January 28, 2017 at 1:08:38 PM UTC, Alla _ wrote:
> On Saturday, January 28, 2017 at 2:46:59 PM UTC+3, Ben Bacarisse wrote:
>
> It would truly great if this worked. This is what I am looking for -
> defining a function with clear generic parameters, and then passing
> certain values to it by the calling routine. But I don't know how to
> pass parameters to it, and as Keith has confirmed there is not
> neat way of doing it.
> Based on your example what should I pass to a function?
> Shall the call look like this:
> double gr_dep = mean(&income_ptr->dep_amor, &bs_ptr->gross_ppe, &bs_ptr->intang);
> ?
> But this won't work apparently because the mean function will
> loop through the same structure changing members, but not
> through an array of structures always calling the same member
> in each of those structures, hence it is a vertical loop, not a
> horizontal one.
> v2[i-1], for example if i = 1, will be gross ppe, and v2[i] will
> be the next member of the same structure, so it will be acc_dep
>
> typedef struct balance_sheet {
> double cash;
> double ar;
> double inv;
> double o_cur_a;
> double t_cur_a;
> double gross_ppe;
> double acc_dep;
> double net_ppe;
> double intang;
> double ta;
> double ap;
> double tp;
> double o_cur_l;
> double t_cur_l;
> double ltd;
> double o_l;
> double tl;
> double se;
> double tle;
> } balance;
>
You need to think it terms of bit-based programming. Bit-based programming
says the data is bits, the high-level concepts languages sometimes build
over the bits a superstructure we can ignore without doing any damage,
as long as we are aware what the bits are and what they mean.
In your case, the bits are doubles in the machine native format (probably
64 bit IEEE). You've got a structure with about a dozen (my count is 19)
of them, and, fortunately, no other data types. If we declare an
array we have N blocks of 19 doubles
{19 doubles}{19 doubles} .... {19 doubles}
Do not get confused between buffers and arrays. Arrays have data in them,
the array is your data. The buffer is just memory where you can put
data if you have it.
Now, assuming we want the geometrical mean of cash, cash is always
the first member of the group. So take the first 8 bytes, treat as a
double, skip 18 doubles (18 * 8 bytes), get the next one, and so on,
up to N. If we want the geometrical mean of ar, same drill, except
it is always the second member of the group. So we can skip 8 bytes,
take 8 bytes, then skip (18 * 8) bytes as before. Or we can take
ther start or the array, skip 8 bytes, take the double go back to the
start, skip (19 *8 bytes), or the entire structure, skip 8 bytes,
take the double, and so on. It doesn't really matter, but method two
is often a bit easier.
offsetof simply tells you how many bytes to skip.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-28 13:01 -0800 |
| Message-ID | <lnr33mc30v.fsf@kst-u.example.com> |
| In reply to | #102633 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> You need to think it terms of bit-based programming. Bit-based programming
> says the data is bits, the high-level concepts languages sometimes build
> over the bits a superstructure we can ignore without doing any damage,
> as long as we are aware what the bits are and what they mean.
>
> In your case, the bits are doubles in the machine native format (probably
> 64 bit IEEE). You've got a structure with about a dozen (my count is 19)
> of them, and, fortunately, no other data types. If we declare an
> array we have N blocks of 19 doubles
>
> {19 doubles}{19 doubles} .... {19 doubles}
You're dealing with objects (variables, struct members, array
elements) and their values. Bitwise representation is just a
low-level mechanism for implementing those values. The compiler
takes care of the bitwise representation for you, precisely so you
don't have to think about it.
> Do not get confused between buffers and arrays. Arrays have data in them,
> the array is your data. The buffer is just memory where you can put
> data if you have it.
More nonsense. Alla, Malcolm has his own personal definition
of the word "array" that contradicts its actual meaning in C.
I strongly suggest you ignore it.
If you want to think about the terminology, it's best to think of
"array" as an adjective, not as a noun. (The same applies to
"pointer".) If you talk about "arrays", you risk ambiguity.
Instead, we have array types, array objects, array values, and
array expressions. A "buffer" is just a term for an object (almost
certainly an array object) used to hold values.
What Malcolm calls a "buffer" is an array object, or equivalently
an object of array type. At a given moment, some elements might
have meaningful values and others might not; you need to keep track
of that. Malcolm nonsensically denies that such an array object
is "an array", and insists on using the word "array" to apply only
to the meaningful contents of an array object (if I understand his
usage correctly).
(An "array value" is the value of an array object, consisting of the
values of the elements of the array object. C doesn't provide
many operations on array values, so the concept of an "array value"
isn't often used.)
> Now, assuming we want the geometrical mean of cash, cash is always
> the first member of the group. So take the first 8 bytes, treat as a
> double, skip 18 doubles (18 * 8 bytes), get the next one, and so on,
> up to N. If we want the geometrical mean of ar, same drill, except
> it is always the second member of the group. So we can skip 8 bytes,
> take 8 bytes, then skip (18 * 8) bytes as before. Or we can take
> ther start or the array, skip 8 bytes, take the double go back to the
> start, skip (19 *8 bytes), or the entire structure, skip 8 bytes,
> take the double, and so on. It doesn't really matter, but method two
> is often a bit easier.
>
> offsetof simply tells you how many bytes to skip.
If your data structures are well designed to enable what you want to do
with them, you won't have to think about bits and offsets; you'll just
refer to elements and members of your data structures, by index or by
name. There are some cases where offsetof() can be useful, but I don't
believe the problem you're working on (which I admittedly haven't taken
the time to understand) is one of them.
I suspect, Alla, that by using offsetof() you may have programmed
yourself into a hole. It may be that continuing to dig is still the
best option, but I don't think you'll be satisfied with the result.
But take that with a grain of salt, since I haven't paid very close
attention to the details of what you're doing.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-30 09:46 -0800 |
| Message-ID | <bb72b246-b6ac-42a0-af97-a7549690c5aa@googlegroups.com> |
| In reply to | #102633 |
On Saturday, January 28, 2017 at 7:26:42 AM UTC-6, Malcolm McLean wrote: > You need to think it terms of bit-based programming. Bit-based programming > says the data is bits, the high-level concepts languages sometimes build > over the bits a superstructure we can ignore without doing any damage, > as long as we are aware what the bits are and what they mean. Such a notion is apt to be viewed as heresy by some people. Although nearly all compilers generally followed such an execution model in the days prior to the Standard, the Standard allows compilers to deviate from such a model in the name of "optimization". Since the easiest optimizations also represent the smallest deviation from the model, this didn't cause too much trouble until compilers started getting more sophisticated and also more aggressive. Consequently, it's important to distinguish whether one is coding in ISO C, or K&R2 C with ISO features added as extensions. I happen to like the latter as a language, though I do wish it had a more concise name.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-30 12:45 -0800 |
| Message-ID | <lnfuk09t0q.fsf@kst-u.example.com> |
| In reply to | #102766 |
supercat@casperkitty.com writes:
[...]
> Consequently, it's important to distinguish whether one is coding in ISO C,
> or K&R2 C with ISO features added as extensions. I happen to like the
> latter as a language, though I do wish it had a more concise name.
K&R2 is intended to describe the C language as defined by the 1989 ANSI
C standard, equivalent to the 1990 ISO C standard (it says so right on
the cover, at least for the edition I have).
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-28 15:05 +0000 |
| Message-ID | <87k29fuswj.fsf@bsb.me.uk> |
| In reply to | #102631 |
Alla _ <modelling.data@gmail.com> writes:
> On Saturday, January 28, 2017 at 2:46:59 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
<snip>
>> > But, as you correctly say, these calculations are very simple:
>> > given, say, 5 years 2012 2013 2014 2015 2016
>> > product of four elements, each having the structure
>> > 1 + value_1 at 2013 from income st-t
>> > ________________________________
>> > sum of (mean of value_2 2012 and value 2013
>> > on the balance sheet + mean of value_3 2012
>> > and value 2013)
>> > on the balance sheet
>> >
>> > repeated for each year;
>> > rate = product ^(1 / 5)
>>
>> It's not easy to implement that from the description because I think
>> you've assumed I know what st-t and value_2 and so on are. Does this
>> calculation have a name? I want to look it up.
>>
>> I *think* the calculation is done on three arrays of numbers. I'd
>> expect the code to look a bit like this:
>>
>> double i_need_a_name(int n, double *v1, double *v2, double *v3)
>> {
>> double product = 1;
>> for (int i = 1; i < n; i++)
>> product *= 1 + v1[i] / (mean(v2[i-1], v2[i]) + mean(v3[i-1], v3[i]));
>> return pow(product, 1.0/n);
>> }
> It would truly great if this worked. This is what I am looking for -
> defining a function with clear generic parameters, and then passing
> certain values to it by the calling routine. But I don't know how to
> pass parameters to it, and as Keith has confirmed there is not
> neat way of doing it.
That suggests that the problem is elsewhere. This is why I originally
cried off from advising you. Without a specification of the
calculations up front I could not advise you on how best to structure
the data. Can you arrange for the data you need to be in three arrays?
> Based on your example what should I pass to a function?
> Shall the call look like this:
> double gr_dep = mean(&income_ptr->dep_amor, &bs_ptr->gross_ppe, &bs_ptr->intang);
> ?
> But this won't work apparently because the mean function will
> loop through the same structure changing members, but not
> through an array of structures always calling the same member
> in each of those structures, hence it is a vertical loop, not a
> horizontal one.
> v2[i-1], for example if i = 1, will be gross ppe, and v2[i] will
> be the next member of the same structure, so it will be acc_dep
No it won't. Structures don't work like arrays.
> typedef struct balance_sheet {
> double cash;
> double ar;
> double inv;
> double o_cur_a;
> double t_cur_a;
> double gross_ppe;
> double acc_dep;
> double net_ppe;
> double intang;
> double ta;
> double ap;
> double tp;
> double o_cur_l;
> double t_cur_l;
> double ltd;
> double o_l;
> double tl;
> double se;
> double tle;
> } balance;
I think the basic problem has been found. You have an array of structs
where you need a struct of arrays. This:
struct s1 {
double something;
double another;
double whatever;
};
struct s1 data[YEARS];
is an array of structs and you can't easily manipulate all of the
"something" data as an array.
But with a struct of arrays, you can:
struct s2 {
double something[YEARS];
double another[YEARS];
double whatever[YEARS];
};
struct s2 data;
You can now pass data.something and data.another to functions that need
an array of doubles. Can you have the data in this format?
There are, of course, other alternatives too (including using offsetof!)
but let's consider the simplest ones first.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-28 10:23 -0800 |
| Message-ID | <d76836b5-43ae-43d7-8429-c2222bf6a4bc@googlegroups.com> |
| In reply to | #102638 |
On Saturday, January 28, 2017 at 6:05:22 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Saturday, January 28, 2017 at 2:46:59 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> <snip>
> >> > But, as you correctly say, these calculations are very simple:
> >> > given, say, 5 years 2012 2013 2014 2015 2016
> >> > product of four elements, each having the structure
> >> > 1 + value_1 at 2013 from income st-t
> >> > ________________________________
> >> > sum of (mean of value_2 2012 and value 2013
> >> > on the balance sheet + mean of value_3 2012
> >> > and value 2013)
> >> > on the balance sheet
> >> >
> >> > repeated for each year;
> >> > rate = product ^(1 / 5)
> >>
> >> It's not easy to implement that from the description because I think
> >> you've assumed I know what st-t and value_2 and so on are. Does this
> >> calculation have a name? I want to look it up.
> >>
> >> I *think* the calculation is done on three arrays of numbers. I'd
> >> expect the code to look a bit like this:
> >>
> >> double i_need_a_name(int n, double *v1, double *v2, double *v3)
> >> {
> >> double product = 1;
> >> for (int i = 1; i < n; i++)
> >> product *= 1 + v1[i] / (mean(v2[i-1], v2[i]) + mean(v3[i-1], v3[i]));
> >> return pow(product, 1.0/n);
> >> }
> > It would truly great if this worked. This is what I am looking for -
> > defining a function with clear generic parameters, and then passing
> > certain values to it by the calling routine. But I don't know how to
> > pass parameters to it, and as Keith has confirmed there is not
> > neat way of doing it.
>
> That suggests that the problem is elsewhere. This is why I originally
> cried off from advising you. Without a specification of the
> calculations up front I could not advise you on how best to structure
> the data. Can you arrange for the data you need to be in three arrays?
>
> > Based on your example what should I pass to a function?
> > Shall the call look like this:
> > double gr_dep = mean(&income_ptr->dep_amor, &bs_ptr->gross_ppe, &bs_ptr->intang);
> > ?
> > But this won't work apparently because the mean function will
> > loop through the same structure changing members, but not
> > through an array of structures always calling the same member
> > in each of those structures, hence it is a vertical loop, not a
> > horizontal one.
> > v2[i-1], for example if i = 1, will be gross ppe, and v2[i] will
> > be the next member of the same structure, so it will be acc_dep
>
> No it won't. Structures don't work like arrays.
>
> > typedef struct balance_sheet {
> > double cash;
> > double ar;
> > double inv;
> > double o_cur_a;
> > double t_cur_a;
> > double gross_ppe;
> > double acc_dep;
> > double net_ppe;
> > double intang;
> > double ta;
> > double ap;
> > double tp;
> > double o_cur_l;
> > double t_cur_l;
> > double ltd;
> > double o_l;
> > double tl;
> > double se;
> > double tle;
> > } balance;
>
> I think the basic problem has been found. You have an array of structs
> where you need a struct of arrays. This:
>
> struct s1 {
> double something;
> double another;
> double whatever;
> };
>
> struct s1 data[YEARS];
>
> is an array of structs and you can't easily manipulate all of the
> "something" data as an array.
>
> But with a struct of arrays, you can:
>
> struct s2 {
> double something[YEARS];
> double another[YEARS];
> double whatever[YEARS];
> };
>
> struct s2 data;
>
> You can now pass data.something and data.another to functions that need
> an array of doubles. Can you have the data in this format?
>
Honestly? No ))) We have discussed this format more than two weeks
ago, and Richard has suggested that the version with arrays inside one
struct is a horrible code, because it did look horrendous given
the amount of members I have.
> There are, of course, other alternatives too (including using offsetof!)
> but let's consider the simplest ones first.
>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-29 13:06 +0000 |
| Message-ID | <87r33mrp6r.fsf@bsb.me.uk> |
| In reply to | #102648 |
Alla _ <modelling.data@gmail.com> writes:
> On Saturday, January 28, 2017 at 6:05:22 PM UTC+3, Ben Bacarisse wrote:
<snip>
>> I think the basic problem has been found. You have an array of structs
>> where you need a struct of arrays. This:
>>
>> struct s1 {
>> double something;
>> double another;
>> double whatever;
>> };
>>
>> struct s1 data[YEARS];
>>
>> is an array of structs and you can't easily manipulate all of the
>> "something" data as an array.
>>
>> But with a struct of arrays, you can:
>>
>> struct s2 {
>> double something[YEARS];
>> double another[YEARS];
>> double whatever[YEARS];
>> };
>>
>> struct s2 data;
>>
>> You can now pass data.something and data.another to functions that need
>> an array of doubles. Can you have the data in this format?
>>
> Honestly? No )))
OK. You will probably not be able to write generic calculation
functions without passing in offsets, but it may also be the case that
the calculations are all so specific that there would be not be much
duplication between them anyway. It's not clear at the moment which is
best.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 05:17 -0800 |
| Message-ID | <c21da0a9-cf66-42f0-904d-a07edb97e6bb@googlegroups.com> |
| In reply to | #102685 |
On Sunday, January 29, 2017 at 4:06:11 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Saturday, January 28, 2017 at 6:05:22 PM UTC+3, Ben Bacarisse wrote:
> <snip>
> >> I think the basic problem has been found. You have an array of structs
> >> where you need a struct of arrays. This:
> >>
> >> struct s1 {
> >> double something;
> >> double another;
> >> double whatever;
> >> };
> >>
> >> struct s1 data[YEARS];
> >>
> >> is an array of structs and you can't easily manipulate all of the
> >> "something" data as an array.
> >>
> >> But with a struct of arrays, you can:
> >>
> >> struct s2 {
> >> double something[YEARS];
> >> double another[YEARS];
> >> double whatever[YEARS];
> >> };
> >>
> >> struct s2 data;
> >>
> >> You can now pass data.something and data.another to functions that need
> >> an array of doubles. Can you have the data in this format?
> >>
> > Honestly? No )))
>
> OK. You will probably not be able to write generic calculation
> functions without passing in offsets, but it may also be the case that
> the calculations are all so specific that there would be not be much
> duplication between them anyway. It's not clear at the moment which is
> best.
But once I manage to understand how to use enum, will I be able to use
given my set of structures, i.e. the format I have? Is that method applicable
in this case?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-29 14:51 +0000 |
| Message-ID | <87a8a9sywa.fsf@bsb.me.uk> |
| In reply to | #102688 |
Alla _ <modelling.data@gmail.com> writes:
> On Sunday, January 29, 2017 at 4:06:11 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Saturday, January 28, 2017 at 6:05:22 PM UTC+3, Ben Bacarisse wrote:
>> <snip>
>> >> I think the basic problem has been found. You have an array of structs
>> >> where you need a struct of arrays. This:
>> >>
>> >> struct s1 {
>> >> double something;
>> >> double another;
>> >> double whatever;
>> >> };
>> >>
>> >> struct s1 data[YEARS];
>> >>
>> >> is an array of structs and you can't easily manipulate all of the
>> >> "something" data as an array.
>> >>
>> >> But with a struct of arrays, you can:
>> >>
>> >> struct s2 {
>> >> double something[YEARS];
>> >> double another[YEARS];
>> >> double whatever[YEARS];
>> >> };
>> >>
>> >> struct s2 data;
>> >>
>> >> You can now pass data.something and data.another to functions that need
>> >> an array of doubles. Can you have the data in this format?
>> >>
>> > Honestly? No )))
>>
>> OK. You will probably not be able to write generic calculation
>> functions without passing in offsets, but it may also be the case that
>> the calculations are all so specific that there would be not be much
>> duplication between them anyway. It's not clear at the moment which is
>> best.
> But once I manage to understand how to use enum, will I be able to use
> given my set of structures, i.e. the format I have? Is that method applicable
> in this case?
Yes, but you seem to think enums are something special. I used then
simply to name some integers. You probably do
#define DATA_SIZE 5
but you could also do
enum { DATA_SIZE = 5 };
Both are just ways to name a value (though they are very different in
the details -- enums can name only integer values for example).
To continue the example above (deliberately not using an snum), you
would have
#define something 0
#define another 1
#define whatever 2
struct s1 {
double[whatever + 1];
};
struct years[DATA_SIZE];
and a function that had to operate on 'another' would pass a pointer
and the index 1 (named, of course, 'another').
inc_member(years, 3, another);
In effect you have a 2D array and you can even dispense with struct s1
though I would not advice it here because you have several different
structures.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-29 12:34 -0800 |
| Message-ID | <lninoxbo6f.fsf@kst-u.example.com> |
| In reply to | #102696 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> Yes, but you seem to think enums are something special. I used then
> simply to name some integers. You probably do
>
> #define DATA_SIZE 5
>
> but you could also do
>
> enum { DATA_SIZE = 5 };
>
> Both are just ways to name a value (though they are very different in
> the details -- enums can name only integer values for example).
More precisely, enums can only name values of type int.
[...]
--
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 | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 06:31 -0800 |
| Message-ID | <b262f4f8-4a6f-4b7b-9955-6f46f628e0ad@googlegroups.com> |
| In reply to | #102685 |
On Sunday, January 29, 2017 at 4:06:11 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
<snip>
I am truly sorry for asking it here, not in a new thread, but as we have
lightly touched upon it, I decided to ask a very brief question. I am
trying to find a good way to make the function, which computes rates and
puts them into the assumptions structure, to return something, to avoid
making it 'void', but I for now I have not yet found any plausible
alternative; even boolean returns don't make any sense.
What possible return values exist for functions that resemble the one
below?
/** Function to set assumptions: rates
for pro forma income statement items,
except depreciation & interest **/
void income_rates(cs_income_st *cs_income_ptr, assumptions *rates,\
size_t line_num, double member_product)
{
double rate = pow(member_product, 1.0/DATA_SIZE) - 1;
switch(line_num)
{
case 1:
rates->gr_sales = pow((cs_income_ptr[DATA_SIZE-1].cs_sales\
/cs_income_ptr[0].cs_sales),\
(1.0/DATA_SIZE))-1;
break;
case 2:
rates->av_cogs = rate;
break;
case 3:
rates->av_gross_profit = rate;
break;
case 4:
rates->av_sga = rate;
break;
case 5:
rates->av_oper_inc = rate;
break;
case 7:
rates->av_oper_prof = rate;
break;
case 9:
rates->av_gain_loss = rate;
break;
case 10:
rates->av_pretax_inc = rate;
break;
case 11:
rates->av_tax_exp = STAT_TAX;
break;
case 12:
rates->av_net_inc = rate;
break;
default:
break;
}
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-29 16:03 +0000 |
| Message-ID | <87r33lrgys.fsf@bsb.me.uk> |
| In reply to | #102694 |
Alla _ <modelling.data@gmail.com> writes:
> On Sunday, January 29, 2017 at 4:06:11 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
> <snip>
> I am truly sorry for asking it here, not in a new thread, but as we have
> lightly touched upon it, I decided to ask a very brief question. I am
> trying to find a good way to make the function, which computes rates and
> puts them into the assumptions structure, to return something, to avoid
> making it 'void', but I for now I have not yet found any plausible
> alternative; even boolean returns don't make any sense.
> What possible return values exist for functions that resemble the one
> below?
> /** Function to set assumptions: rates
> for pro forma income statement items,
> except depreciation & interest **/
> void income_rates(cs_income_st *cs_income_ptr, assumptions *rates,\
> size_t line_num, double member_product)
> {
> double rate = pow(member_product, 1.0/DATA_SIZE) - 1;
> switch(line_num)
> {
> case 1:>
> rates->gr_sales = pow((cs_income_ptr[DATA_SIZE-1].cs_sales\
> /cs_income_ptr[0].cs_sales),\
You don't need the \s there (and above).
> (1.0/DATA_SIZE))-1;
> break;
> case 2:
> rates->av_cogs = rate;
> break;
> case 3:
> rates->av_gross_profit = rate;
> break;
> case 4:
> rates->av_sga = rate;
> break;
> case 5:
> rates->av_oper_inc = rate;
> break;
> case 7:
> rates->av_oper_prof = rate;
> break;
> case 9:
> rates->av_gain_loss = rate;
> break;
> case 10:
> rates->av_pretax_inc = rate;
> break;
> case 11:
> rates->av_tax_exp = STAT_TAX;
> break;
> case 12:
> rates->av_net_inc = rate;
> break;
> default:
> break;
> }
> }
I don't see a need for this to driven by line_num. Can't you just
write:
rates->gr_sales = pow((cs_income_ptr[DATA_SIZE-1].cs_sales
/cs_income_ptr[0].cs_sales),
(1.0/DATA_SIZE))-1;
rates->av_cogs = rate;
rates->av_gross_profit = rate;
rates->av_sga = rate;
rates->av_oper_inc = rate;
rates->av_oper_prof = rate;
rates->av_gain_loss = rate;
rates->av_pretax_inc = rate;
rates->av_tax_exp = STAT_TAX;
rates->av_net_inc = rate;
once you have all the data available?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 10:04 -0800 |
| Message-ID | <dbbf8565-c4bd-4047-8f6e-eaff562a2b18@googlegroups.com> |
| In reply to | #102701 |
On Sunday, January 29, 2017 at 7:03:45 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Sunday, January 29, 2017 at 4:06:11 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> > <snip>
> > I am truly sorry for asking it here, not in a new thread, but as we have
> > lightly touched upon it, I decided to ask a very brief question. I am
> > trying to find a good way to make the function, which computes rates and
> > puts them into the assumptions structure, to return something, to avoid
> > making it 'void', but I for now I have not yet found any plausible
> > alternative; even boolean returns don't make any sense.
> > What possible return values exist for functions that resemble the one
> > below?
> > /** Function to set assumptions: rates
> > for pro forma income statement items,
> > except depreciation & interest **/
> > void income_rates(cs_income_st *cs_income_ptr, assumptions *rates,\
> > size_t line_num, double member_product)
> > {
> > double rate = pow(member_product, 1.0/DATA_SIZE) - 1;
> > switch(line_num)
> > {
> > case 1:>
> > rates->gr_sales = pow((cs_income_ptr[DATA_SIZE-1].cs_sales\
> > /cs_income_ptr[0].cs_sales),\
>
> You don't need the \s there (and above).
>
> > (1.0/DATA_SIZE))-1;
> > break;
> > case 2:
> > rates->av_cogs = rate;
> > break;
> > case 3:
> > rates->av_gross_profit = rate;
> > break;
> > case 4:
> > rates->av_sga = rate;
> > break;
> > case 5:
> > rates->av_oper_inc = rate;
> > break;
> > case 7:
> > rates->av_oper_prof = rate;
> > break;
> > case 9:
> > rates->av_gain_loss = rate;
> > break;
> > case 10:
> > rates->av_pretax_inc = rate;
> > break;
> > case 11:
> > rates->av_tax_exp = STAT_TAX;
> > break;
> > case 12:
> > rates->av_net_inc = rate;
> > break;
> > default:
> > break;
> > }
> > }
>
> I don't see a need for this to driven by line_num. Can't you just
> write:
>
> rates->gr_sales = pow((cs_income_ptr[DATA_SIZE-1].cs_sales
> /cs_income_ptr[0].cs_sales),
> (1.0/DATA_SIZE))-1;
> rates->av_cogs = rate;
> rates->av_gross_profit = rate;
> rates->av_sga = rate;
> rates->av_oper_inc = rate;
> rates->av_oper_prof = rate;
> rates->av_gain_loss = rate;
> rates->av_pretax_inc = rate;
> rates->av_tax_exp = STAT_TAX;
> rates->av_net_inc = rate;
>
> once you have all the data available?
Oh, I can! )))) Indeed. Thank you so much.
I couldn't previously because this function
also depended on offsets, but now I have
removed those, and I am totally free to call
when all lines are read and data is stored )
>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-30 00:00 -0800 |
| Message-ID | <0d49714e-71ee-4a77-a761-ca114bb435c7@googlegroups.com> |
| In reply to | #102701 |
On Sunday, January 29, 2017 at 7:03:45 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Sunday, January 29, 2017 at 4:06:11 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> > <snip>
> > I am truly sorry for asking it here, not in a new thread, but as we have
> > lightly touched upon it, I decided to ask a very brief question. I am
> > trying to find a good way to make the function, which computes rates and
> > puts them into the assumptions structure, to return something, to avoid
> > making it 'void', but I for now I have not yet found any plausible
> > alternative; even boolean returns don't make any sense.
> > What possible return values exist for functions that resemble the one
> > below?
> > /** Function to set assumptions: rates
> > for pro forma income statement items,
> > except depreciation & interest **/
> > void income_rates(cs_income_st *cs_income_ptr, assumptions *rates,\
> > size_t line_num, double member_product)
> > {
> > double rate = pow(member_product, 1.0/DATA_SIZE) - 1;
> > switch(line_num)
> > {
> > case 1:>
> > rates->gr_sales = pow((cs_income_ptr[DATA_SIZE-1].cs_sales\
> > /cs_income_ptr[0].cs_sales),\
>
> You don't need the \s there (and above).
>
> > (1.0/DATA_SIZE))-1;
> > break;
> > case 2:
> > rates->av_cogs = rate;
> > break;
> > case 3:
> > rates->av_gross_profit = rate;
> > break;
> > case 4:
> > rates->av_sga = rate;
> > break;
> > case 5:
> > rates->av_oper_inc = rate;
> > break;
> > case 7:
> > rates->av_oper_prof = rate;
> > break;
> > case 9:
> > rates->av_gain_loss = rate;
> > break;
> > case 10:
> > rates->av_pretax_inc = rate;
> > break;
> > case 11:
> > rates->av_tax_exp = STAT_TAX;
> > break;
> > case 12:
> > rates->av_net_inc = rate;
> > break;
> > default:
> > break;
> > }
> > }
>
> I don't see a need for this to driven by line_num. Can't you just
> write:
>
> rates->gr_sales = pow((cs_income_ptr[DATA_SIZE-1].cs_sales
> /cs_income_ptr[0].cs_sales),
> (1.0/DATA_SIZE))-1;
> rates->av_cogs = rate;
> rates->av_gross_profit = rate;
> rates->av_sga = rate;
> rates->av_oper_inc = rate;
> rates->av_oper_prof = rate;
> rates->av_gain_loss = rate;
> rates->av_pretax_inc = rate;
> rates->av_tax_exp = STAT_TAX;
> rates->av_net_inc = rate;
>
> once you have all the data available?
Yesterday I wrote a hasty reply saying I can; but I have not
looked at the my program and at this function while writing
that, which was a mistake. No, I can't - I need to leave the switch
and line_number because member_product is being
computed by the function, which parses numbers from each
line, hence the calling routing sends member_product
to the rate function as it reads each line. Of course,
as you said, the sub function should never bother
choosing any thing, but perform an action on parameters
it receives. Then it means that this function should not
exist at all, and all these operations in the switch
should be moved to the calling routine, but it will make
it visually bigger ((
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-30 11:06 +0000 |
| Message-ID | <87mve8q02d.fsf@bsb.me.uk> |
| In reply to | #102737 |
Alla _ <modelling.data@gmail.com> writes:
> On Sunday, January 29, 2017 at 7:03:45 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Sunday, January 29, 2017 at 4:06:11 PM UTC+3, Ben Bacarisse wrote:
>> >> Alla _ <modelling.data@gmail.com> writes:
>> >>
>> > <snip>
>> > I am truly sorry for asking it here, not in a new thread, but as we have
>> > lightly touched upon it, I decided to ask a very brief question. I am
>> > trying to find a good way to make the function, which computes rates and
>> > puts them into the assumptions structure, to return something, to avoid
>> > making it 'void', but I for now I have not yet found any plausible
>> > alternative; even boolean returns don't make any sense.
>> > What possible return values exist for functions that resemble the one
>> > below?
>> > /** Function to set assumptions: rates
>> > for pro forma income statement items,
>> > except depreciation & interest **/
>> > void income_rates(cs_income_st *cs_income_ptr, assumptions *rates,\
>> > size_t line_num, double member_product)
>> > {
>> > double rate = pow(member_product, 1.0/DATA_SIZE) - 1;
>> > switch(line_num)
>> > {
>> > case 1:
>> > rates->gr_sales = pow((cs_income_ptr[DATA_SIZE-1].cs_sales\
>> > /cs_income_ptr[0].cs_sales),\
>> > (1.0/DATA_SIZE))-1;
>> > break;
>> > case 2:
>> > rates->av_cogs = rate;
>> > break;
>> > case 3:
>> > rates->av_gross_profit = rate;
>> > break;
>> > case 4:
>> > rates->av_sga = rate;
>> > break;
>> > case 5:
>> > rates->av_oper_inc = rate;
>> > break;
>> > case 7:
>> > rates->av_oper_prof = rate;
>> > break;
>> > case 9:
>> > rates->av_gain_loss = rate;
>> > break;
>> > case 10:
>> > rates->av_pretax_inc = rate;
>> > break;
>> > case 11:
>> > rates->av_tax_exp = STAT_TAX;
>> > break;
>> > case 12:
>> > rates->av_net_inc = rate;
>> > break;
>> > default:
>> > break;
>> > }
>> > }
>>
>> I don't see a need for this to driven by line_num. Can't you just
>> write:
>>
>> rates->gr_sales = pow((cs_income_ptr[DATA_SIZE-1].cs_sales
>> /cs_income_ptr[0].cs_sales),
>> (1.0/DATA_SIZE))-1;
>> rates->av_cogs = rate;
>> rates->av_gross_profit = rate;
>> rates->av_sga = rate;
>> rates->av_oper_inc = rate;
>> rates->av_oper_prof = rate;
>> rates->av_gain_loss = rate;
>> rates->av_pretax_inc = rate;
>> rates->av_tax_exp = STAT_TAX;
>> rates->av_net_inc = rate;
>>
>> once you have all the data available?
> Yesterday I wrote a hasty reply saying I can; but I have not
> looked at the my program and at this function while writing
> that, which was a mistake. No, I can't
OK. This just means you can't write it as simply as I suggested but
there is no question that that switch (and therefore the function) has
to go!
> - I need to leave the switch
> and line_number because member_product is being
> computed by the function, which parses numbers from each
> line, hence the calling routing sends member_product
> to the rate function as it reads each line.
You will often find that a decision in one place has consequences
elsewhere. Sometimes the consequences are so unpleasant that you have
to re-think the earlier decision. It sounds like you should store these
different member_products (or, possibly, the data that are used to
calculate them) in order to calculates the different rates later.
I am, as always, hampered by not being able to see the whole picture.
It's possible that a compute-as-you-go program will be better than a
store-it-all-compute-later program. I can't tell because I don't know
all the data flows in the code.
One key question you could answer is this: when processing a line, do
you ever need data that is on (or calculated from data that is on) a
subsequent line, or do you only need from (or calculated form) the
previous lines?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web