Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #102489 > unrolled thread

Passing values from structure arrays to a generic geometrical mean function

Back to article view | Back to comp.lang.c

Contents

  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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9  Next page →

#102829

David Brown <david.brown@hesbynett.no> wrote:

> On 27/01/17 18:13, Richard Bos wrote:
> > David Brown <david.brown@hesbynett.no> wrote:
> >> On 27/01/17 16:35, BartC wrote:
> >>> On 27/01/2017 15:05, David Brown wrote:
> >>>
> >>>> I have a background in maths, and in functional programming.
> >>>> Re-assignment to a variable always looks slightly wrong to me - if x is
> >>>> 0, then why is it now something else?
> >>>
> >>> Yesterday I had £20 in my wallet, and today it's only £10. Yes it would
> >>> be nice if it was still £20 even after I'd spent half of it, or my
> >>> current account balance never got less, but that's not how it works.
> >>
> >> When I want a glass of milk, I do not initialise the glass to a base
> >> "glass of water" before emptying it and filling it with milk.
> >
> > I do. It's called "rinsing".
> 
> As I said, analogies are not always relevant.  And any analogy, no 
> matter how good, will lose its point when you stretch things too far.

Then maybe you shouldn't have swapped analogies mid-stream.

> >> Analogies are not always relevant.
> >
> > However, this one was. In the real world outside the ivory tower of
> > academe, most things do change. 99% of us do not have tenure, so we have
> > to deal with the fact that our income may be reassigned to.
> 
> In program code, some things change - but not most things.
> 
> If it makes sense for a variable to change, that's fine.  For a loop 
> index, it is hard to avoid changes - you would have to use recursion or 
> make some sort of list structure, which would be a silly idea in most 
> code (at least in a language like C).
> 
> But assigning a value of 0 to x that is never used, and then assigning a 
> different value later on, is a pointless change.

That, I agree with. But that is not what you wrote up ^^ there. That's a
problem with unneeded* initialisations, not with re-assignment /per se/.

Richard

*IMAO, and apparently also IYO, but SPMMV

[toc] | [prev] | [next] | [standalone]

#102831

On 31/01/17 12:23, Richard Bos wrote:
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> On 27/01/17 18:13, Richard Bos wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 27/01/17 16:35, BartC wrote:
>>>>> On 27/01/2017 15:05, David Brown wrote:
>>>>>
>>>>>> I have a background in maths, and in functional programming.
>>>>>> Re-assignment to a variable always looks slightly wrong to me - if x is
>>>>>> 0, then why is it now something else?
>>>>>

<snip>

>>
>> If it makes sense for a variable to change, that's fine.  For a loop 
>> index, it is hard to avoid changes - you would have to use recursion or 
>> make some sort of list structure, which would be a silly idea in most 
>> code (at least in a language like C).
>>
>> But assigning a value of 0 to x that is never used, and then assigning a 
>> different value later on, is a pointless change.
> 
> That, I agree with. But that is not what you wrote up ^^ there. That's a
> problem with unneeded* initialisations, not with re-assignment /per se/.

Are you referring to the bit I have left above the "snip" ?
Re-assignment might be necessary, or at least not pointless, and still
"look slightly wrong to me".  For example, I would prefer foo2 to foo1
below (ignoring the simple and obvious version) :

int foo1(int a) {
	int b = a * 2;
	b++;
	return b;
}

int foo2(int a) {
	int b = a * 2;
	int c = b + 1;
	return c;
}


> 
> Richard
> 
> *IMAO, and apparently also IYO, but SPMMV
> 

[toc] | [prev] | [next] | [standalone]

#102951

raltbos@xs4all.nl (Richard Bos) writes:

> Functional programming is easier if you're dealing with theory.
> IMAO, for dealing with the real world, procedural programming is
> much superior.

The question that comes to mind is how informed an opinion
it is.  How extensive is your experience working in a (at
least primarily) functional programming environment meant to
accomplish nontrivial tasks?  On a scale from 1 to 10, say.
(I'm not out to prove anything, I'm just curious.)

[toc] | [prev] | [next] | [standalone]

#102555

BartC <bc@freeuk.com> writes:

> On 27/01/2017 15:05, David Brown wrote:
>
>> I have a background in maths, and in functional programming.
>> Re-assignment to a variable always looks slightly wrong to me - if x is
>> 0, then why is it now something else?
>
> Yesterday I had £20 in my wallet, and today it's only £10. Yes it
> would be nice if it was still £20 even after I'd spent half of it, or
> my current account balance never got less, but that's not how it
> works.
>
> Some things need to be variable.

But, ironically, variables don't:

wallet_content Yesterday = Just 20
wallet_content Today     = Just 10
Wallet_content _         = Nothing

That's a function (in Haskell as it happens) that represents one kind of
"variable".

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#102560

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> BartC <bc@freeuk.com> writes:
> 
> > On 27/01/2017 15:05, David Brown wrote:
> >
> >> I have a background in maths, and in functional programming.
> >> Re-assignment to a variable always looks slightly wrong to me - if x is
> >> 0, then why is it now something else?
> >
> > Yesterday I had Ł20 in my wallet, and today it's only Ł10. Yes it
> > would be nice if it was still Ł20 even after I'd spent half of it, or
> > my current account balance never got less, but that's not how it
> > works.
> >
> > Some things need to be variable.
> 
> But, ironically, variables don't:
> 
> wallet_content Yesterday = Just 20
> wallet_content Today     = Just 10
> Wallet_content _         = Nothing
> 
> That's a function (in Haskell as it happens) that represents one kind of
> "variable".

It may represent it, but it isn't one.

Now skip a day. "Today" changes, and so does the wallet_content. I'm
sure it can be done, but it's a roundabout way of doing it. You're not
creating a variable, you're creating several constants with similar
names, and if they need to change _again_... *poof* pops up another
constant.

Richard

[toc] | [prev] | [next] | [standalone]

#102616

raltbos@xs4all.nl (Richard Bos) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> BartC <bc@freeuk.com> writes:
>> 
>> > On 27/01/2017 15:05, David Brown wrote:
>> >
>> >> I have a background in maths, and in functional programming.
>> >> Re-assignment to a variable always looks slightly wrong to me - if x is
>> >> 0, then why is it now something else?
>> >
>> > Yesterday I had £20 in my wallet, and today it's only £10. Yes it
>> > would be nice if it was still £20 even after I'd spent half of it, or
>> > my current account balance never got less, but that's not how it
>> > works.
>> >
>> > Some things need to be variable.
>> 
>> But, ironically, variables don't:
>> 
>> wallet_content Yesterday = Just 20
>> wallet_content Today     = Just 10
>> Wallet_content _         = Nothing
>> 
>> That's a function (in Haskell as it happens) that represents one kind of
>> "variable".
>
> It may represent it, but it isn't one.

Of course.  That's the whole point.

> Now skip a day. "Today" changes, and so does the wallet_content. I'm
> sure it can be done, but it's a roundabout way of doing it. You're not
> creating a variable, you're creating several constants with similar
> names, and if they need to change _again_... *poof* pops up another
> constant.

Yes, if you change the claim, the counter-claim changes and may even
vanish.  BartC said "need" and gave an example.  You are saying it's
"roundabout".  It might well be.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#102630

On Friday, January 27, 2017 at 3:35:40 PM UTC, Bart wrote:
> On 27/01/2017 15:05, David Brown wrote:
> 
> > I have a background in maths, and in functional programming.
> > Re-assignment to a variable always looks slightly wrong to me - if x is
> > 0, then why is it now something else?
> 
> Yesterday I had £20 in my wallet, and today it's only £10. Yes it would 
> be nice if it was still £20 even after I'd spent half of it, or my 
> current account balance never got less, but that's not how it works.
> 
> Some things need to be variable.
> 
The question really is whether things are manipulable.

You wallet is the same wallet, the same physical leather, whatever happens
within the scope of the simulation.

Now you could say you take out a £20 note, now the wallet is empty,
you receive a £10 note, now the wallet contains a £10 note. Banknotes
are also (within the scope of the sim) immutable, you can't tear them
in half. Or we could say the money in the wallet is fungible. It has
20 pounds in unknown coinage, you paid out ten pounds, so it now has
10 pounds in it. 

[toc] | [prev] | [next] | [standalone]

#102547

On 01/27/2017 10:05 AM, David Brown wrote:
...
> compilers will be better or worse at it.  However, initialising "var"
> with 0 will not fix the problem with the code, even though it would make
> the behaviour defined.  The answer is to avoid writing code with
> undefined behaviour - /not/ to write code that has defined but
> /incorrect/ behaviour.

The defined incorrect behavior can, in some cases, make it easier to
detect that the behavior is incorrect.
My own experience has been almost entirely the opposite, however. I've
seen several bugs in other people's code that were difficult to notice
because an uninitialized object was zero-initialized by the compiler.
Zero happened to be a value that was incorrect, but not sufficiently
incorrect to produce any easily detected anomalies.
Those bugs could have been detected by carefully written test cases -
but I inherited that code from others who did not create any unit tests
for them. And it needed to be installed and running in a hurry, which
means I didn't have the time it would have required to create a complete
set of unit tests for them. I only had time to do regression testing to
confirm that we were getting the same results as the original authors
did, when processing the same data.
I only detected the defects when the programs were re-built using a
compiler that didn't automatically zero-initialize uninitialized memory.

...
> fail to use available good tools, I expect there are very few people in
> this group who actually have to use a compiler that cannot spot a simple
> case of reading an uninitialised variable.

Detecting the fact that the code reads an uninitialized variable is not
necessarily simple. In cases that aren't hard to construct, whether or
not the variable's value gets set before the first time it is read can
be arbitrarily difficult. To always correctly determine whether or not
that will happen is provably equivalent to solving the halting problem.
Note, in particular, that gcc failed to identify the uninitialized
variable problems that I mentioned above, even though I had the relevant
option turned on.

[toc] | [prev] | [next] | [standalone]

#102562

David Brown <david.brown@hesbynett.no> writes:
[...]
> Deterministic incorrect behaviour is certainly better than
> non-deterministic incorrect behaviour.  But it is not nearly as good as
> a compile-time warning about the problem.
[...]

I think there are cases where non-deterministic incorrect behavior
is better than deterministic incorrect behavior.

Suppose a bug in a program causes it to produce a plausible but
incorrect result.  If it consistently produces that result, you might
never detect the error.  If different runs produce different results,
some of them may be sufficiently bad to make the bug obvious.

It depends, in part, on whether testing can reliably reveal the
problem before the code goes into production, and on the consequences
of incorrect results -- and that can be arbitrarily complicated.

-- 
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]

#102569

On Friday, January 27, 2017 at 11:25:11 AM UTC-6, Keith Thompson wrote:
> I think there are cases where non-deterministic incorrect behavior
> is better than deterministic incorrect behavior.
> 
> Suppose a bug in a program causes it to produce a plausible but
> incorrect result.  If it consistently produces that result, you might
> never detect the error.  If different runs produce different results,
> some of them may be sufficiently bad to make the bug obvious.
> 
> It depends, in part, on whether testing can reliably reveal the
> problem before the code goes into production, and on the consequences
> of incorrect results -- and that can be arbitrarily complicated.

In many cases, "non-deterministic" results will depend upon things which
may not change terribly often, but may change in response to things which
should have no causal relationship with them.  While a compiler option to
deliberately randomize uninitialized variables might occasionally help in
tracking down places where they cause problems in code *which doesn't need
to be compatible with "clever" compilers*, deterministic behavior is far
easier to diagnose than behavior which might change arbitrarily, but usually
doesn't.

[toc] | [prev] | [next] | [standalone]

#102593

supercat@casperkitty.com writes:
> On Friday, January 27, 2017 at 11:25:11 AM UTC-6, Keith Thompson wrote:
>> I think there are cases where non-deterministic incorrect behavior
>> is better than deterministic incorrect behavior.
>> 
>> Suppose a bug in a program causes it to produce a plausible but
>> incorrect result.  If it consistently produces that result, you might
>> never detect the error.  If different runs produce different results,
>> some of them may be sufficiently bad to make the bug obvious.
>> 
>> It depends, in part, on whether testing can reliably reveal the
>> problem before the code goes into production, and on the consequences
>> of incorrect results -- and that can be arbitrarily complicated.
>
> In many cases, "non-deterministic" results will depend upon things which
> may not change terribly often, but may change in response to things which
> should have no causal relationship with them.  While a compiler option to
> deliberately randomize uninitialized variables might occasionally help in
> tracking down places where they cause problems in code *which doesn't need
> to be compatible with "clever" compilers*, deterministic behavior is far
> easier to diagnose than behavior which might change arbitrarily, but usually
> doesn't.

Sometimes it is, sometimes it isn't.

It isn't if the deterministic results are plausible but incorrect.

-- 
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]

#102692

On 27/01/17 20:50, Keith Thompson wrote:
> supercat@casperkitty.com writes:
>> On Friday, January 27, 2017 at 11:25:11 AM UTC-6, Keith Thompson wrote:
>>> I think there are cases where non-deterministic incorrect behavior
>>> is better than deterministic incorrect behavior.
>>>
>>> Suppose a bug in a program causes it to produce a plausible but
>>> incorrect result.  If it consistently produces that result, you might
>>> never detect the error.  If different runs produce different results,
>>> some of them may be sufficiently bad to make the bug obvious.
>>>
>>> It depends, in part, on whether testing can reliably reveal the
>>> problem before the code goes into production, and on the consequences
>>> of incorrect results -- and that can be arbitrarily complicated.
>>
>> In many cases, "non-deterministic" results will depend upon things which
>> may not change terribly often, but may change in response to things which
>> should have no causal relationship with them.  While a compiler option to
>> deliberately randomize uninitialized variables might occasionally help in
>> tracking down places where they cause problems in code *which doesn't need
>> to be compatible with "clever" compilers*, deterministic behavior is far
>> easier to diagnose than behavior which might change arbitrarily, but usually
>> doesn't.
>
> Sometimes it is, sometimes it isn't.
>
> It isn't if the deterministic results are plausible but incorrect.
>

When you have incorrect behaviour, there is no "best type of incorrect 
behaviour".  For any kind of bad behaviour, there will always be cases 
where another type would have been preferable (doing less "damage", or 
being easier to debug).  Often deterministic bad behaviour is easier to 
track than non-deterministic bad behaviour, but certainly not always.

(Yes, that is contrary to some sweeping statements I made earlier in the 
thread without thinking about it properly.)

As Brian Kernighan said, "Everyone knows that debugging is twice as hard 
as writing a program in the first place".

[toc] | [prev] | [next] | [standalone]

#102526

On 1/27/2017 1:29 PM, David Brown wrote:
> Had you left it uninitialised and used appropriate compiler warnings,
> you would /immediately/ have seen your error even before trying to run
> the program.
Hm...
This is probably so with a good compiler and C99 or later, but based on 
experience I still believe that uninitialized variables are best avoided.

I remember of a bug that occurred in a large project (>2Mloc) I was long 
ago involved with. It caused weeks of headache, and it was caused by (a 
deeply buried) strlen being called on an uninitialized string.

[toc] | [prev] | [next] | [standalone]

#102531

On 27/01/17 15:36, Manfred wrote:
> On 1/27/2017 1:29 PM, David Brown wrote:
>> Had you left it uninitialised and used appropriate compiler warnings,
>> you would /immediately/ have seen your error even before trying to run
>> the program.
> Hm...
> This is probably so with a good compiler and C99 or later, but based on
> experience I still believe that uninitialized variables are best avoided.
> 

I agree.  It is best to avoid defining your variables until you have
something to put in them.

But if you /have/ to define them earlier, then it is rare (but not
impossible) that initialising them to an artificial value is helpful.

> I remember of a bug that occurred in a large project (>2Mloc) I was long
> ago involved with. It caused weeks of headache, and it was caused by (a
> deeply buried) strlen being called on an uninitialized string.

[toc] | [prev] | [next] | [standalone]

#102537

On 1/27/2017 4:22 PM, David Brown wrote:
> I agree.  It is best to avoid defining your variables until you have
> something to put in them.
Yes.

>
> But if you /have/ to define them earlier, then it is rare (but not
> impossible) that initialising them to an artificial value is helpful.
I would not be sure about /rare/ (C strings are a good example, and I 
would not consider them rare)
On the other hand, what I see is that if you choose your variables 
properly, usually you also have some reasonable value to initialize them 
with.
In other words, if you have no clue on how to initialize the variable, 
this might be a hint for re-evaluating if the variable is properly chosen.

>
>> I remember of a bug that occurred in a large project (>2Mloc) I was long
>> ago involved with. It caused weeks of headache, and it was caused by (a
>> deeply buried) strlen being called on an uninitialized string.
In this case (where it was in an external library) the issue was 
different - the initial choice was motivated by performance concerns.

[toc] | [prev] | [next] | [standalone]

#102545

On 27/01/17 16:53, Manfred wrote:
> On 1/27/2017 4:22 PM, David Brown wrote:
>> I agree.  It is best to avoid defining your variables until you have
>> something to put in them.
> Yes.
> 
>>
>> But if you /have/ to define them earlier, then it is rare (but not
>> impossible) that initialising them to an artificial value is helpful.
> I would not be sure about /rare/ (C strings are a good example, and I
> would not consider them rare)
> On the other hand, what I see is that if you choose your variables
> properly, usually you also have some reasonable value to initialize them
> with.
> In other words, if you have no clue on how to initialize the variable,
> this might be a hint for re-evaluating if the variable is properly chosen.
> 

Agreed.

>>
>>> I remember of a bug that occurred in a large project (>2Mloc) I was long
>>> ago involved with. It caused weeks of headache, and it was caused by (a
>>> deeply buried) strlen being called on an uninitialized string.
> In this case (where it was in an external library) the issue was
> different - the initial choice was motivated by performance concerns.

[toc] | [prev] | [next] | [standalone]

#102523

On Friday, January 27, 2017 at 1:34:06 PM UTC+3, Richard Heathfield wrote:
> On 27/01/17 09:53, Alla _ wrote:
<snip>
Here is how everything looks now. Far from being generic
because I still have no idea how to name parameters to make
them generic. Maybe I shouldn't try it now, and leave it for later:
(oh, and, yes, offsets - they are still here; enum tool is yet to be 
learned)

/** Function to fill assumptions: rates
 for depreciation, interest **/
void assump_rates_2(income_st *income_ptr, assets *ba_ptr, assumptions *rates)
{
    int dep_amor_offs = offsetof(assumptions, av_dep_amor);
  
    //Compute rate for depreciation and amortization
    double gm_dep = mean(income_ptr, ba_ptr);
    if(gm_dep != 0.0)
        *(double*)((char*)rates + dep_amor_offs) = gm_dep;
}

/** Function to compute the mean
    for two numbers
 **/
double mean_twonums(double number1, double number2)
{
  if(number1 < 0 || number2 < 0)
      return (number1+number2)/2;
    
  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);
}

/** Function to compute arithmetic average
    for depreciation and amortization
 **/
double arithmetic_av(income_st *income_ptr, assets *ba_ptr)
{
    double sum = 0.0;
    double average = 0.0;
    double mean_twonum1 = 0.0;
    double mean_twonum2 = 0.0;
    
    if(DATA_SIZE > 0)
    {
        for (int i = 1; i < DATA_SIZE; i++)
        {
            mean_twonum1 = mean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe);
            mean_twonum2 = mean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang);
            
            if(mean_twonum1 != 0 || mean_twonum2 != 0)
                sum += income_ptr[i].dep_amor/(mean_twonum1 + mean_twonum2);
            else
            {
                sum = 0.0;
                break;
            }
        }
        if(sum != 0.0)
            average = sum / (DATA_SIZE-1);
    }
    return average;
}

/** Function to compute pro forma rate
    for depreciation and amortization
 **/
double mean(income_st *income_ptr, assets *ba_ptr)
{
    double product = 1.0;
    double mean = 0.0;
    double mean_twonum1 = 0.0;
    double mean_twonum2 = 0.0;
    
    if(DATA_SIZE > 0)
    {
        //Take data for each year
        for (int i = 1; i < DATA_SIZE; i++)
        {
            //Compute arithmetic average if negative depreciation
            if (income_ptr[i].dep_amor < 0)
                return arithmetic_av(income_ptr, ba_ptr);
            
            mean_twonum1 = mean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe);
            mean_twonum2 = mean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang);
            
            if(mean_twonum1 != 0 || mean_twonum2 != 0)
                product *= (1 + (income_ptr[i].dep_amor)/(mean_twonum1 + mean_twonum2) );
            else
                product = 0.0;
        }
        if(product != 0.0)
            mean = pow(product, 1.0/DATA_SIZE)-1;
    }
    return mean;
}

[toc] | [prev] | [next] | [standalone]

#102552

Alla _ <modelling.data@gmail.com> writes:

> On Friday, January 27, 2017 at 1:34:06 PM UTC+3, Richard Heathfield wrote:
>> On 27/01/17 09:53, Alla _ wrote:
> <snip>
> Here is how everything looks now. Far from being generic
> because I still have no idea how to name parameters to make
> them generic. Maybe I shouldn't try it now, and leave it for later:
> (oh, and, yes, offsets - they are still here; enum tool is yet to be 
> learned)
>
> /** Function to fill assumptions: rates
>  for depreciation, interest **/
> void assump_rates_2(income_st *income_ptr, assets *ba_ptr, assumptions *rates)

Putting aside the parameters, the function name is wrong.  There is very
rarely any reason to call a function something_2.  If you are doing that
it suggests you are not really sure what the purpose if the function is.

And this function is 'void'.  Do you recall what I said about that?

> {
>     int dep_amor_offs = offsetof(assumptions, av_dep_amor);

You really must stop using offsetof.  It is a terrible hack that is only
very occasionally useful.  Reaching for it should be an indication that
you have the wrong design -- either of the function or of the data
structure.

>     //Compute rate for depreciation and amortization
>     double gm_dep = mean(income_ptr, ba_ptr);
>     if(gm_dep != 0.0)
>         *(double*)((char*)rates + dep_amor_offs) = gm_dep;

And when gm_dep is zero you are happy to leave the target unchanged?

> }
>
> /** Function to compute the mean
>     for two numbers
>  **/
> double mean_twonums(double number1, double number2)
> {
>   if(number1 < 0 || number2 < 0)
>       return (number1+number2)/2;

What do you know for certain at this point after the if?

>   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);

This function is very odd.  It does not do one simple thing.  It does a
weird bunch of things depending on the data and this is very rarely a
good idea.

> }
>
> /** Function to compute arithmetic average
>     for depreciation and amortization
>  **/
> double arithmetic_av(income_st *income_ptr, assets *ba_ptr)

This is the wrong name.  Whatever it is that this function calculates it
is not the arithmetic average of anything!

> {
>     double sum = 0.0;
>     double average = 0.0;
>     double mean_twonum1 = 0.0;
>     double mean_twonum2 = 0.0;

These two are in the wrong place, even (I would say) for Richard
Heathfield code (though he may wish to correct me on that).

>     
>     if(DATA_SIZE > 0)
>     {
>         for (int i = 1; i < DATA_SIZE; i++)
>         {
>             mean_twonum1 = mean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe);
>             mean_twonum2 = mean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang);
>             
>             if(mean_twonum1 != 0 || mean_twonum2 != 0)
>                 sum += income_ptr[i].dep_amor/(mean_twonum1 + mean_twonum2);
>             else
>             {
>                 sum = 0.0;
>                 break;
>             }
>         }
>         if(sum != 0.0)
>             average = sum / (DATA_SIZE-1);
>     }
>     return average;

I don't think this can really be the calculation you need.  I know I
know very little about finance, but this just looks bonkers.

> }
>
> /** Function to compute pro forma rate
>     for depreciation and amortization
>  **/
> double mean(income_st *income_ptr, assets *ba_ptr)
> {
>     double product = 1.0;
>     double mean = 0.0;
>     double mean_twonum1 = 0.0;
>     double mean_twonum2 = 0.0;

Ditto.

>     if(DATA_SIZE > 0)
>     {
>         //Take data for each year
>         for (int i = 1; i < DATA_SIZE; i++)
>         {
>             //Compute arithmetic average if negative depreciation
>             if (income_ptr[i].dep_amor < 0)
>                 return arithmetic_av(income_ptr, ba_ptr);
>             
>             mean_twonum1 = mean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe);
>             mean_twonum2 = mean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang);
>             
>             if(mean_twonum1 != 0 || mean_twonum2 != 0)
>                 product *= (1 + (income_ptr[i].dep_amor)/(mean_twonum1 + mean_twonum2) );
>             else
>                 product = 0.0;
>         }
>         if(product != 0.0)
>             mean = pow(product, 1.0/DATA_SIZE)-1;

Really?  I don't think so but I can't guess what you meant.

>     }
>     return mean;
> }
>

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#102557

On 27/01/17 16:44, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>

<snip>

>>     double mean_twonum1 = 0.0;
>>     double mean_twonum2 = 0.0;
>
> These two are in the wrong place, even (I would say) for Richard
> Heathfield code (though he may wish to correct me on that).

Even for my code, yes. :-)

>>     if(DATA_SIZE > 0)
>>     {
>>         for (int i = 1; i < DATA_SIZE; i++)
>>         {

I'd put them about...

>>             mean_twonum1 = mean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe);
>>             mean_twonum2 = mean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang);

...there.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#102566

On Friday, January 27, 2017 at 7:44:33 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> 
> > On Friday, January 27, 2017 at 1:34:06 PM UTC+3, Richard Heathfield wrote:
> >> On 27/01/17 09:53, Alla _ wrote:
> > <snip>
> > Here is how everything looks now. Far from being generic
> > because I still have no idea how to name parameters to make
> > them generic. Maybe I shouldn't try it now, and leave it for later:
> > (oh, and, yes, offsets - they are still here; enum tool is yet to be 
> > learned)
> >
> > /** Function to fill assumptions: rates
> >  for depreciation, interest **/
> > void assump_rates_2(income_st *income_ptr, assets *ba_ptr, assumptions *rates)
> 
> Putting aside the parameters, the function name is wrong.  There is very
> rarely any reason to call a function something_2.  If you are doing that
> it suggests you are not really sure what the purpose if the function is.
> 
> And this function is 'void'.  Do you recall what I said about that?
> 
> > {
> >     int dep_amor_offs = offsetof(assumptions, av_dep_amor);
> 
> You really must stop using offsetof.  It is a terrible hack that is only
> very occasionally useful.  Reaching for it should be an indication that
> you have the wrong design -- either of the function or of the data
> structure.
> 
I can't stop doing it now. I have spent  more than 2 days
working on the code, when everyone suddenly told me to 
move away from offsets; I have tried to use the enum approach, 
but it was too difficult, so I asked if I can learn it later, and I 
have understood that you have agreed to that; but then, after
I have moved quite far, you have said to switch away from it. 
You know that I am still learning, and that some things are 
too comprehensive for me now. 

> >     //Compute rate for depreciation and amortization
> >     double gm_dep = mean(income_ptr, ba_ptr);
> >     if(gm_dep != 0.0)
> >         *(double*)((char*)rates + dep_amor_offs) = gm_dep;
> 
> And when gm_dep is zero you are happy to leave the target unchanged?
This part is dealt with by the calling routine. And actually a zero depreciation rate
during 5 (let alone 10 years) is hardly ever possible for a company that has 
depreciable assets. 

> 
> > }
> >
> > /** Function to compute the mean
> >     for two numbers
> >  **/
> > double mean_twonums(double number1, double number2)
> > {
> >   if(number1 < 0 || number2 < 0)
> >       return (number1+number2)/2;
> 
> What do you know for certain at this point after the if?
After this 'if' the function stops and returns the simple
arithmetic average, because at least one of the values
is negative (which is actually also very rarely possible 
for depreciation values, it would mean appreciation 
of the asset, but that is not truly relative for now). 
> 
> >   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);
> 
> This function is very odd.  It does not do one simple thing.  It does a
> weird bunch of things depending on the data and this is very rarely a
> good idea.
By this code I check if any number is between 1 and zero. I don't see
what wrong with this test :(
> 
> > }
> >
> > /** Function to compute arithmetic average
> >     for depreciation and amortization
> >  **/
> > double arithmetic_av(income_st *income_ptr, assets *ba_ptr)
> 
> This is the wrong name.  Whatever it is that this function calculates it
> is not the arithmetic average of anything!
It computes an arithmetic average of ratios. 
> 
> > {
> >     double sum = 0.0;
> >     double average = 0.0;
> >     double mean_twonum1 = 0.0;
> >     double mean_twonum2 = 0.0;
> 
> These two are in the wrong place, even (I would say) for Richard
> Heathfield code (though he may wish to correct me on that).
I see. They have to be right before the for loop, correct?
> 
> >     
> >     if(DATA_SIZE > 0)
> >     {
> >         for (int i = 1; i < DATA_SIZE; i++)
> >         {
> >             mean_twonum1 = mean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe);
> >             mean_twonum2 = mean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang);
> >             
> >             if(mean_twonum1 != 0 || mean_twonum2 != 0)
> >                 sum += income_ptr[i].dep_amor/(mean_twonum1 + mean_twonum2);
> >             else
> >             {
> >                 sum = 0.0;
> >                 break;
> >             }
> >         }
> >         if(sum != 0.0)
> >             average = sum / (DATA_SIZE-1);
> >     }
> >     return average;
> 
> I don't think this can really be the calculation you need.  I know I
> know very little about finance, but this just looks bonkers.
This is the best code I could come up with :)  It does serve the purpose
when I have negative values, which, again, will very rarely appear 
in "real life". 

> 
> > }
> >
> > /** Function to compute pro forma rate
> >     for depreciation and amortization
> >  **/
> > double mean(income_st *income_ptr, assets *ba_ptr)
> > {
> >     double product = 1.0;
> >     double mean = 0.0;
> >     double mean_twonum1 = 0.0;
> >     double mean_twonum2 = 0.0;
> 
> Ditto.
> 
> >     if(DATA_SIZE > 0)
> >     {
> >         //Take data for each year
> >         for (int i = 1; i < DATA_SIZE; i++)
> >         {
> >             //Compute arithmetic average if negative depreciation
> >             if (income_ptr[i].dep_amor < 0)
> >                 return arithmetic_av(income_ptr, ba_ptr);
> >             
> >             mean_twonum1 = mean_twonums(ba_ptr[i-1].gross_ppe, ba_ptr[i].gross_ppe);
> >             mean_twonum2 = mean_twonums(ba_ptr[i-1].intang, ba_ptr[i].intang);
> >             
> >             if(mean_twonum1 != 0 || mean_twonum2 != 0)
> >                 product *= (1 + (income_ptr[i].dep_amor)/(mean_twonum1 + mean_twonum2) );
> >             else
> >                 product = 0.0;
> >         }
> >         if(product != 0.0)
> >             mean = pow(product, 1.0/DATA_SIZE)-1;
> 
> Really?  I don't think so but I can't guess what you meant.
Why? I don't understand your question.
For example: mean = ( (1+x) x (1+y) x (1+z) ) ^ (1/number of periods)
Actually I should have subtracted 1 from DATA_SIZE, but that gives 
a better rate, so it's better to keep it lower. It's just an assumption
to "play" around later in valuations and scenarios. 

[toc] | [prev] | [next] | [standalone]

Page 2 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