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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-30 19:54 +0000 |
| Message-ID | <87tw8gnx29.fsf@bsb.me.uk> |
| In reply to | #102763 |
Alla _ <modelling.data@gmail.com> writes:
> On Monday, January 30, 2017 at 7:48:17 PM UTC+3, James R. Kuyper wrote:
>> On 01/29/2017 04:55 PM, Ben Bacarisse wrote:
<snip>
>> > In short, (and to get topical) there are three calculations that you
>> > might need to use in various situations:
>> >
>> > double arith_mean(double a, double b) { return (a + b)/2; }
>> >
>> > double geom_mean(double a, double b) { return sqrt(a * b); }
>> >
>> > double mean_of_changes(double a, double b) { return sqrt((a+1) * (b+1)) - 1; }
>> >
>> > Your function calculated this:
>> >
>> > if (a < 0 || b < 0)
>> > return arith_mean(a, b);
>> > else if (a < 1 && b < 1)
>> > return mean_of_changes(a, b) + 1;
>> > else if (a < 1)
>> > return geom_mean(a + 1, b);
>> > else if (b < 1)
>> > return geom_mean(a, b + 1);
>> > else
>> > return geom_mean(a, b);
>> >
>> > As you can see, in three of the five cases, your function does not
>> > calculate one of the usual functions.
>> >
<snip>
>> Your function switches which calculation it performs based upon the
>> values of the numbers, which makes no sense. It should only depend upon
>> the meaning of those numbers. If it makes sense to call arith_mean(a,b)
>> for some values of a and b, it does not make sense to call
>> geom_mean(a,b) when those numbers have different values.
>>
>> Your function is symmetrical, which implies that number1 and number2
>> have the same type of meaning. If so, it doesn't make sense to ever call
>> geom_mean(a+1, b) or geom_mean(a, b+1): those function calls make sense
>> only if a and b have very different meanings.
<snip>
> James, I see what you mean, but I don't understand why again.
> I had what I would call a typo, and have explained this quite a few messages
> ago.
> I don't understand why you say this about the code below, which
> I have showed previously.
I don't recall seeing the code below before. I would not have posted
what I did if I had. (I would have made some similar points but not
exactly the same ones.) I'm sorry if I have led James astray by
commenting on old code, but the basic problem remains.
> To my opinion it doesn't do what you
> claim it does. I call geomean only when both
> absolute values of two numbers are in the range between 1 and 0.
>
> double mean_twonums(double number1, double number2)
> {
> // if both abs values of numbers are between 1 and 0
> if( (fabs(number1) < 1 && fabs(number1) > 0)
> && (fabs(number2) < 1 && fabs(number2) > 0) )
> {
> number1 += 1.0;
> number2 += 1.0;
>
> return pow((number1*number2), 1.0/2) - 1;
> }
> // if any number is negative return simple arithm average
> if(number1 < 0 || number2 < 0)
> return (number1+number2)/2;
> //compute geo mean for any other cases
> return pow((number1*number2), 1.0/2);
> }
This function has the same basic issue that James and I are concerned
about: it calculates a different function based on the values of the
parameters rather than on their meaning. (James put it much better that
I did.) That's almost always wrong, but even when it's right it's going
to raise eyebrows and need extensive comments.
It's not just the programmer or mathematician in me that makes me think
you need to redesign this function. You've said some things in the past
that make me think you are not entirely sure when to use one or other
kind of mean. For example you said
| if two values are between 1 and zero (i.e. if they are ratios, or
| percents, whatever one calls it), then to compute a geometric mean I
| do the following: ((1 + number2)*(1 + number2)*.....(1 +
| numberN))^(1/N)
(there's probably a missing - 1 at the end, but that's a detail). This
is an odd remark for two reasons. Firstly, ratios and percents can be
larger than 1 so you can't tell a ratio from the value alone. Secondly,
the reason to add 1 is because the percentage is a change rather than a
factor. Sales can be repeatedly down by 30% or they can be only 70% of
what they were the previous year. Both are percentages but one needs
sqrt(.7 * .7) and the other needs sqrt((-.3 + 1) * (-.3 + 1)) - 1 to get
the "average".
At each place where you use this function, you will know which of the
two you want (I can't understand the third option at all -- maybe you
can shed some light on that). Some of the calls will be on changes and
others on factors (this is not, maybe, the best terminology but I don't
know of any better terms).
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-31 12:51 -0800 |
| Message-ID | <dd9674be-7702-444a-9c8b-3bc6cf65382a@googlegroups.com> |
| In reply to | #102788 |
On Monday, January 30, 2017 at 10:54:14 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Monday, January 30, 2017 at 7:48:17 PM UTC+3, James R. Kuyper wrote:
> >> On 01/29/2017 04:55 PM, Ben Bacarisse wrote:
> <snip>
> >> > In short, (and to get topical) there are three calculations that you
> >> > might need to use in various situations:
> >> >
> >> > double arith_mean(double a, double b) { return (a + b)/2; }
> >> >
> >> > double geom_mean(double a, double b) { return sqrt(a * b); }
> >> >
> >> > double mean_of_changes(double a, double b) { return sqrt((a+1) * (b+1)) - 1; }
> >> >
> >> > Your function calculated this:
> >> >
> >> > if (a < 0 || b < 0)
> >> > return arith_mean(a, b);
> >> > else if (a < 1 && b < 1)
> >> > return mean_of_changes(a, b) + 1;
> >> > else if (a < 1)
> >> > return geom_mean(a + 1, b);
> >> > else if (b < 1)
> >> > return geom_mean(a, b + 1);
> >> > else
> >> > return geom_mean(a, b);
> >> >
> >> > As you can see, in three of the five cases, your function does not
> >> > calculate one of the usual functions.
> >> >
> <snip>
> >> Your function switches which calculation it performs based upon the
> >> values of the numbers, which makes no sense. It should only depend upon
> >> the meaning of those numbers. If it makes sense to call arith_mean(a,b)
> >> for some values of a and b, it does not make sense to call
> >> geom_mean(a,b) when those numbers have different values.
> >>
> >> Your function is symmetrical, which implies that number1 and number2
> >> have the same type of meaning. If so, it doesn't make sense to ever call
> >> geom_mean(a+1, b) or geom_mean(a, b+1): those function calls make sense
> >> only if a and b have very different meanings.
> <snip>
> > James, I see what you mean, but I don't understand why again.
> > I had what I would call a typo, and have explained this quite a few messages
> > ago.
> > I don't understand why you say this about the code below, which
> > I have showed previously.
>
> I don't recall seeing the code below before. I would not have posted
> what I did if I had. (I would have made some similar points but not
> exactly the same ones.) I'm sorry if I have led James astray by
> commenting on old code, but the basic problem remains.
>
> > To my opinion it doesn't do what you
> > claim it does. I call geomean only when both
> > absolute values of two numbers are in the range between 1 and 0.
> >
> > double mean_twonums(double number1, double number2)
> > {
> > // if both abs values of numbers are between 1 and 0
> > if( (fabs(number1) < 1 && fabs(number1) > 0)
> > && (fabs(number2) < 1 && fabs(number2) > 0) )
> > {
> > number1 += 1.0;
> > number2 += 1.0;
> >
> > return pow((number1*number2), 1.0/2) - 1;
> > }
> > // if any number is negative return simple arithm average
> > if(number1 < 0 || number2 < 0)
> > return (number1+number2)/2;
> > //compute geo mean for any other cases
> > return pow((number1*number2), 1.0/2);
> > }
>
> This function has the same basic issue that James and I are concerned
> about: it calculates a different function based on the values of the
> parameters rather than on their meaning. (James put it much better that
> I did.) That's almost always wrong, but even when it's right it's going
> to raise eyebrows and need extensive comments.
>
> It's not just the programmer or mathematician in me that makes me think
> you need to redesign this function. You've said some things in the past
> that make me think you are not entirely sure when to use one or other
> kind of mean. For example you said
>
> | if two values are between 1 and zero (i.e. if they are ratios, or
> | percents, whatever one calls it), then to compute a geometric mean I
> | do the following: ((1 + number2)*(1 + number2)*.....(1 +
> | numberN))^(1/N)
>
> (there's probably a missing - 1 at the end, but that's a detail). This
> is an odd remark for two reasons. Firstly, ratios and percents can be
> larger than 1 so you can't tell a ratio from the value alone. Secondly,
> the reason to add 1 is because the percentage is a change rather than a
> factor. Sales can be repeatedly down by 30% or they can be only 70% of
> what they were the previous year. Both are percentages but one needs
> sqrt(.7 * .7) and the other needs sqrt((-.3 + 1) * (-.3 + 1)) - 1 to get
> the "average".
>
> At each place where you use this function, you will know which of the
> two you want (I can't understand the third option at all -- maybe you
> can shed some light on that). Some of the calls will be on changes and
> others on factors (this is not, maybe, the best terminology but I don't
> know of any better terms).
I think that the main problem is caused by my carelessness in explaining
what I want to do and inattentiveness to the wording I use.
But I truly didn't want to cause so much trouble by something which
is out side C matters, and, as I said initially, which I didn't intend to put
any effort in because it is not related to learning C and programming;
all these computations are supposed to be very very simple, and i wanted
to stick to the arithmetic mean, but then decided to add geo mean computations
to increase complexity of the programming task.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-31 16:54 -0500 |
| Message-ID | <190874e9-bfdc-d8c1-6b8c-ee6097579edd@verizon.net> |
| In reply to | #102864 |
On 01/31/2017 03:51 PM, Alla _ wrote: ... > I think that the main problem is caused by my carelessness in explaining > what I want to do and inattentiveness to the wording I use. That may be part of it, but I strongly suspect that even if you were more careful and attentive in describing what your code is intended to do, your code would still fail to do it correctly. What your code actually does doesn't come close enough to matching what you've already said for the discrepancy to be merely the result of careless or inattentive explanations. It seems to be the result of thoughtlessly complicating code that should be much simpler. Thoughtful complications can often be an improvement over the simpler code, but thoughtless ones just lead to trouble. > But I truly didn't want to cause so much trouble by something which > is out side C matters, and, as I said initially, which I didn't intend to put > any effort in because it is not related to learning C and programming; > all these computations are supposed to be very very simple, and i wanted > to stick to the arithmetic mean, but then decided to add geo mean computations > to increase complexity of the programming task. If you had simply replaced the arithmetic mean with the geometric mean, that would have been fine. Switching between three different ways of calculating the mean, without even having any good reason for the switches, is the key problem with that code. It won't prevent the code from executing, but it will prevent the results from having any useful meaning.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-30 12:19 -0800 |
| Message-ID | <lno9yo9u7i.fsf@kst-u.example.com> |
| In reply to | #102763 |
Alla _ <modelling.data@gmail.com> writes:
[...]
> And, to Keith, I am a girl :)
I'm aware. If I've used an incorrect pronoun, I apologize, but I'm not
aware that I have, nor do I see anything from me in this post or the few
of its direct ancestors I bothered to check.
[...]
> double mean_twonums(double number1, double number2)
> {
> // if both abs values of numbers are between 1 and 0
> if( (fabs(number1) < 1 && fabs(number1) > 0)
> && (fabs(number2) < 1 && fabs(number2) > 0) )
> {
> number1 += 1.0;
> number2 += 1.0;
>
> return pow((number1*number2), 1.0/2) - 1;
> }
> // if any number is negative return simple arithm average
> if(number1 < 0 || number2 < 0)
> return (number1+number2)/2;
> //compute geo mean for any other cases
> return pow((number1*number2), 1.0/2);
> }
I can't comment on whether this function is meaningful in financial
terms, but I find the name "mean_twonums" misleading at best.
The name strongly implies that it computes the mean of two numbers,
which should be as simple as
return (number1 + number2) / 2.0;
for an arithmetic mean, or
return sqrt(number1 * number2);
for a geometric mean. There are other kinds of means, such as the
harmonic mean, but the value computed by this function doesn't resemble
any of them.
What this function actually does strikes me as quite arbitrary,
but that's merely a statement about my misunderstanding. If this
mathematical function is actually called a "mean" in the field of
finance, then I suppose my objection is with financial terminology.
If it's not called a "mean", then I would hope that there's some
coherent name for it.
I seem to recall you also had a function called something like
"geomean()" that computed something other than a geometic mean.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-30 13:54 -0800 |
| Message-ID | <lnbmuo9psr.fsf@kst-u.example.com> |
| In reply to | #102794 |
Keith Thompson <kst-u@mib.org> writes:
[...]
> What this function actually does strikes me as quite arbitrary,
> but that's merely a statement about my misunderstanding.
[...]
I meant to say "lack of understanding" rather than "misunderstanding".
--
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-31 12:57 -0800 |
| Message-ID | <053298c7-0b3f-45c6-a1b2-a53663fca412@googlegroups.com> |
| In reply to | #102794 |
On Monday, January 30, 2017 at 11:18:19 PM UTC+3, Keith Thompson wrote:
> Alla _ <modelling.data@gmail.com> writes:
> [...]
> > And, to Keith, I am a girl :)
>
> I'm aware. If I've used an incorrect pronoun, I apologize, but I'm not
> aware that I have, nor do I see anything from me in this post or the few
> of its direct ancestors I bothered to check.
I thought I have seen it somewhere, but that is definitely not an issue )
I am not one of those marching individuals ) And I am not very fond of
this fairly new concept of naming everyone "she", particularly in
professional context; it looks like an eyesore in all modern professional
literature - everyone has suddenly been addressed as "she", and it
looks and sounds very odd, bizarre and unnatural.
>
> [...]
>
> > double mean_twonums(double number1, double number2)
> > {
> > // if both abs values of numbers are between 1 and 0
> > if( (fabs(number1) < 1 && fabs(number1) > 0)
> > && (fabs(number2) < 1 && fabs(number2) > 0) )
> > {
> > number1 += 1.0;
> > number2 += 1.0;
> >
> > return pow((number1*number2), 1.0/2) - 1;
> > }
> > // if any number is negative return simple arithm average
> > if(number1 < 0 || number2 < 0)
> > return (number1+number2)/2;
> > //compute geo mean for any other cases
> > return pow((number1*number2), 1.0/2);
> > }
>
> I can't comment on whether this function is meaningful in financial
> terms, but I find the name "mean_twonums" misleading at best.
> The name strongly implies that it computes the mean of two numbers,
> which should be as simple as
> return (number1 + number2) / 2.0;
> for an arithmetic mean, or
> return sqrt(number1 * number2);
> for a geometric mean. There are other kinds of means, such as the
> harmonic mean, but the value computed by this function doesn't resemble
> any of them.
>
Yes, this is exactly what it does. Indeed it has been mentioned many
times that i have to change the pow to sqrt. Truly sorry for not doing
it yet.
> What this function actually does strikes me as quite arbitrary,
> but that's merely a statement about my misunderstanding. If this
> mathematical function is actually called a "mean" in the field of
> finance, then I suppose my objection is with financial terminology.
> If it's not called a "mean", then I would hope that there's some
> coherent name for it.
>
> I seem to recall you also had a function called something like
> "geomean()" that computed something other than a geometic mean.
>
> --
> 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-31 13:35 -0800 |
| Message-ID | <lnk29a9akl.fsf@kst-u.example.com> |
| In reply to | #102865 |
Alla _ <modelling.data@gmail.com> writes:
> On Monday, January 30, 2017 at 11:18:19 PM UTC+3, Keith Thompson wrote:
>> Alla _ <modelling.data@gmail.com> writes:
[...]
>> > double mean_twonums(double number1, double number2)
>> > {
>> > // if both abs values of numbers are between 1 and 0
>> > if( (fabs(number1) < 1 && fabs(number1) > 0)
>> > && (fabs(number2) < 1 && fabs(number2) > 0) )
>> > {
>> > number1 += 1.0;
>> > number2 += 1.0;
>> >
>> > return pow((number1*number2), 1.0/2) - 1;
>> > }
>> > // if any number is negative return simple arithm average
>> > if(number1 < 0 || number2 < 0)
>> > return (number1+number2)/2;
>> > //compute geo mean for any other cases
>> > return pow((number1*number2), 1.0/2);
>> > }
>>
>> I can't comment on whether this function is meaningful in financial
>> terms, but I find the name "mean_twonums" misleading at best.
>> The name strongly implies that it computes the mean of two numbers,
>> which should be as simple as
>> return (number1 + number2) / 2.0;
>> for an arithmetic mean, or
>> return sqrt(number1 * number2);
>> for a geometric mean. There are other kinds of means, such as the
>> harmonic mean, but the value computed by this function doesn't resemble
>> any of them.
>>
> Yes, this is exactly what it does. Indeed it has been mentioned many
> times that i have to change the pow to sqrt. Truly sorry for not doing
> it yet.
Using sqrt() rather than pow() is a minor side issue, affecting
clarity and perhaps performance.
*What* is exactly what it does?
My point is this: I can understand what the function actually does,
because I understand C well enough to follow it. What I cannot (yet)
understand is *why* it does what it does.
Do you agree that name "mean_twonums" is misleading?
I'm asking (as others have asked) what is the actual purpose of
this function? Is there some actual reason for computing either
an arithmetic mean, or a geometric mean, or sqrt((x+1)*(y+1))-1,
depending on the values of the arguments? Does this function have
some name in the context of financial calculations?
If you don't want to answer that question, by all means say so
and I'll drop it -- but I can't figure out why you don't want to
answer it.
You're asking for help with your program. Understanding the meaning of
this function would help us do that. Without that, we can't tell
whether the function is correct or not.
--
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-31 17:01 -0500 |
| Message-ID | <9b306fea-3610-63a4-220a-0a97307a681e@verizon.net> |
| In reply to | #102865 |
On 01/31/2017 03:57 PM, Alla _ wrote: ... > I am not one of those marching individuals ) And I am not very fond of > this fairly new concept of naming everyone "she", particularly in Neither am I. > professional context; it looks like an eyesore in all modern professional > literature - everyone has suddenly been addressed as "she", and it > looks and sounds very odd, bizarre and unnatural. It's no more odd, bizarre, or unnatural than calling everyone "he". The only difference is that calling everyone "he" is traditional sexism, whereas calling everyone "she" is more modern reverse sexism.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-02-06 14:38 +0000 |
| Message-ID | <589889d9.16406234@news.xs4all.nl> |
| In reply to | #102884 |
"James R. Kuyper" <jameskuyper@verizon.net> wrote: > On 01/31/2017 03:57 PM, Alla _ wrote: > ... > > I am not one of those marching individuals ) And I am not very fond of > > this fairly new concept of naming everyone "she", particularly in > > Neither am I. > > > professional context; it looks like an eyesore in all modern professional > > literature - everyone has suddenly been addressed as "she", and it > > looks and sounds very odd, bizarre and unnatural. > > It's no more odd, bizarre, or unnatural than calling everyone "he". The > only difference is that calling everyone "he" is traditional sexism, > whereas calling everyone "she" is more modern reverse sexism. In fact, there was a time when calling everyone "he" wasn't sexism at all. Granted, that's back in the Late Old or Early Middle English, when the pronunciation of "heo" had merged with "he" and "seo" hadn't been invented yet, but during that period of English, everybody simply _was_ called "he". (And yes, that means that the word "she" is at least several centuries younger than "he". If you want equality, stop asking for the application of "she" - ask for its re-abolition!) Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-30 10:09 -0800 |
| Message-ID | <0c257fc8-2532-496b-a9cd-94f7d337e8fe@googlegroups.com> |
| In reply to | #102762 |
On Monday, January 30, 2017 at 4:48:17 PM UTC, James R. Kuyper wrote: > On 01/29/2017 04:55 PM, Ben Bacarisse wrote: > > When Ben is talking about "the usual functions", there's a reason why > the are, in fact, "usual". There are kinds of data where it would make > sense to call arith_mean(a,b); there's other kinds of data where it > would make sense to call geom_mean(a,b); there's other kinds of data > where it would make sense to call mean_of_changes(a,b). The key point is > that which one you should call depends upon the meaning of the data - it > doesn't depend upon the values. > > Your function switches which calculation it performs based upon the > values of the numbers, which makes no sense. It should only depend upon > the meaning of those numbers. If it makes sense to call arith_mean(a,b) > for some values of a and b, it does not make sense to call > geom_mean(a,b) when those numbers have different values. > > Your function is symmetrical, which implies that number1 and number2 > have the same type of meaning. If so, it doesn't make sense to ever call > geom_mean(a+1, b) or geom_mean(a, b+1): those function calls make sense > only if a and b have very different meanings. > As a programmer, I would query a function which applied different operations depending on the values of the input, except obviously a piecewise approximation function of a non-tractable curve. But at the end of the day, it's Alla's program. If that's the correct behaviour specified, that's the behaviour to implement.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-30 10:24 -0800 |
| Message-ID | <5715eda9-c0a5-4bb8-ad0e-198c03fd8f94@googlegroups.com> |
| In reply to | #102770 |
On Monday, January 30, 2017 at 9:09:19 PM UTC+3, Malcolm McLean wrote: > On Monday, January 30, 2017 at 4:48:17 PM UTC, James R. Kuyper wrote: > > On 01/29/2017 04:55 PM, Ben Bacarisse wrote: > > > > When Ben is talking about "the usual functions", there's a reason why > > the are, in fact, "usual". There are kinds of data where it would make > > sense to call arith_mean(a,b); there's other kinds of data where it > > would make sense to call geom_mean(a,b); there's other kinds of data > > where it would make sense to call mean_of_changes(a,b). The key point is > > that which one you should call depends upon the meaning of the data - it > > doesn't depend upon the values. > > > > Your function switches which calculation it performs based upon the > > values of the numbers, which makes no sense. It should only depend upon > > the meaning of those numbers. If it makes sense to call arith_mean(a,b) > > for some values of a and b, it does not make sense to call > > geom_mean(a,b) when those numbers have different values. > > > > Your function is symmetrical, which implies that number1 and number2 > > have the same type of meaning. If so, it doesn't make sense to ever call > > geom_mean(a+1, b) or geom_mean(a, b+1): those function calls make sense > > only if a and b have very different meanings. > > > As a programmer, I would query a function which applied different operations > depending on the values of the input, except obviously a piecewise approximation > function of a non-tractable curve. Yes, I understand it. Ben has repeatedly told me that too. I am doing my best to correct what I can. > But at the end of the day, it's Alla's program. If that's the correct behaviour > specified, that's the behaviour to implement.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 01:48 -0800 |
| Message-ID | <73152dd7-f9b8-436e-9720-8daa8c5dc000@googlegroups.com> |
| In reply to | #102655 |
On Saturday, January 28, 2017 at 10:53:07 PM UTC+3, James Kuyper wrote: > On 01/28/2017 01:38 PM, Alla _ wrote: > > On Saturday, January 28, 2017 at 6:46:04 PM UTC+3, James R. Kuyper wrote: > >> On 01/28/2017 06:43 AM, Alla _ wrote: > The context of this thread implies that you're looking at 1-year growth > factors for various quantities, and calculating fractional 1-year growth > rate as > > this_year/last_year - 1.0 > > or equivalently > > (this_year - last_year)/last_year. No, this is not what I am computing here. I am computing rates for depreciation and interest rate, not growth rates, rather ratios of corresponding expenses. <snip>
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-29 11:07 -0500 |
| Message-ID | <aa2fc0d7-cd2e-6b05-d92f-33f7d4902407@verizon.net> |
| In reply to | #102674 |
On 01/29/2017 04:48 AM, Alla _ wrote:
> On Saturday, January 28, 2017 at 10:53:07 PM UTC+3, James Kuyper wrote:
>> On 01/28/2017 01:38 PM, Alla _ wrote:
>>> On Saturday, January 28, 2017 at 6:46:04 PM UTC+3, James R. Kuyper wrote:
>>>> On 01/28/2017 06:43 AM, Alla _ wrote:
>
>> The context of this thread implies that you're looking at 1-year growth
>> factors for various quantities, and calculating fractional 1-year growth
>> rate as
>>
>> this_year/last_year - 1.0
>>
>> or equivalently
>>
>> (this_year - last_year)/last_year.
> No, this is not what I am computing here.
> I am computing rates for depreciation and interest rate, not growth
> rates, rather ratios of corresponding expenses.
> <snip>
Interest rates are fractional growth rates. Consider a savings account
with a variable interest rate. For simplicity, assume that the interest
is compounded annually. Let the balance in the account at the start of
the i'th year be balance[i]. Let the percent interest rate during that
year be pct_interest[i]. Then the corresponding fractional interest rate
is given by
frac_interest[i] = pct_interest[i]/100.0;
If, during a given period of time, we make no deposits and no
withdrawals from this account, then
balance[i+1] == balance[i]*(1.0+frac_interest[i]);
The corresponding growth factor is then
(balance[i+1]/balance[i]) == 1.0+frac_interest[i];
If you do make deposits and withdrawals, that relationship is no longer
true, and the left-hand side of the comparison doesn't have any simple
meaning. However, even in that case 1.0+frac_interest[i] is still a
meaningful growth factor to calculate - it's the factor describing the
growth that would have occurred due to earned interest, if there hadn't
been anything else affecting the account balance. It also makes sense to
take the geometric mean of the values of 1.0+frac_interest[i] over a
period of N years; the result is the constant growth factor that would
have given you the same final balance after N years from the same
initial investment (without deposits or withdrawals) as the actual
interest rates would have.
The same exact math applies to a line of credit with a variable interest
rate - which isn't too surprising: from your point of view, that line of
credit is a debt, but from the bank's point of view, that same account
is an investment the bank has made in you.
Depreciation rates are simply negative growth rates, and it can make
sense to calculate the geometric mean of (1.0 +
fractional_depreciation[i]) for precisely the same reasons that it can
make sense to calculate the geometric mean of positive growth rates.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 01:52 -0800 |
| Message-ID | <2c4fbd3a-2a42-4783-b7c0-a8796dfd38be@googlegroups.com> |
| In reply to | #102655 |
On Saturday, January 28, 2017 at 10:53:07 PM UTC+3, James Kuyper wrote: > On 01/28/2017 01:38 PM, Alla _ wrote: > > On Saturday, January 28, 2017 at 6:46:04 PM UTC+3, James R. Kuyper wrote: > >> On 01/28/2017 06:43 AM, Alla _ wrote: <snip> > > The context of this thread implies that you're looking at 1-year growth > factors for various quantities, and calculating fractional 1-year growth > rate as > > this_year/last_year - 1.0 > > or equivalently > > (this_year - last_year)/last_year. > > With that definition, the growth factor can never be negative if you're > looking at a quantity that can't be negative. I apologize for replying fractionally, not in one message. You lost me here. This is an incorrect statement, or I don't understand what you mean by saying that the above rate cannot be negative. (2-3)/3? But truly this is not C, and I am sure that these types of discussions are not welcome here - people have been complaining. Though I truly like to read your thoughts on all this. <snip>
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-29 11:25 -0500 |
| Message-ID | <338448ec-1b77-c707-e558-db9ed76f5d33@verizon.net> |
| In reply to | #102675 |
On 01/29/2017 04:52 AM, Alla _ wrote: > On Saturday, January 28, 2017 at 10:53:07 PM UTC+3, James Kuyper wrote: >> On 01/28/2017 01:38 PM, Alla _ wrote: >>> On Saturday, January 28, 2017 at 6:46:04 PM UTC+3, James R. Kuyper wrote: >>>> On 01/28/2017 06:43 AM, Alla _ wrote: > <snip> >> >> The context of this thread implies that you're looking at 1-year growth >> factors for various quantities, and calculating fractional 1-year growth >> rate as >> >> this_year/last_year - 1.0 >> >> or equivalently >> >> (this_year - last_year)/last_year. >> >> With that definition, the growth factor can never be negative if you're >> looking at a quantity that can't be negative. > I apologize for replying fractionally, not in one message. > You lost me here. This is an incorrect statement, or I don't understand > what you mean by saying that the above rate cannot be negative. > (2-3)/3? I said that the growth factor can't be negative The growth factor is this_year/last_year, or 2/3 in your example, so it's not negative. What you're calculating above is the fractional growth rate (2-3)/3 = -1/3. That will be negative anytime there is shrinkage rather than growth. However, if the basic numbers are guaranteed to be positive, the growth factor cannot be negative, from which it follows that the fractional growth rate can't be <=-1.0.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-02-04 13:26 -0500 |
| Message-ID | <1ad4355d-8f1d-2290-a950-8d48ac9be8b3@verizon.net> |
| In reply to | #102655 |
On 01/28/2017 02:52 PM, James R. Kuyper wrote: ... > Why not? The geometric mean of numbers, some of which are negative, is > perfectly well defined: the formula (a1*a2*...*aN)^(1/N) doesn't care > whether a2 is negative. If the number of negative values is odd, the > result is imaginary ... I was writing about the general case, but thinking about the specific case where N=2. If the number of values that are negative is odd, the product will be negative. If N is even, that means that the geometric mean cannot be a pure-real number. Otherwise, there's always at least one real root.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-28 15:08 -0500 |
| Message-ID | <1325a2f1-78e2-8769-7951-471675806a24@verizon.net> |
| In reply to | #102640 |
On 01/28/2017 10:45 AM, James R. Kuyper wrote: > On 01/28/2017 06:43 AM, Alla _ wrote: >> On Saturday, January 28, 2017 at 2:42:29 AM UTC+3, Ben Bacarisse wrote: >>> Alla _ <modelling.data@gmail.com> writes: >>> >>>> On Friday, January 27, 2017 at 7:44:33 PM UTC+3, Ben Bacarisse wrote: >>>>> Alla _ <modelling.data@gmail.com> writes: > ... >>>>>> if(fabs(number1) < 1 && fabs(number1) > 0) >>>>>> number1 += 1.0; >>>>>> if(fabs(number2) < 1 && fabs(number2) > 0) >>>>>> number2 += 1.0; >>>>>> return pow((number1*number2), 1.0/2); I forgot that you were using fabs() in the above comparisons. I'll make the corresponding corrections below: > If both arguments to your function are <=0.0, or if both are >=1.0, then SB: If both arguments to your function are 0, or both have a magnitude >=1.0 > what it calculates is the geometric mean of those numbers. If number1 > and number2 are both >0.0 and <1.0, what it calculates is the geometric SB: ... are both non-zero and between -1.0 and 1.0 ... > mean of 1.0+number1 and 1.0+number2, which is something quite different > from the geometric mean of number1 and number2. If one of the numbers is > <=0.0, and the other is not, what you calculate is a domain error. > Otherwise, if only one of the numbers is >=1.0, there's no simple > standard name for the function you're calculating. ... > Because your program changes how it calculates it's result, depending > upon the values of the numbers, it has discontinuities at number1==0, > number1==1, number2==0, and number2==1: There are also discontinuities at number1==-1.0 and number2==-1.0. Also, the discontinuities at 0 are much worse than I thought: if number1 is a very tiny positive number OR a very tiny negative number, the same formula is used in both cases, and very similar values will be returned by your function. However, if number1 is exactly 0.0, a very different formula is used, which will result in returning a value of exactly 0.0. The same is true for number2.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 01:20 -0800 |
| Message-ID | <67090342-32d4-4b06-a67c-daab4279f223@googlegroups.com> |
| In reply to | #102640 |
On Saturday, January 28, 2017 at 6:46:04 PM UTC+3, James Kuyper wrote:
> On 01/28/2017 06:43 AM, Alla _ wrote:
<snip>
> If your function were intended to only be applied to numbers between 0
> and 1, it would make more sense. But you do nothing to reject values
> outside of those ranges, and what it calculates outside of those ranges
> is quite different. And you said above that it was intended to work with
> negative numbers.
I have corrected this function a bit:
double mean_twonums(double number1, double number2)
{
if(number1 < 0 || number2 < 0)
return (number1+number2)/2;
if( (fabs(number1) < 1 && fabs(number1) > 0)
&& (fabs(number2) < 1 && fabs(number2) > 0) )
{
number1 += 1.0;
number2 += 1.0;
return pow((number1*number2), 1.0/2) - 1;
}
return pow((number1*number2), 1.0/2);
}
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-29 11:17 -0500 |
| Message-ID | <dfe9581d-c3e3-e8c9-9698-1cc97c3f9a03@verizon.net> |
| In reply to | #102671 |
On 01/29/2017 04:20 AM, Alla _ wrote:
> On Saturday, January 28, 2017 at 6:46:04 PM UTC+3, James Kuyper wrote:
>> On 01/28/2017 06:43 AM, Alla _ wrote:
> <snip>
>> If your function were intended to only be applied to numbers between 0
>> and 1, it would make more sense. But you do nothing to reject values
>> outside of those ranges, and what it calculates outside of those ranges
>> is quite different. And you said above that it was intended to work with
>> negative numbers.
> I have corrected this function a bit:
> double mean_twonums(double number1, double number2)
> {
> if(number1 < 0 || number2 < 0)
> return (number1+number2)/2;
>
> if( (fabs(number1) < 1 && fabs(number1) > 0)
> && (fabs(number2) < 1 && fabs(number2) > 0) )
> {
> number1 += 1.0;
> number2 += 1.0;
>
> return pow((number1*number2), 1.0/2) - 1;
> }
> return pow((number1*number2), 1.0/2);
> }
>
So, sometimes mean_twonums calculates the arithmetic mean of number1 and
number2, sometimes it calculates the geometric mean of number1 and
number2, and sometimes it calculates the geometric mean of (1.0+number1)
and (1.0+number2). That's a smaller variety of different calculations
than you had in your previous version, but I still can't imagine any
context in which it would make sense to change what the function
calculates in that manner. Your previous citation of a web page
describing the geometric mean make no mention of changing the value
computed in that fashion.
Note, in particular, that mean_twonums(-FLT_EPSILON, x), mean_twonums(0,
x) and mean_twonums(FLT_EPSILON, x), are three very different functions
of x. The values -FLT_EPSILON, 0 and FLT_EPSILON are all every close to
each other - it doesn't make sense for the function to have such widely
different behavior in those three cases.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-29 08:42 -0800 |
| Message-ID | <156s8chg0klt04rua4jg7p6u6hflmv1qar@4ax.com> |
| In reply to | #102671 |
On Sun, 29 Jan 2017 01:20:55 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>I have corrected this function a bit:
>double mean_twonums(double number1, double number2)
>{
> if(number1 < 0 || number2 < 0)
> return (number1+number2)/2;
>
> if( (fabs(number1) < 1 && fabs(number1) > 0)
> && (fabs(number2) < 1 && fabs(number2) > 0) )
WHY are you calling fabs???
This statement cannot be reached if either number is negative. The
expression fabs(number1) must always evaluate to number1. Similarly
for number2.
> {
> number1 += 1.0;
> number2 += 1.0;
>
> return pow((number1*number2), 1.0/2) - 1;
Is there some reason you chose the more complex pow function over the
simpler sqrt function? Not only will it consume more processing but
it needlessly obfuscates the code for a reader.
> }
> return pow((number1*number2), 1.0/2);
>}
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
Page 7 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