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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-28 14:52 -0500 |
| Message-ID | <43aa17b1-6286-8ec5-c9d7-fe59d88c1688@verizon.net> |
| In reply to | #102650 |
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:
>>> 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:
...
>> The geometric mean of -1 and 9 is csqrt(-1*9) = csqrt(-9) = 3*I. Your
>> function calculates sqrt(-1*9) = sqrt(-9) which is a domain error -
>> again, it does nothing to prevent or detect the domain error.
> No no, you can't use this standard geo mean formula for negative
> numbers, which are not in the range between zero and one.
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 - but under precisely those circumstances, there is
no real value that matches the input data. If any meaning can be
attached to an imaginary value (which is more common in the sciences
than in economics), that meaning is probably correct. Otherwise, either
the data is wrong, or the model that calls for you to calculate the
geometric mean is wrong.
>> The geometric mean of 1.0/3.0 and 3.0 is sqrt(1.0/3.0 * 3.0) = sqrt(1) =
>> 1. Your routine calculates pow((1+1.0/3.0)*3, 0.5) = pow(4, 0.5) = 2.
>>
> I have to look into this. This is bad, and I have completely missed
> this case. I have to changed my if condition, so this formula is used
> only when both numbers are between 0 and 1.
I think that's the wrong fix. See below.
>> 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: it calculates something very
>> different on one side of each discontinuity than it does on the other
>> side. For example:
>>
>> When number1==0.5 and number2 = 0.99, your function calculates
>>
>> pow(1.5*1.99, 0.5) = pow(2.985, 0.5) = 1.73.
>>
>> When number1=0.5 and number2==1.0, your function calculates
>>
>> pow(1.5*1.0, 0.5) = pow(1.5, 0.5) = 1.22
>>
>> 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.
> Yes, this is a flaw; I have answered above. As to negatives, I was referring
> to those between 1 and 0, for example x = -0.3, y = 0.6, hence pow(0.7*1.6, 0.5),
> eliminates the negative number.
But -0.3 is NOT between 1.0 and 0.0, it's smaller than both of those
numbers. It is between -1.0 and 0.0. If you want to test for that case,
you need to express the test in terms of -1.0, not 1.0.
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. Therefore, the fractional
growth rate can't be less than -1.0. However, before imposing that as a
validity test, make very sure that none of the quantities you're
applying it to can be negative. The cash on hand can't be negative, for
example (if you owe someone money, that's a liability, and it might make
your net worth negative, but it's not actual negative cash). Similarly,
the count of washing machines in your inventory can't be negative. As
mentioned above, the net worth of a company can be and is legally
mandatorynegative (though that's not likely to remain true for very long
without going bankrupt). Also, if your inventory becomes unsalable due
to revelations that it's made of toxic materials, and you are legally
required to safely dispose of those toxic materials, and doing so will
cost a lot of money, then the value of your inventory could be negative,
even if the inventory count is positive.
However, even looking at the growth rate of inherently positive
quantities, there's no mathematical reason they couldn't grow to more
than double their original value in one year, in which case the
fractional growth rate could be greater than 1.0. There might be an
economic reason why it can't happen, but such growth raters do
occasionally come up in microeconomics (the economics of single
companies), so your code should be prepared to deal with them correctly.
Therefore, it doesn't make sense to treat 1-year growth rate values
greater than 1.0 any differently than values less than or equal to 1.0.
Such rates are far less common in macro-economics, because the extremes
get averaged out when considering the entire economy.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-28 19:00 -0800 |
| Message-ID | <lnmveabmfh.fsf@kst-u.example.com> |
| In reply to | #102655 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 01/28/2017 01:38 PM, Alla _ wrote:
[...]
>> No no, you can't use this standard geo mean formula for negative
>> numbers, which are not in the range between zero and one.
>
> 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 - but under precisely those circumstances, there is
> no real value that matches the input data. If any meaning can be
> attached to an imaginary value (which is more common in the sciences
> than in economics), that meaning is probably correct. Otherwise, either
> the data is wrong, or the model that calls for you to calculate the
> geometric mean is wrong.
True, but I suspect that in this context *any* negative values
would be an error. For example, if you have (2, -3, 4, -5, 6),
the geometric mean is approximately 3.73 (the same as the geometric
mean of (2, 3, 4, 5, 6) -- but the presence of negative data likely
indicates an error whether the number of negative values is even
or odd.
If your input data doesn't make sense in context, you should check
and report the error before trying to compute a result.
--
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 Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-28 22:54 -0500 |
| Message-ID | <o6jova$mu2$1@dont-email.me> |
| In reply to | #102665 |
On 01/28/2017 10:00 PM, Keith Thompson wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: >> On 01/28/2017 01:38 PM, Alla _ wrote: > [...] >>> No no, you can't use this standard geo mean formula for negative >>> numbers, which are not in the range between zero and one. >> >> 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 - but under precisely those circumstances, there is >> no real value that matches the input data. If any meaning can be >> attached to an imaginary value (which is more common in the sciences >> than in economics), that meaning is probably correct. Otherwise, either >> the data is wrong, or the model that calls for you to calculate the >> geometric mean is wrong. > > True, but I suspect that in this context *any* negative values > would be an error. For example, if you have (2, -3, 4, -5, 6), > the geometric mean is approximately 3.73 (the same as the geometric > mean of (2, 3, 4, 5, 6) -- but the presence of negative data likely > indicates an error whether the number of negative values is even > or odd. Agree - if applied to financial data which includes valid negative values, the model implied by taking the geometric mean of the growth factors is unlikely to be a valid one.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 01:33 -0800 |
| Message-ID | <98f99449-1a1b-4311-a080-26563ddcff32@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: <snip> > > >> 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: it calculates something very > >> different on one side of each discontinuity than it does on the other > >> side. For example: > >> > >> When number1==0.5 and number2 = 0.99, your function calculates > >> > >> pow(1.5*1.99, 0.5) = pow(2.985, 0.5) = 1.73. > >> > >> When number1=0.5 and number2==1.0, your function calculates > >> > >> pow(1.5*1.0, 0.5) = pow(1.5, 0.5) = 1.22 > >> > >> 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. > > Yes, this is a flaw; I have answered above. As to negatives, I was referring > > to those between 1 and 0, for example x = -0.3, y = 0.6, hence pow(0.7*1.6, 0.5), > > eliminates the negative number. > > But -0.3 is NOT between 1.0 and 0.0, it's smaller than both of those > numbers. It is between -1.0 and 0.0. If you want to test for that case, > you need to express the test in terms of -1.0, not 1.0. James, I do see that almost everyone here assumes "by default" that I am the silliest thing on our planet just because I am not always attentive, don't have time to work on learning the coding in a way the majority thinks correct, therefore do not *yet* know enough about CS and programming in particular, have no math background (no official college math degree), the list can go on and on. I am all right with such an attitude, it is sometimes fair. But it does bring about such paragraphs as above, and I am also a human being and can get beside myself too )))))) Though always with a smile ))) Please, take a look at the code - I use absolute values, which means that -0.3 taking as an abs value *is* in the range between 0 and 1. > <snip>
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-29 10:37 -0500 |
| Message-ID | <b136ac33-274e-76e6-ac09-63f30eba4951@verizon.net> |
| In reply to | #102672 |
On 01/29/2017 04:33 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: ... >>> Yes, this is a flaw; I have answered above. As to negatives, I was referring >>> to those between 1 and 0, for example x = -0.3, y = 0.6, hence pow(0.7*1.6, 0.5), >>> eliminates the negative number. >> >> But -0.3 is NOT between 1.0 and 0.0, it's smaller than both of those >> numbers. It is between -1.0 and 0.0. If you want to test for that case, >> you need to express the test in terms of -1.0, not 1.0. > > James, I do see that almost everyone here assumes "by default" > that I am the silliest thing on our planet just because I am not always attentive, > don't have time to work on learning the coding in a way the majority > thinks correct, therefore do not *yet* know enough about CS and programming > in particular, have no math background (no official college math degree), > the list can go on and on. I am all right with such an attitude, it is sometimes > fair. But it does bring about such paragraphs as above, and I am also a human > being and can get beside myself too )))))) Though always with a smile ))) I don't think you are the silliest thing on our planet - I've seen much sillier (my own twins, for instance, when they're in a good mood). I do, however, believe that you have a lot of bad attitudes and bad habits that have made it harder for you to learn C as fast or as well as you should be able to. The most important of those bad habits is not taking enough time to understand the basics of what you're trying to do, before going on to more complicated things. But that isn't an assumption - it's a deduction based upon a large quantity of relevant evidence that you yourself have presented to us. > Please, take a look at the code - I use absolute values, which means > that -0.3 taking as an abs value *is* in the range between 0 and 1. Yes. The fundamental problem with your function is that it changes whether or not it adds 1.0 to each argument, based upon the value of that argument. In my haste to explain why that indicates that your function can't be correct, I overlooked the fact that you were using fabs(). This was not due to me thinking you were too stupid to use fabs(), it was simple carelessness on my part. Using fabs() actually makes the problem worse: it adds another discontinuity at number1==-1.0, and makes the discontinuity at number1==0 double-sided. I'm frequently guilty of carelessness, and as a result, I've developed a large collection of heuristic techniques I can use to identify possible mistakes. One of those heuristics is that mathematical functions which are discontinuous are seldom correct, and your function is a prime example of this. There are exceptions to that rule. For example, single US citizens with a taxable income between $49,950.00 and $49,599.99 in 2016 should pay $8,265 in federal income taxes; if it was between $50,000.00 and $50,049.99, they should pay $8,278. The income tax tables are used to compute a function that is discontinuous at $50,000. However, that function is a piece-wise constant approximation to a smooth curve, to make it easier for taxpayers who aren't particularly mathematically competent to prepare their own tax returns (other parts of the tax calculation implement piece-wise linear approximations to a smooth curve, so I don't think they succeeded - but that's what they were trying to do). Your function has no such justification.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-29 15:57 +0000 |
| Message-ID | <87wpddrh8y.fsf@bsb.me.uk> |
| In reply to | #102698 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: > On 01/29/2017 04:33 AM, Alla _ wrote: <snip> >> Please, take a look at the code - I use absolute values, which means >> that -0.3 taking as an abs value *is* in the range between 0 and 1. In the function I saw, when one of the parameters is negative you don't use the absolute value, you return the arithmetic mean. > Yes. The fundamental problem with your function is that it changes > whether or not it adds 1.0 to each argument, based upon the value of > that argument. In my haste to explain why that indicates that your > function can't be correct, I overlooked the fact that you were using > fabs(). I suspect you are looking at a part of the function. The fabs calls are redundant because of a prior test. I tried to point Alla _ in this direction but I think the hint got lost in the discussion. The function computes one of: (a+b)/2 sqrt((a+1)*b) sqrt(a*(b+1)) sqrt((a+1)*(b+1)) sqrt(a*b) The arithmetic mean is used if either number is negative. It's possible the intent is to return sqrt((a+1)*(b+1))-1 in some cases but the code did not do that (growth of 10% is growth by a factor of 1.1). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 09:19 -0800 |
| Message-ID | <556a0195-6a9c-4a43-bd0f-bfdbd3333f74@googlegroups.com> |
| In reply to | #102698 |
On Sunday, January 29, 2017 at 6:38:01 PM UTC+3, James R. Kuyper wrote: > On 01/29/2017 04:33 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: > ... > >>> Yes, this is a flaw; I have answered above. As to negatives, I was referring > >>> to those between 1 and 0, for example x = -0.3, y = 0.6, hence pow(0.7*1.6, 0.5), > >>> eliminates the negative number. > >> > >> But -0.3 is NOT between 1.0 and 0.0, it's smaller than both of those > >> numbers. It is between -1.0 and 0.0. If you want to test for that case, > >> you need to express the test in terms of -1.0, not 1.0. > > > > James, I do see that almost everyone here assumes "by default" > > that I am the silliest thing on our planet just because I am not always attentive, > > don't have time to work on learning the coding in a way the majority > > thinks correct, therefore do not *yet* know enough about CS and programming > > in particular, have no math background (no official college math degree), > > the list can go on and on. I am all right with such an attitude, it is sometimes > > fair. But it does bring about such paragraphs as above, and I am also a human > > being and can get beside myself too )))))) Though always with a smile ))) > > I don't think you are the silliest thing on our planet - I've seen much > sillier (my own twins, for instance, when they're in a good mood). I do, > however, believe that you have a lot of bad attitudes and bad habits > that have made it harder for you to learn C as fast or as well as you > should be able to. The most important of those bad habits is not taking > enough time to understand the basics of what you're trying to do, before > going on to more complicated things. But that isn't an assumption - it's > a deduction based upon a large quantity of relevant evidence that you > yourself have presented to us. Can't agree more with this, and I understand this, and do that with a clear intent. I have many times stated that when I started the course I never thought I would be so involved and so attracted to programming, because I was so much far away from anything related to CS. I have taken this introductory CS course following a very specific and clear goal. But, as so many people during decades of this course's existence (thought the majority were those lucky fellows in their college age, but now I see lots of grown-ups as well; one guy who has finished the course together with some other education and got a real programming job at some good company is 56; though I guess he had some technical background in the past, unlike me), I was so much fascinated with the subject and especially with C - it's the only language I have seen thus far that completely coincides with my attitude towards lots of problems and ways in doing things. I know that I will have to learn the basics and the learn the language properly if I want to move anywhere closer to professional programming ) > > > Please, take a look at the code - I use absolute values, which means > > that -0.3 taking as an abs value *is* in the range between 0 and 1. > > Yes. The fundamental problem with your function is that it changes > whether or not it adds 1.0 to each argument, based upon the value of > that argument. In my haste to explain why that indicates that your > function can't be correct, I overlooked the fact that you were using > fabs(). This was not due to me thinking you were too stupid to use > fabs(), it was simple carelessness on my part. Using fabs() actually > makes the problem worse: it adds another discontinuity at number1==-1.0, > and makes the discontinuity at number1==0 double-sided. > > I'm frequently guilty of carelessness, and as a result, I've developed a > large collection of heuristic techniques I can use to identify possible > mistakes. One of those heuristics is that mathematical functions which > are discontinuous are seldom correct, and your function is a prime > example of this. > There are exceptions to that rule. For example, single US citizens with > a taxable income between $49,950.00 and $49,599.99 in 2016 should pay > $8,265 in federal income taxes; if it was between $50,000.00 and > $50,049.99, they should pay $8,278. The income tax tables are used to > compute a function that is discontinuous at $50,000. However, that > function is a piece-wise constant approximation to a smooth curve, to > make it easier for taxpayers who aren't particularly mathematically > competent to prepare their own tax returns (other parts of the tax > calculation implement piece-wise linear approximations to a smooth > curve, so I don't think they succeeded - but that's what they were > trying to do). Your function has no such justification.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-01-29 11:49 -0800 |
| Message-ID | <6425a2a6-273a-421a-98de-a618de43707e@googlegroups.com> |
| In reply to | #102709 |
W dniu niedziela, 29 stycznia 2017 18:19:38 UTC+1 użytkownik Alla _ napisał: > On Sunday, January 29, 2017 at 6:38:01 PM UTC+3, James R. Kuyper wrote: > > On 01/29/2017 04:33 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: > > ... > > >>> Yes, this is a flaw; I have answered above. As to negatives, I was referring > > >>> to those between 1 and 0, for example x = -0.3, y = 0.6, hence pow(0.7*1.6, 0.5), > > >>> eliminates the negative number. > > >> > > >> But -0.3 is NOT between 1.0 and 0.0, it's smaller than both of those > > >> numbers. It is between -1.0 and 0.0. If you want to test for that case, > > >> you need to express the test in terms of -1.0, not 1.0. > > > > > > James, I do see that almost everyone here assumes "by default" > > > that I am the silliest thing on our planet just because I am not always attentive, > > > don't have time to work on learning the coding in a way the majority > > > thinks correct, therefore do not *yet* know enough about CS and programming > > > in particular, have no math background (no official college math degree), > > > the list can go on and on. I am all right with such an attitude, it is sometimes > > > fair. But it does bring about such paragraphs as above, and I am also a human > > > being and can get beside myself too )))))) Though always with a smile ))) > > > > I don't think you are the silliest thing on our planet - I've seen much > > sillier (my own twins, for instance, when they're in a good mood). I do, > > however, believe that you have a lot of bad attitudes and bad habits > > that have made it harder for you to learn C as fast or as well as you > > should be able to. The most important of those bad habits is not taking > > enough time to understand the basics of what you're trying to do, before > > going on to more complicated things. But that isn't an assumption - it's > > a deduction based upon a large quantity of relevant evidence that you > > yourself have presented to us. > Can't agree more with this, and I understand this, and do that with a > clear intent. I have many times stated that when I started the course > I never thought I would be so involved and so attracted to programming, > because I was so much far away from anything related to CS. I have > taken this introductory CS course following a very specific and clear > goal. But, as so many people during decades of this course's existence > (thought the majority were those lucky fellows in their college age, > but now I see lots of grown-ups as well; one guy who has finished > the course together with some other education and got a real > programming job at some good company is 56; though I guess > he had some technical background in the past, unlike me), > I was so much fascinated with the subject and especially with C - it's > the only language I have seen thus far that completely coincides with > my attitude towards lots of problems and ways in doing things. I know > that I will have to learn the basics and the learn the language properly > if I want to move anywhere closer to professional programming ) > > > > > Please, take a look at the code - I use absolute values, which means > > > that -0.3 taking as an abs value *is* in the range between 0 and 1. > > > > Yes. The fundamental problem with your function is that it changes > > whether or not it adds 1.0 to each argument, based upon the value of > > that argument. In my haste to explain why that indicates that your > > function can't be correct, I overlooked the fact that you were using > > fabs(). This was not due to me thinking you were too stupid to use > > fabs(), it was simple carelessness on my part. Using fabs() actually > > makes the problem worse: it adds another discontinuity at number1==-1.0, > > and makes the discontinuity at number1==0 double-sided. > > > > I'm frequently guilty of carelessness, and as a result, I've developed a > > large collection of heuristic techniques I can use to identify possible > > mistakes. One of those heuristics is that mathematical functions which > > are discontinuous are seldom correct, and your function is a prime > > example of this. > > There are exceptions to that rule. For example, single US citizens with > > a taxable income between $49,950.00 and $49,599.99 in 2016 should pay > > $8,265 in federal income taxes; if it was between $50,000.00 and > > $50,049.99, they should pay $8,278. The income tax tables are used to > > compute a function that is discontinuous at $50,000. However, that > > function is a piece-wise constant approximation to a smooth curve, to > > make it easier for taxpayers who aren't particularly mathematically > > competent to prepare their own tax returns (other parts of the tax > > calculation implement piece-wise linear approximations to a smooth > > curve, so I don't think they succeeded - but that's what they were > > trying to do). Your function has no such justification. why c? c is usually liked by fellows who like controll and optimisation (its 'transparent' loook over the wires and sillicone) (some that likes optimisation could also use c++ (and some do) but c++ not offers as much transparency or at least simplicity)
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 01:40 -0800 |
| Message-ID | <39f310e9-691c-4a27-9d9f-bc9114854af8@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: > >>> 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: > ... > >> The geometric mean of -1 and 9 is csqrt(-1*9) = csqrt(-9) = 3*I. Your > >> function calculates sqrt(-1*9) = sqrt(-9) which is a domain error - > >> again, it does nothing to prevent or detect the domain error. > > No no, you can't use this standard geo mean formula for negative > > numbers, which are not in the range between zero and one. > > 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. No, it is not recommended to use geo mean on a set of negative numbers, and on a mixture of positives and negatives, where the number of negatives is even. <snip>
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-29 10:48 -0500 |
| Message-ID | <816ac4fc-3e93-cd1b-e4b9-ce0eac72da7e@verizon.net> |
| In reply to | #102673 |
On 01/29/2017 04:40 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: ... >>>> The geometric mean of -1 and 9 is csqrt(-1*9) = csqrt(-9) = 3*I. Your >>>> function calculates sqrt(-1*9) = sqrt(-9) which is a domain error - >>>> again, it does nothing to prevent or detect the domain error. >>> No no, you can't use this standard geo mean formula for negative >>> numbers, which are not in the range between zero and one. >> >> 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. > No, it is not recommended to use geo mean on a set of negative numbers, > and on a mixture of positives and negatives, where the number of negatives > is even. That's correct, but it's not something the a generic geometric-mean function should be worried about. It should simply calculate the geometric mean whenever that value is well-defined, without passing judgement on whether or not it was appropriate to use the geometric mean. It's the caller of the routine that should make such judgements. In the context of your program, using the geometric mean only makes sense if the numbers are sufficiently similar; if (1.0+number1) is negative, while (1.0+number2) is positive, they're probably not sufficiently similar. In a more sophisticated model, you'd be doing a curve fitting, and the fitting routine should calculate some measure of the goodness of the fit, and such data is unlikely to be a good fit to the model. But that's too sophisticated for this program; a simple validity check on the input values would be more appropriate. The key point is that your routine does NOT reject values that are outside the range it's intended to be used for; it simply calculates a significantly different function for such data, and that's just bizarre.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 09:59 -0800 |
| Message-ID | <7af44069-dfe1-48ce-8c6e-33aed7131a02@googlegroups.com> |
| In reply to | #102699 |
On Sunday, January 29, 2017 at 6:49:14 PM UTC+3, James R. Kuyper wrote: > On 01/29/2017 04:40 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: > ... > >>>> The geometric mean of -1 and 9 is csqrt(-1*9) = csqrt(-9) = 3*I. Your > >>>> function calculates sqrt(-1*9) = sqrt(-9) which is a domain error - > >>>> again, it does nothing to prevent or detect the domain error. > >>> No no, you can't use this standard geo mean formula for negative > >>> numbers, which are not in the range between zero and one. > >> > >> 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. > > No, it is not recommended to use geo mean on a set of negative numbers, > > and on a mixture of positives and negatives, where the number of negatives > > is even. > > That's correct, but it's not something the a generic geometric-mean > function should be worried about. It should simply calculate the > geometric mean whenever that value is well-defined, without passing > judgement on whether or not it was appropriate to use the geometric > mean. It's the caller of the routine that should make such judgements. > > In the context of your program, using the geometric mean only makes > sense if the numbers are sufficiently similar; if (1.0+number1) is > negative, while (1.0+number2) is positive, they're probably not > sufficiently similar. How can any negative number, whose absolute value is in the range between 1 and 0, be still negative when +1.0 is added to it? This calculate is precisely used to account for negative values. >In a more sophisticated model, you'd be doing a > curve fitting, and the fitting routine should calculate some measure of > the goodness of the fit, and such data is unlikely to be a good fit to > the model. But that's too sophisticated for this program; a simple > validity check on the input values would be more appropriate. > > The key point is that your routine does NOT reject values that are > outside the range it's intended to be used for; it simply calculates a > significantly different function for such data, and that's just bizarre.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-29 13:52 -0500 |
| Message-ID | <54ce71f7-5db5-0d83-c2f6-bc37acf070c1@verizon.net> |
| In reply to | #102711 |
On 01/29/2017 12:59 PM, Alla _ wrote: > On Sunday, January 29, 2017 at 6:49:14 PM UTC+3, James R. Kuyper wrote: ... >> In the context of your program, using the geometric mean only makes >> sense if the numbers are sufficiently similar; if (1.0+number1) is >> negative, while (1.0+number2) is positive, they're probably not >> sufficiently similar. > How can any negative number, whose absolute value is in the range > between 1 and 0, be still negative when +1.0 is added to it? In making that comment, I was agreeing that, in a financial context, it will often (but not necessarily) be that case that you're looking at the growth rates for quantities that are inherently non-negative, and usually positive. In that case, growth factors that aren't positive don't make sense, so fractional growth rates are necessarily greater than -1.0. However, there's no particular reason why fractional growth rates can't be >=1.0; some quantities of financial interest do occasionally more than double in size in a single year. That's not common for macro-economic quantities, but it's more common when looking at the financial operations of a single company - and your variable names give the impression that this is the context of your program.. Your function treats values >=1.0 the same way as values <=1.0, which makes no sense, even in the context of the growth of quantities that are inherently positive. More to the point, your code does NOT reject values that are outside the range that you consider valid, it simply calculates a different function for those cases than it does for the others. I can't come up with any good reason why it should do so. In particular, it does the same thing for values of 0.0 (which should be valid, as far as I can tell) that it does for values <=1.0 or >=1.0 - which makes no sense whatsoever. > This calculate is precisely used to account for negative values. And it does so in a way that has no mathematical or financial justification.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-29 12:48 -0800 |
| Message-ID | <2be1c4a8-64ed-4e33-86fc-00ae8dee873b@googlegroups.com> |
| In reply to | #102719 |
On Sunday, January 29, 2017 at 9:52:50 PM UTC+3, James R. Kuyper wrote: > On 01/29/2017 12:59 PM, Alla _ wrote: > > On Sunday, January 29, 2017 at 6:49:14 PM UTC+3, James R. Kuyper wrote: > ... > >> In the context of your program, using the geometric mean only makes > >> sense if the numbers are sufficiently similar; if (1.0+number1) is > >> negative, while (1.0+number2) is positive, they're probably not > >> sufficiently similar. > > How can any negative number, whose absolute value is in the range > > between 1 and 0, be still negative when +1.0 is added to it? > > In making that comment, I was agreeing that, in a financial context, it > will often (but not necessarily) be that case that you're looking at the > growth rates for quantities that are inherently non-negative, and > usually positive. In that case, growth factors that aren't positive > don't make sense, so fractional growth rates are necessarily greater > than -1.0. > However, there's no particular reason why fractional growth rates can't > be >=1.0; some quantities of financial interest do occasionally more > than double in size in a single year. That's not common for > macro-economic quantities, but it's more common when looking at the > financial operations of a single company - and your variable names give > the impression that this is the context of your program.. Your function > treats values >=1.0 the same way as values <=1.0, which makes no sense, > even in the context of the growth of quantities that are inherently > positive. > > More to the point, your code does NOT reject values that are outside the > range that you consider valid, it simply calculates a different function > for those cases than it does for the others. I can't come up with any > good reason why it should do so. In particular, it does the same thing > for values of 0.0 (which should be valid, as far as I can tell) that it > does for values <=1.0 or >=1.0 - which makes no sense whatsoever. > > > This calculate is precisely used to account for negative values. > > And it does so in a way that has no mathematical or financial justification. Sorry to say that but you are wrong.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-29 16:27 -0500 |
| Message-ID | <5336a413-574b-dbdc-013c-e4e5f8907b0f@verizon.net> |
| In reply to | #102728 |
On 01/29/2017 03:48 PM, Alla _ wrote: > On Sunday, January 29, 2017 at 9:52:50 PM UTC+3, James R. Kuyper wrote: ... >> More to the point, your code does NOT reject values that are outside the >> range that you consider valid, it simply calculates a different function >> for those cases than it does for the others. I can't come up with any >> good reason why it should do so. In particular, it does the same thing >> for values of 0.0 (which should be valid, as far as I can tell) that it >> does for values <=1.0 or >=1.0 - which makes no sense whatsoever. >> >>> This calculate is precisely used to account for negative values. >> >> And it does so in a way that has no mathematical or financial justification. > Sorry to say that but you are wrong. That's not a sufficient answer - if it has justification, you should be able to provide it. At a minimum, cite a text that calls for changing whether or not you add 1.0 to the number, based upon it's value, before multiplying it. The only citation you've provided so far has described what the geometric mean is, and why it's useful in financial calculations, but provides no justification for that feature of your calculations.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-30 04:57 -0800 |
| Message-ID | <5c731498-13a4-4d5e-b962-c104d9e77d6c@googlegroups.com> |
| In reply to | #102731 |
On Monday, January 30, 2017 at 12:28:05 AM UTC+3, James R. Kuyper wrote: > On 01/29/2017 03:48 PM, Alla _ wrote: > > On Sunday, January 29, 2017 at 9:52:50 PM UTC+3, James R. Kuyper wrote: > ... > >> More to the point, your code does NOT reject values that are outside the > >> range that you consider valid, it simply calculates a different function > >> for those cases than it does for the others. I can't come up with any > >> good reason why it should do so. In particular, it does the same thing > >> for values of 0.0 (which should be valid, as far as I can tell) that it > >> does for values <=1.0 or >=1.0 - which makes no sense whatsoever. > >> > >>> This calculate is precisely used to account for negative values. > >> > >> And it does so in a way that has no mathematical or financial justification. > > Sorry to say that but you are wrong. > > That's not a sufficient answer - if it has justification, you should be > able to provide it. At a minimum, cite a text that calls for changing > whether or not you add 1.0 to the number, based upon it's value, before > multiplying it. The only citation you've provided so far has described > what the geometric mean is, and why it's useful in financial > calculations, but provides no justification for that feature of your > calculations. With all respect I would like to opt out from this discussion because I consider it fruitless to both of us - we both talk about something related to our cases. If you have ever created pro forma statements and have exact examples of data in spreadsheets will such computations, than it could be very interesting to see, and to continue this discussion (and definitely not here). At the moment, as I said, it is fruitless because you are referring to something you are thinking about, to some abstract math ideas, even if you apply them to some examples of basic compound interest computations. I made a mistake most likely when I wrote a phrase "interest rate" instead of "interest expense", which has led to you showing pretty basic examples, not referred to what I am computing. You are not basing your examples on my data, and even not on some financial statements, i.e. income statements and balance sheet data, which I take as basis for my computation. Therefore, not being a math professor, at the moment I am interested only in applicable computations based on concrete data, say from K-10 reports, and not on discussing math issues. I do hope to have an opportunity to learn math much more thoroughly and sometime to be able to indulge in truly interesting discussions on math issues.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-30 12:26 -0500 |
| Message-ID | <d24e080e-9fd2-fdec-a4b0-2194a928393d@verizon.net> |
| In reply to | #102747 |
On 01/30/2017 07:57 AM, Alla _ wrote: ... > With all respect I would like to opt out from this discussion because I consider > it fruitless to both of us - we both talk about something related > to our cases. If you have ever created pro forma statements and have > exact examples of data in spreadsheets will such computations, than > it could be very interesting to see, and to continue this discussion > (and definitely not here). I make no claim to being an expert in accounting. However, neither am I ignorant of the subject. I learned the basics of accounting many years ago because my instructors thought I might end up using my computing skills in financial contexts, which is not how my career actually turned out. I used those basics while doing my own personal bookkeeping. At one time, my wife was considering changing her career to accounting. She took a different accounting class every semester for several years, including summer sessions I and II. Because English is not her native language, she came to me for help. I would spend 10-15 minutes reading and easily understanding each chapter, and then spend the next several hours explaining what I had just learned to her. Unless you have at least a certificate of some kind in accounting, please don't automatically assume that I'm ignorant of any particular aspect of accounting that you're well aware of. The problem with your function has nothing to do with accounting principles. Accounting involves some very weird processes that can be difficult to justify mathematically, such as the way double-declining balance depreciation is calculated. But whenever that's the case, there's very specific rules describing what you're supposed to do (in the case of double-declining balance depreciation, those rules are embedded in US tax law, as well as the rules of several different international accounting authorities). If there were any such rules justifying the bizarre features of your function, you could have cited them, and I'm fairly certain I would have understood those rules, and might even have been able to understand why they were written that way. I did in fact ask you to cite them, but you haven't done so, which leads me to believe that the peculiar features of your function are entirely your own invention - which is consistent with the way you've written many other pieces of code that you've posted to this group. You routinely add unnecessary and often just plain wrong complications to what should be simple functions. > At the moment, as I said, it is fruitless because you are referring to > something you are thinking about, to some abstract math ideas, > even if you apply them to some examples of basic compound interest > computations. I made a mistake most likely when I wrote a phrase > "interest rate" instead of "interes> t expense", which has led to you > showing pretty basic examples, not referred to what I am computing. > You are not basing your examples on my data, and > even not on some financial statements, i.e. income statements and > balance sheet data, which I take as basis for my computation. Going back you your earlier messages about this program, you have indicated that you're collecting accounting data and then attempting to project it into the future. That's data modeling, and the relevant rules for data modeling that are violated by your function are just as relevant when you're modeling financial data as they are when you're modeling the scientific data that I have more professional experience with. If you have a series of numbers x[i] for which there's a good reason to expect them to have a nearly constant ratio between consecutive numbers in the series, it can be reasonable to model that series for projections into the future as having an exactly constant ratio, and calculating the geometric mean of those ratios is a reasonable, if simplistic, way of determining what that constant should be. If you have a series of numbers y[i], such that 1.0+y[i] has the same properties as the ratios described in the previous paragraph, then it can make sense to model that series as having a constant value of y, and to determine what that constant value should be by calculating the geometric mean of 1.0+y[i] over all values of i, and subtracting 1.0 from that geometric mean. However, it doesn't make sense to have a series of numbers z[i], and to calculate the geometric mean over all values of i of either z[i] or 1.0+z[i], depending upon the value of z[i]. And that's precisely the kind of calculation your function does. > Therefore, not being a math professor, at the moment I am interested > only in applicable computations based on concrete data, say from > K-10 reports, and not on discussing math issues. I do hope to have > an opportunity to learn math much more thoroughly and sometime > to be able to indulge in truly interesting discussions on math issues. I'm fairly certain that the calculations you are doing are NOT the "applicable" ones. They seem to represent a bizarre misunderstanding on your part about what the term "geometric mean" means.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-30 10:04 -0800 |
| Message-ID | <67e1ade0-2e26-463b-ba33-5bd307c50ce7@googlegroups.com> |
| In reply to | #102765 |
On Monday, January 30, 2017 at 8:27:07 PM UTC+3, James R. Kuyper wrote: > On 01/30/2017 07:57 AM, Alla _ wrote: > ... > > With all respect I would like to opt out from this discussion because I consider > > it fruitless to both of us - we both talk about something related > > to our cases. If you have ever created pro forma statements and have > > exact examples of data in spreadsheets will such computations, than > > it could be very interesting to see, and to continue this discussion > > (and definitely not here). > > I make no claim to being an expert in accounting. However, neither am I > ignorant of the subject. I learned the basics of accounting many years > ago because my instructors thought I might end up using my computing > skills in financial contexts, which is not how my career actually turned > out. I used those basics while doing my own personal bookkeeping. > At one time, my wife was considering changing her career to accounting. > She took a different accounting class every semester for several years, > including summer sessions I and II. Because English is not her native > language, she came to me for help. I would spend 10-15 minutes reading > and easily understanding each chapter, and then spend the next several > hours explaining what I had just learned to her. Unless you have at > least a certificate of some kind in accounting, please don't > automatically assume that I'm ignorant of any particular aspect of > accounting that you're well aware of. You are just confirming that this discussion is fruitless. I have not claimed that you are ignorant, on the contrary; you have said many many messages ago that you understand and know accounting, and I was happy to read that because it means you know what I am doing. I don't need any more proofs from you, I have trusted that first message. But what I said is that we both refer to something each of us is thinking about, and not having an opportunity to look at the same data and discuss it, the whole discussion doesn't make sense, no matter what and how much each of us knows or doesn't know. > > The problem with your function has nothing to do with accounting > principles. Accounting involves some very weird processes that can be > difficult to justify mathematically, such as the way double-declining > balance depreciation is calculated. But whenever that's the case, > there's very specific rules describing what you're supposed to do (in > the case of double-declining balance depreciation, those rules are > embedded in US tax law, as well as the rules of several different > international accounting authorities). > If there were any such rules justifying the bizarre features of your > function, you could have cited them, and I'm fairly certain I would have > understood those rules, and might even have been able to understand why > they were written that way. I did in fact ask you to cite them, but you > haven't done so, which leads me to believe that the peculiar features of > your function are entirely your own invention - which is consistent with > the way you've written many other pieces of code that you've posted to > this group. You routinely add unnecessary and often just plain wrong > complications to what should be simple functions. > > > At the moment, as I said, it is fruitless because you are referring to > > something you are thinking about, to some abstract math ideas, > > even if you apply them to some examples of basic compound interest > > computations. I made a mistake most likely when I wrote a phrase > > "interest rate" instead of "interes> > t expense", which has led to you > > showing pretty basic examples, not referred to what I am computing. > > You are not basing your examples on my data, and > > even not on some financial statements, i.e. income statements and > > balance sheet data, which I take as basis for my computation. > > Going back you your earlier messages about this program, you have > indicated that you're collecting accounting data and then attempting to > project it into the future. That's data modeling, and the relevant rules > for data modeling that are violated by your function are just as > relevant when you're modeling financial data as they are when you're > modeling the scientific data that I have more professional experience with. > > If you have a series of numbers x[i] for which there's a good reason to > expect them to have a nearly constant ratio between consecutive numbers > in the series, it can be reasonable to model that series for projections > into the future as having an exactly constant ratio, and calculating the > geometric mean of those ratios is a reasonable, if simplistic, way of > determining what that constant should be. > > If you have a series of numbers y[i], such that 1.0+y[i] has the same > properties as the ratios described in the previous paragraph, then it > can make sense to model that series as having a constant value of y, and > to determine what that constant value should be by calculating the > geometric mean of 1.0+y[i] over all values of i, and subtracting 1.0 > from that geometric mean. > > However, it doesn't make sense to have a series of numbers z[i], and to > calculate the geometric mean over all values of i of either z[i] or > 1.0+z[i], depending upon the value of z[i]. And that's precisely the > kind of calculation your function does. > > > Therefore, not being a math professor, at the moment I am interested > > only in applicable computations based on concrete data, say from > > K-10 reports, and not on discussing math issues. I do hope to have > > an opportunity to learn math much more thoroughly and sometime > > to be able to indulge in truly interesting discussions on math issues. > > I'm fairly certain that the calculations you are doing are NOT the > "applicable" ones. They seem to represent a bizarre misunderstanding on > your part about what the term "geometric mean" means.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-30 10:28 -0800 |
| Message-ID | <f0437333-f797-461d-b6ea-59592d0c63ee@googlegroups.com> |
| In reply to | #102765 |
On Monday, January 30, 2017 at 8:27:07 PM UTC+3, James R. Kuyper wrote: > On 01/30/2017 07:57 AM, Alla _ wrote: > ... > > With all respect I would like to opt out from this discussion because I consider > > it fruitless to both of us - we both talk about something related > > to our cases. If you have ever created pro forma statements and have > > exact examples of data in spreadsheets will such computations, than > > it could be very interesting to see, and to continue this discussion > > (and definitely not here). > > I make no claim to being an expert in accounting. However, neither am I > ignorant of the subject. I learned the basics of accounting many years > ago because my instructors thought I might end up using my computing > skills in financial contexts, which is not how my career actually turned > out. I used those basics while doing my own personal bookkeeping. > At one time, my wife was considering changing her career to accounting. > She took a different accounting class every semester for several years, > including summer sessions I and II. Because English is not her native > language, she came to me for help. I would spend 10-15 minutes reading > and easily understanding each chapter, and then spend the next several > hours explaining what I had just learned to her. Unless you have at > least a certificate of some kind in accounting, please don't > automatically assume that I'm ignorant of any particular aspect of > accounting that you're well aware of. > > The problem with your function has nothing to do with accounting > principles. Accounting involves some very weird processes that can be > difficult to justify mathematically, such as the way double-declining > balance depreciation is calculated. But whenever that's the case, > there's very specific rules describing what you're supposed to do (in > the case of double-declining balance depreciation, those rules are > embedded in US tax law, as well as the rules of several different > international accounting authorities). > If there were any such rules justifying the bizarre features of your > function, you could have cited them, and I'm fairly certain I would have > understood those rules, and might even have been able to understand why > they were written that way. I did in fact ask you to cite them, but you > haven't done so, which leads me to believe that the peculiar features of > your function are entirely your own invention - which is consistent with > the way you've written many other pieces of code that you've posted to > this group. You routinely add unnecessary and often just plain wrong > complications to what should be simple functions. > > > At the moment, as I said, it is fruitless because you are referring to > > something you are thinking about, to some abstract math ideas, > > even if you apply them to some examples of basic compound interest > > computations. I made a mistake most likely when I wrote a phrase > > "interest rate" instead of "interes> > t expense", which has led to you > > showing pretty basic examples, not referred to what I am computing. > > You are not basing your examples on my data, and > > even not on some financial statements, i.e. income statements and > > balance sheet data, which I take as basis for my computation. > > Going back you your earlier messages about this program, you have > indicated that you're collecting accounting data and then attempting to > project it into the future. That's data modeling, and the relevant rules > for data modeling that are violated by your function are just as > relevant when you're modeling financial data as they are when you're > modeling the scientific data that I have more professional experience with. > > If you have a series of numbers x[i] for which there's a good reason to > expect them to have a nearly constant ratio between consecutive numbers > in the series, it can be reasonable to model that series for projections > into the future as having an exactly constant ratio, and calculating the > geometric mean of those ratios is a reasonable, if simplistic, way of > determining what that constant should be. > > If you have a series of numbers y[i], such that 1.0+y[i] has the same > properties as the ratios described in the previous paragraph, then it > can make sense to model that series as having a constant value of y, and > to determine what that constant value should be by calculating the > geometric mean of 1.0+y[i] over all values of i, and subtracting 1.0 > from that geometric mean. > > However, it doesn't make sense to have a series of numbers z[i], and to > calculate the geometric mean over all values of i of either z[i] or > 1.0+z[i], depending upon the value of z[i]. And that's precisely the > kind of calculation your function does. > > > Therefore, not being a math professor, at the moment I am interested > > only in applicable computations based on concrete data, say from > > K-10 reports, and not on discussing math issues. I do hope to have > > an opportunity to learn math much more thoroughly and sometime > > to be able to indulge in truly interesting discussions on math issues. > > I'm fairly certain that the calculations you are doing are NOT the > "applicable" ones. They seem to represent a bizarre misunderstanding on > your part about what the term "geometric mean" means. Hardly makes any sense to discuss anything if one person of the discussion is "certain" about his vision of the situation, therefore let's agree on this last two-sentence certainty of yours )
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-30 14:38 -0500 |
| Message-ID | <d764f354-78e0-7072-4a61-701b09f0eb2d@verizon.net> |
| In reply to | #102776 |
On 01/30/2017 01:28 PM, Alla _ wrote: > On Monday, January 30, 2017 at 8:27:07 PM UTC+3, James R. Kuyper wrote: ... >> I'm fairly certain that the calculations you are doing are NOT the >> "applicable" ones. They seem to represent a bizarre misunderstanding on >> your part about what the term "geometric mean" means. > Hardly makes any sense to discuss anything if one person of the discussion > is "certain" about his vision of the situation, therefore let's agree on this last Did you mean to say "agree to disagree"? As written, that comment doesn't seem to fit the context. > two-sentence certainty of yours ) I'm only "fairly certain" of it. I don't believe that absolute certainty can ever be justified (though unjustified absolute certainty is quite common). All you have to do to make me change my mind on this matter is to cite a document justifying the peculiar features of your function. The more authoritative it is, the better, but my requirements are not high - so long as there is even one publicly available document written by someone who has a relevant professional background, that describes the calculations your function performs, that would significantly modify my perception of your function. In particular, that document might explain the reason for those peculiar features, something that you seem unable to do.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-31 12:45 -0800 |
| Message-ID | <2f29913d-e7d9-495a-9306-e6e4c17589c8@googlegroups.com> |
| In reply to | #102785 |
On Monday, January 30, 2017 at 10:39:08 PM UTC+3, James R. Kuyper wrote: > On 01/30/2017 01:28 PM, Alla _ wrote: > > On Monday, January 30, 2017 at 8:27:07 PM UTC+3, James R. Kuyper wrote: > ... > >> I'm fairly certain that the calculations you are doing are NOT the > >> "applicable" ones. They seem to represent a bizarre misunderstanding on > >> your part about what the term "geometric mean" means. > > Hardly makes any sense to discuss anything if one person of the discussion > > is "certain" about his vision of the situation, therefore let's agree on this last > > Did you mean to say "agree to disagree"? As written, that comment > doesn't seem to fit the context. Oh, James ) You surely know that there is text, context, and, the best of three, subtext ))) I have written exactly what I have meant to write ) But sorry for using vague language; won't do that again. But it was surely not a sign of impoliteness from my side, rather a little friendly jibe. > > > two-sentence certainty of yours ) > > I'm only "fairly certain" of it. I don't believe that absolute certainty > can ever be justified (though unjustified absolute certainty is quite > common). All you have to do to make me change my mind on this matter is > to cite a document justifying the peculiar features of your function. > The more authoritative it is, the better, but my requirements are not > high - so long as there is even one publicly available document written > by someone who has a relevant professional background, that describes > the calculations your function performs, that would significantly modify > my perception of your function. In particular, that document might > explain the reason for those peculiar features, something that you seem > unable to do.
[toc] | [prev] | [next] | [standalone]
Page 4 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