Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #64979 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-07-09 12:49 +0200 |
| Last post | 2015-07-16 09:41 +1200 |
| Articles | 20 on this page of 292 — 25 participants |
Back to article view | Back to comp.lang.c
Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 12:49 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 12:03 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 14:15 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 13:49 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:15 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:25 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:36 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:51 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:02 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:48 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-09 09:54 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 15:08 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:16 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 15:18 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:24 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:31 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:42 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 00:57 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:39 +0100
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 21:44 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 22:50 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 13:49 +0100
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 13:52 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:26 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:28 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 05:28 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:09 +0200
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-09 09:25 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 18:41 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-10 11:52 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 18:44 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-10 18:52 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 20:34 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-10 11:50 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 20:56 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-10 13:30 -0700
Re: Recursion or loop, design questions Philip Lantz <prl@canterey.us> - 2015-07-11 10:51 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 16:07 -0700
Re: Recursion or loop, design questions Philip Lantz <prl@canterey.us> - 2015-07-12 00:20 -0700
Re: Recursion or loop, design questions gordonb.j93iw@burditt.org (Gordon Burditt) - 2015-07-11 21:26 -0500
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 10:08 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 19:19 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 19:11 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:28 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 13:41 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:22 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 18:45 +0200
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-09 18:05 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:06 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 15:51 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 09:36 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-15 10:49 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-15 13:05 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:28 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 12:41 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-20 21:37 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 13:05 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 15:07 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:42 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-24 15:38 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:39 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 22:35 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 07:09 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:43 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 09:48 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:23 +0200
Re: Recursion or loop, design questions Andrew Cooper <amc96@cam.ac.uk> - 2015-07-10 00:52 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-10 01:28 +0100
Re: Recursion or loop, design questions Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 13:20 +0300
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-12 11:39 +0100
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 10:28 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-13 08:17 +1200
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 14:46 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 19:27 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-07-13 21:16 +0000
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 08:34 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 00:46 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 12:35 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 12:47 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 14:29 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 06:36 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 07:16 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 14:23 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 15:27 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 19:27 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 15:27 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 08:00 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 15:46 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:01 -0700
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:36 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 13:55 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 14:12 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 19:45 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 14:34 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 15:37 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-16 10:07 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-16 10:18 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-16 13:35 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-16 21:10 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 13:55 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-17 11:16 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 11:25 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-17 20:51 +0100
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 13:48 -0700
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 15:12 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-21 10:56 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-21 19:43 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-21 12:52 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-21 21:17 +0100
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 23:58 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:39 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-24 00:54 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 09:06 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-24 08:04 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 13:48 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-25 14:02 -0400
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 13:41 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-02 15:41 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-02 21:51 +0000
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-03 01:20 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-04 10:54 +0000
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:02 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:03 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 11:36 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 11:21 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 12:18 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:19 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:35 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 21:40 +0100
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:51 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 22:57 +0200
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-08-05 08:45 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 14:19 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:22 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 14:28 -0700
Language (was: Re: Recursion or loop, design questions) "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:35 +0200
Re: Language (was: Re: Recursion or loop, design questions) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 14:45 -0700
Re: Language "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:55 +0200
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-04 16:44 -0700
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-04 17:18 -0700
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-05 01:32 -0700
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 09:51 +0100
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 12:55 +0100
Re: Language Gareth Owen <gwowen@gmail.com> - 2015-08-05 19:12 +0100
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-06 17:09 +0100
Re: Language luser droog <luser.droog@gmail.com> - 2015-08-06 15:10 -0700
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-07 09:48 +0100
Re: Language luser droog <luser.droog@gmail.com> - 2015-08-07 13:37 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-06 10:54 +0000
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-06 13:32 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-08-06 11:06 -0400
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 11:52 -0700
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-08-06 21:19 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-08-06 17:59 -0400
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 15:54 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 12:56 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-07 23:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-08 09:27 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 01:09 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 01:34 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-08-08 13:00 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 14:22 -0700
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-08-08 16:12 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-08-08 17:31 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:34 +0000
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-09 08:38 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-09 09:31 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-09 01:52 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 04:40 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 20:19 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 23:59 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:53 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 19:43 -0700
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 20:05 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-27 23:53 +0100
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-03 01:51 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 10:04 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 21:34 +0100
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 13:52 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 21:57 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 10:44 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-18 11:00 +0100
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-18 05:25 -0500
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 14:26 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-18 17:38 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 10:05 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 21:31 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 14:28 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 15:01 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 15:39 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 15:44 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 15:55 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-19 10:58 +1200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 16:26 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 17:23 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 18:04 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 00:03 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-19 13:30 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 08:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-19 20:59 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-19 21:19 +0200
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-20 07:23 -0500
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:11 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:37 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:55 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:22 -0700
Re: Recursion or loop, design questions Gareth Owen <gwowen@gmail.com> - 2015-07-19 17:22 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 10:25 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 03:15 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-19 10:36 +0100
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 12:45 -0400
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 13:05 -0400
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 13:09 -0400
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 10:40 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-19 22:31 +0100
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:05 +0000
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-09 21:22 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-09 16:14 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 05:39 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 01:40 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-08-10 21:03 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:16 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 12:16 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:36 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 12:45 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:07 +0000
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:07 +0000
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 02:47 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-19 22:23 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 05:01 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 09:55 +1200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-19 23:13 +0100
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 10:19 +1200
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 17:21 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-20 00:25 +0100
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 11:45 +1200
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-20 02:34 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-20 10:52 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 05:31 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 22:16 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 17:24 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 22:36 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 21:07 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 02:51 -0700
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-19 10:12 -0500
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 16:54 -0500
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-20 12:34 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 07:28 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-27 11:08 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-02 14:59 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 08:40 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:05 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-19 12:46 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 12:57 -0700
Re: Recursion or loop, design questions Gareth Owen <gwowen@gmail.com> - 2015-07-19 21:16 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:50 -0700
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 09:13 -0400
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 15:04 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 12:40 -0400
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 16:27 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 14:26 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 09:58 -0400
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 15:24 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-18 10:29 -0400
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-18 17:32 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:28 -0700
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 22:58 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:13 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 21:49 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:12 -0700
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-20 15:21 -0700
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-20 15:23 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:46 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:31 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-21 04:08 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:50 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-11 18:43 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-11 18:54 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-11 13:06 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-12 23:45 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-12 17:48 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-13 01:27 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 19:39 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 14:51 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 23:51 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:04 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:36 +1200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:37 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-21 20:55 +1200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 07:39 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:41 +1200
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-18 10:44 +0100 |
| Message-ID | <87wpxxby1o.fsf@bsb.me.uk> |
| In reply to | #65777 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>I won't pretend to know what "the average programmer" is like but I will >>say that I am sceptical that you do. I will say that when I was teaching I >>never found anyone who could not pick up the idea right away. I don't >>recall it ever being seen as anything but a trivial definition that was >>easy to understand. I suspect that people who get it wrong are more >>likely simply never to have been told how to spot one. > > If this is so easy and obvious for you, than give the definition of > it. In a non-void function its a return statement whose expression is a function call. In a void function it's an expression statement that consists of nothing but a function call immediately preceding a return statement. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-18 11:00 +0100 |
| Message-ID | <mod81i$h0l$1@dont-email.me> |
| In reply to | #65838 |
On 18/07/2015 10:44, Ben Bacarisse wrote: > ram@zedat.fu-berlin.de (Stefan Ram) writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> I won't pretend to know what "the average programmer" is like but I will >>> say that I am sceptical that you do. I will say that when I was teaching I >>> never found anyone who could not pick up the idea right away. I don't >>> recall it ever being seen as anything but a trivial definition that was >>> easy to understand. I suspect that people who get it wrong are more >>> likely simply never to have been told how to spot one. >> >> If this is so easy and obvious for you, than give the definition of >> it. > > In a non-void function its a return statement whose expression is a > function call. In a void function it's an expression statement that > consists of nothing but a function call immediately preceding a return > statement. That deepens the mystery. So that final function call can be to any function, not necessarily this one, or to a chain of such function calls which come back to this one? Is it an advantage to distinguish them like this? I'd imagine it would be possible to replace such a call by a jump in some cases, thus avoiding a corresponding return, if you were to disregard the little matter of creating and disposing of the stack frame. (I sometimes use a similar idea, when writing in assembly, where each 'function' jumps to the next, and never returns. But I call it threaded code. It only works where there are no parameters and no local 'auto' variables. I also note the need you had to distinguish void and non-void functions. For this reason, I like to refer to them as procs (procedures) and functions respectively, even in C, to make it clearer what is what, as 'void' and 'non-void' are clumsy.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-18 05:25 -0500 |
| Message-ID | <r9akqa1d4cv1fc0bdbgav4l6je9q4535ce@4ax.com> |
| In reply to | #65841 |
On Sat, 18 Jul 2015 11:00:38 +0100, Bartc <bc@freeuk.com> wrote: >On 18/07/2015 10:44, Ben Bacarisse wrote: >> ram@zedat.fu-berlin.de (Stefan Ram) writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>> I won't pretend to know what "the average programmer" is like but I will >>>> say that I am sceptical that you do. I will say that when I was teaching I >>>> never found anyone who could not pick up the idea right away. I don't >>>> recall it ever being seen as anything but a trivial definition that was >>>> easy to understand. I suspect that people who get it wrong are more >>>> likely simply never to have been told how to spot one. >>> >>> If this is so easy and obvious for you, than give the definition of >>> it. >> >> In a non-void function its a return statement whose expression is a >> function call. In a void function it's an expression statement that >> consists of nothing but a function call immediately preceding a return >> statement. > >That deepens the mystery. > >So that final function call can be to any function, not necessarily this >one, or to a chain of such function calls which come back to this one? > >Is it an advantage to distinguish them like this? I'd imagine it would >be possible to replace such a call by a jump in some cases, thus >avoiding a corresponding return, if you were to disregard the little >matter of creating and disposing of the stack frame. Yes. By defining it, the programmer can rely on the optimization happening.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-18 14:26 +0100 |
| Message-ID | <87fv4lbnqj.fsf@bsb.me.uk> |
| In reply to | #65841 |
Bartc <bc@freeuk.com> writes:
> On 18/07/2015 10:44, Ben Bacarisse wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> I won't pretend to know what "the average programmer" is like but I will
>>>> say that I am sceptical that you do. I will say that when I was teaching I
>>>> never found anyone who could not pick up the idea right away. I don't
>>>> recall it ever being seen as anything but a trivial definition that was
>>>> easy to understand. I suspect that people who get it wrong are more
>>>> likely simply never to have been told how to spot one.
>>>
>>> If this is so easy and obvious for you, than give the definition of
>>> it.
>>
>> In a non-void function its a return statement whose expression is a
>> function call. In a void function it's an expression statement that
>> consists of nothing but a function call immediately preceding a return
>> statement.
>
> That deepens the mystery.
>
> So that final function call can be to any function, not necessarily
> this one, or to a chain of such function calls which come back to this
> one?
Just as there are function calls and recursive function calls, there are
tail calls and recursive tail calls. How does explaining something
deepen the mystery, especially as I've said this before?
> Is it an advantage to distinguish them like this?
Yes, it avoids needlessly emphasising one particular case. If a
compiler (or language) promises to optimise tail calls then mutually
recursive tail calls come for free.
I just went back to check and I see that I said all this in my reply to
you of the 16th ("Eliminating a tail call is a useful optimisation even
when the call is not a recursive one, not least because you don't need
to check for mutual recursion."). I even gave an explicit example of a
non-recursive tail call. Now maybe you did not read that reply; maybe I
explained it very badly; maybe Malcolm is right and it just "too hard to
know" but given your love of polemic I suspect you being a tad
disingenuous.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-18 17:38 +0100 |
| Message-ID | <modvau$ubb$1@dont-email.me> |
| In reply to | #65847 |
On 18/07/2015 14:26, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>> Is it an advantage to distinguish them like this?
>
> Yes, it avoids needlessly emphasising one particular case. If a
> compiler (or language) promises to optimise tail calls then mutually
> recursive tail calls come for free.
>
> I just went back to check and I see that I said all this in my reply to
> you of the 16th ("Eliminating a tail call is a useful optimisation even
> when the call is not a recursive one, not least because you don't need
> to check for mutual recursion.").
I've read it again now. Maybe it didn't register because I was still
reeling from your comment that 'return 1+my_strlen()' didn't count as
tail recursion. (Which I understand now; sort of.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-18 10:05 -0700 |
| Message-ID | <644aa8d6-46f4-474f-a668-a5a8990f37e2@googlegroups.com> |
| In reply to | #65841 |
On Saturday, July 18, 2015 at 11:00:55 AM UTC+1, Bart wrote:
>
> > In a non-void function its a return statement whose expression is a
> > function call. In a void function it's an expression statement that
> > consists of nothing but a function call immediately preceding a return
> > statement.
>
> That deepens the mystery.
>
> So that final function call can be to any function, not necessarily this
> one, or to a chain of such function calls which come back to this one?
>
It's not that hard. The question is,, when you can replace simple
recursion by a loop, or mututal recursion, or even a simple function
call, by a jump.
Obviously if you like writing lots of little trivial functions you
can inline them
x = max(a, b)
can be replaced by
x = a > b ? a : b;
but that's not what we're after. Consider something more realistic, we
have atree with "left" and "right" children. We want to count the nodes.
so int countnodes(NODE *root)
{
if(!root)
return 0;
else return countnodes(root->left) + countnodes(root->right) + 1;
}
that's not tail recursive. It looks like it ought to be, because
the class are at the tail. But the return isn't a single call.
we can write it like this.
void countnodes(NODE *root, int *N)
{
if(root)
{
(*N)++;
countnodes(root->left, N);
countnodes(root->right, N);
}
}
now the last call can be optimised away to to a jump. Let's do it.
void countnodes(NODE *root, int *N)
{
Ilovetailrecursion:
if(root)
{
(*N)++;
countnodes(root->left, N);
root = nodes->right;
goto Ilovetailrecursion;
}
}
if we try to optimise out the first call, however, we run into problems.
We've destroyed the root pointer. The only way of doing it is to
store a series of pointers leading back to the root, which the call
stack does for you, for free.
However using a pointer is kind of cluntsy. So functional programming
language will let you do something along the lines of
int countnodes(root)
{
if(root is null) return 0;
return sum(1, countnodes(root->left), countnodes(root->right) );
}
In C, that's not tail recursive, because countnodes must be called
before sum. In functional programming, sum is called first, then it
evaluates its arguments.
That's the trick. It's not that hard, but it's counter-intuitive,
it doesn't match the way most people think about programming,
which is following a list of instructions, like a cooking
recipe, not specifying an expression to evaluate.
>
> Is it an advantage to distinguish them like this? I'd imagine it would
> be possible to replace such a call by a jump in some cases, thus
> avoiding a corresponding return, if you were to disregard the little
> matter of creating and disposing of the stack frame.
>
> (I sometimes use a similar idea, when writing in assembly, where each
> 'function' jumps to the next, and never returns. But I call it threaded
> code. It only works where there are no parameters and no local 'auto'
> variables.
>
It's worth getting a handle on functional programming. It's the flavour
of the month. Tail recursion is really a weakness of the paradigm,
the power and dynamic of it is that you forget about the underlying
machine. It's just a concession that has to be made to the fact
that calls are expensive and stacks limited.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-18 21:31 +0100 |
| Message-ID | <87380l9pi7.fsf@bsb.me.uk> |
| In reply to | #65856 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 18, 2015 at 11:00:55 AM UTC+1, Bart wrote:
>>
>> > In a non-void function its a return statement whose expression is a
>> > function call. In a void function it's an expression statement that
>> > consists of nothing but a function call immediately preceding a return
>> > statement.
>>
>> That deepens the mystery.
>>
>> So that final function call can be to any function, not necessarily this
>> one, or to a chain of such function calls which come back to this one?
>>
> It's not that hard.
>
> [...] Consider something more realistic, we
> have atree with "left" and "right" children. We want to count the nodes.
>
> so int countnodes(NODE *root)
> {
> if(!root)
> return 0;
> else return countnodes(root->left) + countnodes(root->right) + 1;
> }
>
> that's not tail recursive. It looks like it ought to be, because
> the class are at the tail. But the return isn't a single call.
>
> we can write it like this.
>
> void countnodes(NODE *root, int *N)
> {
> if(root)
> {
> (*N)++;
> countnodes(root->left, N);
> countnodes(root->right, N);
> }
> }
It's less clunky to use an int parameter:
int countnodes(NODE *tree, int n)
{
if (tree)
return countnodes(tree->right, countnodes(tree->left, n) + 1);
else return n;
}
> now the last call can be optimised away to to a jump. Let's do it.
>
> void countnodes(NODE *root, int *N)
> {
> Ilovetailrecursion:
> if(root)
> {
> (*N)++;
> countnodes(root->left, N);
> root = nodes->right;
> goto Ilovetailrecursion;
> }
> }
in my version you get:
int countnodes(NODE *tree, int n)
{
countnodes:
if (tree) {
n = countnodes(tree->left, n) + 1;
tree = tree->right;
goto countnodes;
}
return n;
}
> if we try to optimise out the first call, however, we run into problems.
> We've destroyed the root pointer. The only way of doing it is to
> store a series of pointers leading back to the root, which the call
> stack does for you, for free.
>
> However using a pointer is kind of cluntsy. So functional programming
> language will let you do something along the lines of
>
> int countnodes(root)
> {
> if(root is null) return 0;
> return sum(1, countnodes(root->left), countnodes(root->right) );
> }
>
> In C, that's not tail recursive, because countnodes must be called
> before sum.
That's not a tail call in any language.
> In functional programming, sum is called first, then it
> evaluates its arguments.
No, that's just wrong. That's wrong as a general statement about
functional programming, and it's wrong as an attempt to suggest that
the syntax above is a tail call.
> That's the trick. It's not that hard, but it's counter-intuitive,
> it doesn't match the way most people think about programming,
> which is following a list of instructions, like a cooking
> recipe, not specifying an expression to evaluate.
No, that's not the trick. There is no trick. To a first approximation,
the notion of a tail call is the same way in functional and
non-functional languages.
<snip>
> It's worth getting a handle on functional programming. It's the flavour
> of the month. Tail recursion is really a weakness of the paradigm,
> the power and dynamic of it is that you forget about the underlying
> machine. It's just a concession that has to be made to the fact
> that calls are expensive and stacks limited.
I don't think you are well-placed to offer a critique the functional
paradigm.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-18 14:28 -0700 |
| Message-ID | <e99ae7b2-ed07-4cd3-b321-9ae102818b23@googlegroups.com> |
| In reply to | #65862 |
On Saturday, July 18, 2015 at 9:31:44 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > However using a pointer is kind of cluntsy. So functional programming
> > language will let you do something along the lines of
> >
> > int countnodes(root)
> > {
> > if(root is null) return 0;
> > return sum(1, countnodes(root->left), countnodes(root->right) );
> > }
> >
> > In C, that's not tail recursive, because countnodes must be called
> > before sum.
>
> That's not a tail call in any language.
>
From Ben:
[defining tail recursion]
In a non-void function its a return statement whose expression is a
function call. In a void function it's an expression statement that
consists of nothing but a function call immediately preceding a return
statement.
>
So you need to clarify your ideas.
And certainly I think it's time to admit that this stuff is too
complicated for the general programmer.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-18 15:01 -0700 |
| Message-ID | <lntwt1gm77.fsf@kst-u.example.com> |
| In reply to | #65865 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 18, 2015 at 9:31:44 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > However using a pointer is kind of cluntsy. So functional programming
>> > language will let you do something along the lines of
>> >
>> > int countnodes(root)
>> > {
>> > if(root is null) return 0;
>> > return sum(1, countnodes(root->left), countnodes(root->right) );
>> > }
>> >
>> > In C, that's not tail recursive, because countnodes must be called
>> > before sum.
>>
>> That's not a tail call in any language.
>>
>
> From Ben:
> [defining tail recursion]
> In a non-void function its a return statement whose expression is a
> function call. In a void function it's an expression statement that
> consists of nothing but a function call immediately preceding a return
> statement.
By that definition, the call to sum() is a tail call, but it's not tail
recursive. The (recursive) calls to countnodes() are not tail calls.
> So you need to clarify your ideas.
> And certainly I think it's time to admit that this stuff is too
> complicated for the general programmer.
I think not.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-18 15:39 -0700 |
| Message-ID | <f8dd2be6-8384-4105-b8fb-57da9e528f07@googlegroups.com> |
| In reply to | #65867 |
On Saturday, July 18, 2015 at 11:01:12 PM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > On Saturday, July 18, 2015 at 9:31:44 PM UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>
> >> > However using a pointer is kind of cluntsy. So functional programming
> >> > language will let you do something along the lines of
> >> >
> >> > int countnodes(root)
> >> > {
> >> > if(root is null) return 0;
> >> > return sum(1, countnodes(root->left), countnodes(root->right) );
> >> > }
> >> >
> >> > In C, that's not tail recursive, because countnodes must be called
> >> > before sum.
> >>
> >> That's not a tail call in any language.
> >>
> >
> > From Ben:
> > [defining tail recursion]
> > In a non-void function its a return statement whose expression is a
> > function call. In a void function it's an expression statement that
> > consists of nothing but a function call immediately preceding a return
> > statement.
>
> By that definition, the call to sum() is a tail call, but it's not tail
> recursive. The (recursive) calls to countnodes() are not tail calls.
>
In C, it isn't. Because the two recursive calls must be made before
the call to sum(). But if we devise a language which calls sum,
the calls the arguments, then that objection disappears, it's
a case of two mutually recursive functions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-18 15:44 -0700 |
| Message-ID | <lnpp3pgk6o.fsf@kst-u.example.com> |
| In reply to | #65868 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 18, 2015 at 11:01:12 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > On Saturday, July 18, 2015 at 9:31:44 PM UTC+1, Ben Bacarisse wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >>
>> >> > However using a pointer is kind of cluntsy. So functional programming
>> >> > language will let you do something along the lines of
>> >> >
>> >> > int countnodes(root)
>> >> > {
>> >> > if(root is null) return 0;
>> >> > return sum(1, countnodes(root->left), countnodes(root->right) );
>> >> > }
>> >> >
>> >> > In C, that's not tail recursive, because countnodes must be called
>> >> > before sum.
>> >>
>> >> That's not a tail call in any language.
>> >>
>> >
>> > From Ben:
>> > [defining tail recursion]
>> > In a non-void function its a return statement whose expression is a
>> > function call. In a void function it's an expression statement that
>> > consists of nothing but a function call immediately preceding a return
>> > statement.
>>
>> By that definition, the call to sum() is a tail call, but it's not tail
>> recursive. The (recursive) calls to countnodes() are not tail calls.
>>
> In C, it isn't.
What isn't what?
> Because the two recursive calls must be made before
> the call to sum(). But if we devise a language which calls sum,
> the calls the arguments, then that objection disappears, it's
> a case of two mutually recursive functions.
You're suggesting a language in which a function is called before its
arguments are evaluated? I fail to see how that could make sense.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-18 15:55 -0700 |
| Message-ID | <e2e94f5f-00d8-4daa-80e4-81bb1603e8f2@googlegroups.com> |
| In reply to | #65869 |
On Saturday, July 18, 2015 at 11:44:40 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > You're suggesting a language in which a function is called before its > arguments are evaluated? I fail to see how that could make sense. > There are two approaches. The C way is to say that the programmer has called foo with 2 =2 foo(2+2); Ok, says the compiler. 2 +4 make 4. So what I'll do is generate a call to foo with 4. The other way is to say the programmer has called foo with 2+2. Ok, says the compiler. foo takes the parameter foo(x). So, anywhere I see x in foo, I'll replace it with 2+2. For simple functions, it makes no difference. But the second method is more powerful if you want to do fancy things.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-19 10:58 +1200 |
| Message-ID | <d1041eF4ji9U4@mid.individual.net> |
| In reply to | #65870 |
Malcolm McLean wrote: > On Saturday, July 18, 2015 at 11:44:40 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> >> You're suggesting a language in which a function is called before its >> arguments are evaluated? I fail to see how that could make sense. >> > There are two approaches. > > The C way is to say that the programmer has called foo with 2 =2 > > foo(2+2); > > Ok, says the compiler. 2 +4 make 4. So what I'll do is generate a > call to foo with 4. > > The other way is to say the programmer has called foo with 2+2. > > Ok, says the compiler. foo takes the parameter foo(x). So, anywhere > I see x in foo, I'll replace it with 2+2. In other words, a macro. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-18 16:26 -0700 |
| Message-ID | <lnlhedgi82.fsf@kst-u.example.com> |
| In reply to | #65870 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, July 18, 2015 at 11:44:40 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>
>> You're suggesting a language in which a function is called before its
>> arguments are evaluated? I fail to see how that could make sense.
>>
> There are two approaches.
>
> The C way is to say that the programmer has called foo with 2 =2
>
> foo(2+2);
>
> Ok, says the compiler. 2 +4 make 4. So what I'll do is generate a
> call to foo with 4.
>
> The other way is to say the programmer has called foo with 2+2.
>
> Ok, says the compiler. foo takes the parameter foo(x). So, anywhere
> I see x in foo, I'll replace it with 2+2.
>
> For simple functions, it makes no difference. But the second method
> is more powerful if you want to do fancy things.
You're talking about call-by-name (which C doesn't support, though you
can emulate it with function pointers).
Still, in the case of a call like f(g(), h()), the calls to g() and h()
still must occur before f() returns (assuming f refers to its
arguments), so it still wouldn't make for a tail-recursive call.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-18 17:23 -0700 |
| Message-ID | <333c8704-4b99-4cc2-bcf1-bf920edc1d6d@googlegroups.com> |
| In reply to | #65873 |
On Sunday, July 19, 2015 at 12:27:00 AM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>
> Still, in the case of a call like f(g(), h()), the calls to g() and h()
> still must occur before f() returns (assuming f refers to its
> arguments), so it still wouldn't make for a tail-recursive call.
>
If we've got this
int foo()
{
if(condition)
return 0;
return bar(foo(), foo());
}
and
bar is
int bar(a, b)
{
return a + b;
}
then it can affect the optimisation.
bar becomes
int bar( ... )
{
return foo() + foo();
}
So the last foo() call can be optimised out to a jump.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-18 18:04 -0700 |
| Message-ID | <lnh9p1gdpf.fsf@kst-u.example.com> |
| In reply to | #65874 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, July 19, 2015 at 12:27:00 AM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> Still, in the case of a call like f(g(), h()), the calls to g() and h()
>> still must occur before f() returns (assuming f refers to its
>> arguments), so it still wouldn't make for a tail-recursive call.
>>
> If we've got this
>
> int foo()
> {
> if(condition)
> return 0;
>
> return bar(foo(), foo());
> }
>
> and
> bar is
>
> int bar(a, b)
> {
> return a + b;
> }
>
> then it can affect the optimisation.
>
>
> bar becomes
>
> int bar( ... )
> {
> return foo() + foo();
> }
>
> So the last foo() call can be optimised out to a jump.
Sure, a program without at tail call can sometimes be transformed to an
equivalent program with a tail call. I don't think that has much
bearing on determining what a tail call is.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-19 00:03 -0700 |
| Message-ID | <2c1a35d5-f9c8-41e3-bfa4-4c51218aa443@googlegroups.com> |
| In reply to | #65876 |
On Sunday, July 19, 2015 at 2:04:38 AM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Sure, a program without at tail call can sometimes be transformed to an > equivalent program with a tail call. I don't think that has much > bearing on determining what a tail call is. > That's the crux of the issue. Let's say that hardware was designed specifically for functional languages, as indeed it was in the early days of computing, with a few Lisp machines being built. Stacks would be massive and function calls would be extremely cheap. There'd be no real advantage in transforming recursion into iteration, and no one would worry about tail recursion. Now lets say that God waved a magic wand and changed mathematics (we can debate whether God can do this elsewhere, let's assume for the sake of argument that He can). Now, it's not possible to transform a non-tail recursive program into a tail-recursive one or vice versa. So, again, there's no point in worrying about it, the tail recursive functions are more efficient, but that's like saying addition is more efficient than taking the logarithm - true, but not much use to someone who needs to optimise a call to log(x) in his program. Tail recursion is more efficient than normal recursion, and many programs can be rewritten by human programmers to become tail recursive, without too much restructuring. That's the whole situation. The real answer is to iterate over the next pointers and recurse over the child pointers. That's fine for C, and it usually works because very few legitimate structures have deep children, many have many hundreds of siblings. But no compiler can know that, and human genealogical trees are a partial exception. (Most people have more known ancestors than brothers or sisters, but no-one can trace their ancestry back more than a hundred or so generations, so you can't blow a stack except on a tiny system).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-19 13:30 +0100 |
| Message-ID | <87zj2s72io.fsf@bsb.me.uk> |
| In reply to | #65884 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, July 19, 2015 at 2:04:38 AM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> Sure, a program without at tail call can sometimes be transformed to an >> equivalent program with a tail call. I don't think that has much >> bearing on determining what a tail call is. >> > That's the crux of the issue. > Let's say that hardware was designed specifically for functional > languages, as indeed it was in the early days of computing, with > a few Lisp machines being built. Stacks would be massive and function > calls would be extremely cheap. There'd be no real advantage in > transforming recursion into iteration, and no one would worry about > tail recursion. That wrong. It's wrong in so many ways, but all of them are also very much off-topic. Is there any chance you can be persuaded not to make pronouncements about things you don't know much about? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-19 08:45 -0700 |
| Message-ID | <965a140c-05e7-485d-8f21-bda129cf8650@googlegroups.com> |
| In reply to | #65895 |
On Sunday, July 19, 2015 at 1:31:05 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > That wrong. It's wrong in so many ways, but all of them are also very > much off-topic. Is there any chance you can be persuaded not to make > pronouncements about things you don't know much about? > You give a definition of tail recursion, then contradict yourself. Then you say "that's not the trick" so I pretty clearly (to my mind at least) show how the "trick" transforms something which can't be trivially turned into a jump into something which can be, and we don't get any response. I'm not a great fan of functional programming, but I have written a toy Lisp interpreter (like everyone else who leafs through a Lisp primer, it's pretty much the natural first response to say "cool", I can knock up an intepreter for this, I'm not claiming anything exceptional here). It's not that I know nothing. Myers explained it thus: I have considered the impudent accusations of Mr Dawkins with exasperation at his lack of serious scholarship. He has apparently not read the detailed discourses of Count Roderigo of Seville on the exquisite and exotic leathers of the Emperor's boots, nor does he give a moment's consideration to Bellini's masterwork, On the Luminescence of the Emperor's Feathered Hat. We have entire schools dedicated to writing learned treatises on the beauty of the Emperor's raiment, and every major newspaper runs a section dedicated to imperial fashion; Dawkins cavalierly dismisses them all. He even laughs at the highly popular and most persuasive arguments of his fellow countryman, Lord D. T. Mawkscribbler, who famously pointed out that the Emperor would not wear common cotton, nor uncomfortable polyester, but must, I say must, wear undergarments of the finest silk. Dawkins arrogantly ignores all these deep philosophical ponderings to crudely accuse the Emperor of nudity
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-19 20:59 +0200 |
| Message-ID | <mogs2l$tme$1@speranza.aioe.org> |
| In reply to | #65898 |
On 07/19/2015 05:45 PM, Malcolm McLean wrote: > On Sunday, July 19, 2015 at 1:31:05 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> That wrong. It's wrong in so many ways, but all of them are also very >> much off-topic. Is there any chance you can be persuaded not to make >> pronouncements about things you don't know much about? >> > You give a definition of tail recursion, then contradict yourself. > Then you say "that's not the trick" so I pretty clearly (to my > mind at least) show how the "trick" transforms something which can't > be trivially turned into a jump into something which can be, > and we don't get any response. > > I'm not a great fan of functional programming, but I have written > a toy Lisp interpreter (like everyone else who leafs through > a Lisp primer, it's pretty much the natural first response > to say "cool", I can knock up an intepreter for this, I'm not > claiming anything exceptional here). It's not that I know > nothing. Well, what I've gathered from all of this and doing some googling is that tail recursion can also be implemented as a loop and that "good optimizing compilers" should convert tail recursion code into a loop. A loop that in its simplest form is a implemented using a goto. And that it might be easier to debug code if it is written with recursion. If performance or security is an issue, loops are the right choice. In my case then, since security is important and blowing the stack has undefined results, the final code should be written using a loop. But, it might be easier in the development and debugging phase to write the code using recursion. -Morten
[toc] | [prev] | [next] | [standalone]
Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web