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 | 9 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 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-30 00:13 -0800 |
| Message-ID | <a7d61600-b010-4962-b6b4-d2ed81521b07@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?
I have just deleted the whole function, and moved the switch
to the calling function; although it is more vertical in appearance
now, it does look more logically correct, and I don't have any
void function.
Continuing with some "housekeeping" before moving on
to computing the table. Have deleted a few other redundant
things.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-27 07:39 -0800 |
| Message-ID | <32345bc8-5459-4d6c-b167-6a517bde7205@googlegroups.com> |
| In reply to | #102519 |
On Friday, January 27, 2017 at 4:34:06 AM UTC-6, Richard Heathfield wrote:
> 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".
For some algorithms it won't matter what value a storage location is
initialized with provided *only* that it behaves as a value of the
appropriate type. Consider, for example:
uint32_t result=0;
for (int i=0; i<32; i++)
{
strobe_clock();
result >>= 1;
if (data_input()) result |= 0x80000000;
}
Any uint32_t value "result" might start with would be erased in the
course of 32 iterations of the loop, but I don't know any Standard
way of indicating that a compiler could let it start with any 32-bit
value. Even though uint32_t has no trap representations, omitting
the initialization of "result" could cause errant behavior. A
Standard-defined directive which would say "set an lvalue to any
arbitrary value of its type" [which could be ignored by compilers
where uninitialized values naturally behave that way] would seem
to offer both performance and readability benefits. Note that
something like "result = __UNSPECIFIED;" would work on compilers that
recognize that concept, but would generate needless extra code on
compilers that neither recognize nor need it. A directive that acts
on an lvalue, e.g. __SET_UNSPECIFIED(result);, could more easily be
ignored by compilers where it would be unnecessary.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-01-27 17:30 +0100 |
| Message-ID | <o6fsfn$3ih$1@dont-email.me> |
| In reply to | #102536 |
On 27/01/17 16:39, supercat@casperkitty.com wrote:
> On Friday, January 27, 2017 at 4:34:06 AM UTC-6, Richard Heathfield wrote:
>> 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".
>
> For some algorithms it won't matter what value a storage location is
> initialized with provided *only* that it behaves as a value of the
> appropriate type. Consider, for example:
>
> uint32_t result=0;
>
> for (int i=0; i<32; i++)
> {
> strobe_clock();
> result >>= 1;
> if (data_input()) result |= 0x80000000;
> }
>
> Any uint32_t value "result" might start with would be erased in the
> course of 32 iterations of the loop, but I don't know any Standard
> way of indicating that a compiler could let it start with any 32-bit
> value. Even though uint32_t has no trap representations, omitting
> the initialization of "result" could cause errant behavior. A
> Standard-defined directive which would say "set an lvalue to any
> arbitrary value of its type" [which could be ignored by compilers
> where uninitialized values naturally behave that way] would seem
> to offer both performance and readability benefits. Note that
> something like "result = __UNSPECIFIED;" would work on compilers that
> recognize that concept, but would generate needless extra code on
> compilers that neither recognize nor need it. A directive that acts
> on an lvalue, e.g. __SET_UNSPECIFIED(result);, could more easily be
> ignored by compilers where it would be unnecessary.
>
Many compilers accept the idiom "uint32_t result = result;" to give you
this.
Fun-fact - clang recommends this as a solution to avoid the "variable is
uninitialized when used" warning if you just have "uint32_t result;".
But if you write "uint32_t result = result;", it warns that you are
using "result" within its own initialisation!
If not, you can always try inline assembly:
uint32_t result;
asm ("" : "=g" (result) :: );
On compatible compilers, that "initialises" result to whatever happens
to be in its register at the time.
Fun-fact - gcc 7 is smart enough to tell that it does not need an
uninitialised warning for the code above, even with "uint32_t result;".
If you reduce the loop to less than 32, then the warning (correctly)
appears. gcc 6 is not quite as clever.
gcc.godbolt.org is a marvellous tool!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-27 16:16 +0000 |
| Message-ID | <87r33oxyu3.fsf@bsb.me.uk> |
| In reply to | #102519 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> 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'll just add that not everyone thinks this is a good habit. The other
side of the coin is that an initialisation that is not strictly needed
causes the reader to wonder why that object has that value. When I see
double rates[N_YEARS] = {0};
I think "ah, the rates must be zero to start with". When I see
double rates[N_YEARS];
I think "ah, some rates (no more that N_YEARS) will be calculated later
on".
Yet another point of view comes from modern C where the rule might be
"if you can't give it the right initial value, this may be the wrong
place to declare it".
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-27 11:49 -0800 |
| Message-ID | <lnfuk4cmgj.fsf@kst-u.example.com> |
| 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. 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;
> }
Let me try to summarize what I *think* you're trying to do. (I haven't
been following this thread 100% thoroughly, so I might be either
repeating or misunderstanding some of what's been said.)
You have an array of structures, where each structure has a member of
type double. You want to compute the geometric mean of those N members.
That seems straightforward enough that I don't mind showing a solution
rather than a hint:
#include <stdio.h>
#include <math.h>
struct foo {
double x;
};
static double geomean(struct foo *arr, size_t count) {
double product = 1.0;
for (size_t i = 0; i < count; i ++) {
product *= arr[i].x;
}
return pow(product, 1.0/count);
}
int main(void) {
struct foo the_array[] = {
{ .x = 3.0 },
{ .x = 4.0 },
{ .x = 5.0 }
};
printf("Geometric mean = %f\n",
geomean(the_array, sizeof the_array / sizeof the_array[0]));
}
Output:
Geometric mean = 3.914868
(which is consistent with my manual calculation of the cube root of
3*4*5).
You say you want to make the function "generic". That can mean a lot of
things, but I think what you want is to have a function that can do the
same thing for an array of *any* structure type that contains a double
member.
There is no clean way to do that in C.
I can think of several not-so-clean solutions. The standard qsort()
function gives some hints about how you can operate on arrays of
arbitrary element types
You could pass a void* pointer to the initial element of the array,
along with a size_t indicating the size of a single element, another
size_t to specify the number of elements, *and* yet another size_t to
specify the offset of the double member within the structure. The body
of the function will have to do some fairly ugly pointer casts to
extract the actual data. If you do everything correctly, it should
work, but there are a number of mistakes you could make that the
compiler can't help you diagnose, because you you have to throw away
type information.
You could also wrap the entire function definition in a macro
definition, with macro parameters to specify the name of the structure
type and of the double member. You'd have to invoke the macro for each
structure type, creating a new function with a distinct name.
Or the geomean() function could take a function pointer as an argument,
where the pointed-to function returns the value of the double member.
But you'd still have to use void* pointers to refer to the array
elements.
The fact that doing this is so ugly might suggest that a change of data
structure would be appropriate. (Or conceivably a change of language,
but I'm not sure what language would handle this gracefully; I don't
think C++ would.)
If you're doing a lot of operations that have to iterate over sequences
of double values, it's going to be a lot easier if they're stored in
arrays of doubles, rather than scattered as double members of arrays of
structures.
On the other hand, that loses the coherence of using a structure to
collect all the relevant information about a given entity in one place.
Conceivably the structure could contain a pointer to the array element,
but keeping that consistent is going to be non-trivial.
--
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-28 00:48 -0800 |
| Message-ID | <971f7660-ee89-47b7-acde-1dc1e1ae2655@googlegroups.com> |
| In reply to | #102592 |
On Friday, January 27, 2017 at 10:48:29 PM UTC+3, Keith Thompson 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. 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;
> > }
>
> Let me try to summarize what I *think* you're trying to do. (I haven't
> been following this thread 100% thoroughly, so I might be either
> repeating or misunderstanding some of what's been said.)
>
> You have an array of structures, where each structure has a member of
> type double. You want to compute the geometric mean of those N members.
>
> That seems straightforward enough that I don't mind showing a solution
> rather than a hint:
>
> #include <stdio.h>
> #include <math.h>
>
> struct foo {
> double x;
> };
>
> static double geomean(struct foo *arr, size_t count) {
> double product = 1.0;
> for (size_t i = 0; i < count; i ++) {
> product *= arr[i].x;
> }
> return pow(product, 1.0/count);
> }
>
> int main(void) {
> struct foo the_array[] = {
> { .x = 3.0 },
> { .x = 4.0 },
> { .x = 5.0 }
> };
> printf("Geometric mean = %f\n",
> geomean(the_array, sizeof the_array / sizeof the_array[0]));
> }
>
Yes, this is exactly how I do it, except that I have to pass two
pointers to two structures, and I don't pass a count, because
I use a predefined number of elements. My computations are
a bit more complex, but the idea is exactly the same. I also
include some cases when I call an arithmetic mean function.
> Output:
> Geometric mean = 3.914868
> (which is consistent with my manual calculation of the cube root of
> 3*4*5).
>
> You say you want to make the function "generic". That can mean a lot of
> things, but I think what you want is to have a function that can do the
> same thing for an array of *any* structure type that contains a double
> member.
Yes ))) This is exactly what I was asking about )
>
> There is no clean way to do that in C.
Oh, I see.
>
> I can think of several not-so-clean solutions. The standard qsort()
> function gives some hints about how you can operate on arrays of
> arbitrary element types
>
> You could pass a void* pointer to the initial element of the array,
> along with a size_t indicating the size of a single element, another
> size_t to specify the number of elements, *and* yet another size_t to
> specify the offset of the double member within the structure. The body
> of the function will have to do some fairly ugly pointer casts to
> extract the actual data. If you do everything correctly, it should
> work, but there are a number of mistakes you could make that the
> compiler can't help you diagnose, because you you have to throw away
> type information.
>
> You could also wrap the entire function definition in a macro
> definition, with macro parameters to specify the name of the structure
> type and of the double member. You'd have to invoke the macro for each
> structure type, creating a new function with a distinct name.
>
Do I include this macro as part of the function definition (as a parameter),
and then use specific struct types within a calling routine to pass those
to a function?
> Or the geomean() function could take a function pointer as an argument,
> where the pointed-to function returns the value of the double member.
> But you'd still have to use void* pointers to refer to the array
> elements.
>
> The fact that doing this is so ugly might suggest that a change of data
> structure would be appropriate. (Or conceivably a change of language,
> but I'm not sure what language would handle this gracefully; I don't
> think C++ would.)
>
> If you're doing a lot of operations that have to iterate over sequences
> of double values, it's going to be a lot easier if they're stored in
> arrays of doubles, rather than scattered as double members of arrays of
> structures.
>
> On the other hand, that loses the coherence of using a structure to
> collect all the relevant information about a given entity in one place.
> Conceivably the structure could contain a pointer to the array element,
> but keeping that consistent is going to be non-trivial.
Thank you very much for these explanations. I will have to think over them,
and see if I can apply any of those now. Most likely, I will not do that, and stick
to the approach I am using now.
Honestly, what is coming out, truly disappoints me because the whole program
now runs afoul of my sense of elegance, grace, beauty, etc., which are, to my
opinion, inherent in C, and which has attracted me so much to this language.
Though I do hope to make the program at least somewhat better.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-28 11:02 -0800 |
| Message-ID | <lnvaszatzm.fsf@kst-u.example.com> |
| In reply to | #102622 |
Alla _ <modelling.data@gmail.com> writes:
> On Friday, January 27, 2017 at 10:48:29 PM UTC+3, Keith Thompson wrote:
[...]
>> You could also wrap the entire function definition in a macro
>> definition, with macro parameters to specify the name of the structure
>> type and of the double member. You'd have to invoke the macro for each
>> structure type, creating a new function with a distinct name.
>>
> Do I include this macro as part of the function definition (as a parameter),
> and then use specific struct types within a calling routine to pass those
> to a function?
No, the idea is that the macro would expand to an entire function
definition, and you'd invoke the macro once for each structure type to
define a function for that type. It's very similar to a C++ template,
but much uglier and less type-safe.
Here's a trivial (and not at all useful) example of what I'm talking
about:
#include <stdio.h>
#define DEFINE_INCREMENT_FUNCTION(type, name) \
void name(type *ptr) { \
*ptr ++; \
}
DEFINE_INCREMENT_FUNCTION(int, inc_int)
DEFINE_INCREMENT_FUNCTION(double, inc_double)
int main(void) {
int i = 3;
inc_int(&i);
double d = 4.5;
inc_double(&d);
printf("i = %d, d = %f\n", i, d);
}
This is not a good idea. This is an ugly approach that might become
necessary in some circumstances.
A similar approach is to define the function in a separate source file,
and have the definition refer to several macros; you could then define
those macros and #include the file.
Note carefully that I am *not* recommending either approach. I'm just
presenting alternatives that might become necessary if you need to deal
with an existing set of data structures that don't allow for more
straighforward code.
[...]
--
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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-28 11:09 -0500 |
| Message-ID | <25057a5f-8fb9-2493-6fd5-d7bc1f2f78b6@verizon.net> |
| In reply to | #102592 |
On 01/27/2017 02:49 PM, Keith Thompson wrote:
...
> Let me try to summarize what I *think* you're trying to do. (I haven't
> been following this thread 100% thoroughly, so I might be either
> repeating or misunderstanding some of what's been said.)
>
> You have an array of structures, where each structure has a member of
> type double. You want to compute the geometric mean of those N members.
>
> That seems straightforward enough that I don't mind showing a solution
> rather than a hint:
>
> #include <stdio.h>
> #include <math.h>
>
> struct foo {
> double x;
> };
>
> static double geomean(struct foo *arr, size_t count) {
> double product = 1.0;
> for (size_t i = 0; i < count; i ++) {
> product *= arr[i].x;
> }
> return pow(product, 1.0/count);
> }
>
> int main(void) {
> struct foo the_array[] = {
> { .x = 3.0 },
> { .x = 4.0 },
> { .x = 5.0 }
> };
> printf("Geometric mean = %f\n",
> geomean(the_array, sizeof the_array / sizeof the_array[0]));
> }
>
> Output:
> Geometric mean = 3.914868
> (which is consistent with my manual calculation of the cube root of
> 3*4*5).
>
> You say you want to make the function "generic". That can mean a lot of
> things, but I think what you want is to have a function that can do the
> same thing for an array of *any* structure type that contains a double
> member.
>
> There is no clean way to do that in C.
>
> I can think of several not-so-clean solutions. The standard qsort()
> function gives some hints about how you can operate on arrays of
> arbitrary element types
>
> You could pass a void* pointer to the initial element of the array,
> along with a size_t indicating the size of a single element, another
> size_t to specify the number of elements, *and* yet another size_t to
> specify the offset of the double member within the structure. The body
> of the function will have to do some fairly ugly pointer casts to
> extract the actual data. If you do everything correctly, it should
> work, but there are a number of mistakes you could make that the
> compiler can't help you diagnose, because you you have to throw away
> type information.
>
> You could also wrap the entire function definition in a macro
> definition, with macro parameters to specify the name of the structure
> type and of the double member. You'd have to invoke the macro for each
> structure type, creating a new function with a distinct name.
>
> Or the geomean() function could take a function pointer as an argument,
> where the pointed-to function returns the value of the double member.
> But you'd still have to use void* pointers to refer to the array
> elements.
>
> The fact that doing this is so ugly might suggest that a change of data
> structure would be appropriate. (Or conceivably a change of language,
> but I'm not sure what language would handle this gracefully; I don't
> think C++ would.)
In IDL, if you have an array of structures you can access a named member
of all elements of the array as if they were themselves elements of an
array. I don't know the details of how that's implemented, but I'm sure
it's slow compared to C code - but t makes it a lot easier to write
certain kinds of code.
In C++, a truly generic geometric mean routine would take the start and
end of an iterator range as two of its arguments. You could define an
iterator that iterates over the elements of an array of structs,
referring to a specified element of each of those the elements. To
genericize it the way Alla_ is insisting on would require using a member
pointer to identify the particular element of the array you want to
access. That's functionally equivalent to the offsetof() method, but
more type-safe. Setting it up would be complicated, but using it would
be fairly simple.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-01-28 18:56 +0000 |
| Message-ID | <slrn3vfso8pqe9.ap4.ike@iceland.freeshell.org> |
| In reply to | #102489 |
On 2017-01-26, Alla _ <modelling.data@gmail.com> wrote:
> 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!
Regarding the variable 'multiply': what do you think will happen
when you mulitiply the initial value 0.0 with somethihg else (in
your case, the complicated expression that starts wich (1 +
(income_ptr[1] ...)) ?
Do you realize that multiplying 0.0 by some complicated expression will
yield 0.0 ?
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.c
csiph-web