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 6 of 15 — ← Prev page 1 … 4 5 [6] 7 8 … 15 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-17 11:16 -0700 |
| Message-ID | <67494740-17db-4055-8206-9e67b5612caa@googlegroups.com> |
| In reply to | #65777 |
On Friday, July 17, 2015 at 1:55:36 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> 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. > > I note your careful wording: too hard to know. Do you think the > average programmer could not learn what a tail call is in a matter > of minutes? That's the measure of how hard it is: know what the > average programmer knows, but what they can learn. > Bart is, in my view, way above average as a programmer. Implementing interpreters isn't an entry-level programming task. You'd also expect a person with such an interest to have an openness and receptiveness to new languages. But he got it wrong. He got it wrong. The point is that functional languages, as far as I'm aware, aren't designed with the difference between tail recursion and normal in mind. They don't make a syntactical distinction, because, as far as correctness is concerned, that doesn't matter. And functional programming is driven by considerations of correctness over efficiency. It's harder to have a post error in a functional language. In C, it's very easy to write i = N where you meant N - 1.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-17 11:25 -0700 |
| Message-ID | <lnpp3qiqur.fsf@kst-u.example.com> |
| In reply to | #65796 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> But he got it wrong. He got it wrong. The point is that functional
> languages, as far as I'm aware, aren't designed with the difference
> between tail recursion and normal in mind. They don't make a syntactical
> distinction, because, as far as correctness is concerned, that
> doesn't matter.
Scheme implementations are required by the language standard to be
"properly tail-recursive".
https://people.csail.mit.edu/jaffer/r5rs_5.html#SEC23
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-17 20:51 +0100 |
| Message-ID | <mobm9d$87o$1@dont-email.me> |
| In reply to | #65796 |
On 17/07/2015 19:16, Malcolm McLean wrote: > On Friday, July 17, 2015 at 1:55:36 PM UTC+1, Ben Bacarisse wrote: >> I note your careful wording: too hard to know. Do you think the >> average programmer could not learn what a tail call is in a matter >> of minutes? (Why would they need to?) > [Bart] ... You'd also expect > a person with such an interest to have an openness and receptiveness > to new languages. Not necessarily... > But he got it wrong. He got it wrong. The point is that functional > languages, as far as I'm aware, aren't designed with the difference > between tail recursion and normal in mind. They don't make a syntactical > distinction, because, as far as correctness is concerned, that > doesn't matter. I've never properly understood what tail recursion is, and I probably still don't. I don't get why people think it's such a big deal. You can look at some recursive functions, and say they are use tail recursion or they don't, but, so what? It might give you some easy optimisation in a small number of cases (in my sort of code, usually in some silly benchmark), but I can't see myself getting excited about it. And isn't that a compiler's job anyway? (Actually, in benchmarks I'd prefer it wasn't optimised, if the purpose of the test is to find out how well large numbers of recursive calls are handled; you don't want them eliminated!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-17 13:48 -0700 |
| Message-ID | <lnh9p2ik7o.fsf@kst-u.example.com> |
| In reply to | #65806 |
Bartc <bc@freeuk.com> writes:
[...]
> I've never properly understood what tail recursion is, and I probably
> still don't. I don't get why people think it's such a big deal. You can
> look at some recursive functions, and say they are use tail recursion or
> they don't, but, so what?
Scheme, for example, defines what is or is not a tail recursive call,
and requires the implementation to optimize such calls to an iterative
form. As a result, you can safely write a tail-recursive routine that
would overflow the stack if the generated code actually used recursion
(because it goes, say, a million or a billion calls deep).
C has no such definition or guarantee, and really deeply recursive calls
are rarer in C than in function languages, but it's still a useful
optimization.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-07-21 15:12 +0200 |
| Message-ID | <molgct$7ao$1@dont-email.me> |
| In reply to | #65806 |
On 17/07/15 21:51, Bartc wrote: > On 17/07/2015 19:16, Malcolm McLean wrote: >> On Friday, July 17, 2015 at 1:55:36 PM UTC+1, Ben Bacarisse wrote: > >>> I note your careful wording: too hard to know. Do you think the >>> average programmer could not learn what a tail call is in a matter >>> of minutes? > > (Why would they need to?) > >> [Bart] ... You'd also expect >> a person with such an interest to have an openness and receptiveness >> to new languages. > > Not necessarily... > >> But he got it wrong. He got it wrong. The point is that functional >> languages, as far as I'm aware, aren't designed with the difference >> between tail recursion and normal in mind. They don't make a syntactical >> distinction, because, as far as correctness is concerned, that >> doesn't matter. > > I've never properly understood what tail recursion is, and I probably > still don't. I don't get why people think it's such a big deal. You can > look at some recursive functions, and say they are use tail recursion or > they don't, but, so what? Tail recursion is quite simple - if a function ends in a call to itself, with no processing done after that call, then it is tail recursive. (There will usually also be other means to return from the function, to avoid infinite loops.) Basically, if you've got the assembly : foo: ... // Simple non-recursive code and conditional return call foo ret Then you have tail recursion. The "call foo; ret" can be replaced with "jmp foo". Why is tail recursion important? It's just because it is easy for a compiler to turn it into an iterative loop for efficiency. As we saw from your example, recursive functions may still sometimes be turned into loops by a smart enough compiler - but if the function is written as a tail recursion, you can be sure that the transformation is possible. (See <https://en.wikipedia.org/wiki/Tail_call> - the transformation done by gcc to turn your recursion into iteration is equivalent to the "Tail recursion modulo cons" described here.) > > It might give you some easy optimisation in a small number of cases (in > my sort of code, usually in some silly benchmark), but I can't see > myself getting excited about it. And isn't that a compiler's job anyway? > Usually the best development method (following Heathfield's law) is to write the code clearly and correctly, and if it is too slow in practice then you can fiddle with it until it runs faster. If the recursion is easily converted to iteration, then gcc (with high enough optimisation level) or other good compilers can usually do the job, saving you the effort. > (Actually, in benchmarks I'd prefer it wasn't optimised, if the purpose > of the test is to find out how well large numbers of recursive calls are > handled; you don't want them eliminated!) >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-21 10:56 -0700 |
| Message-ID | <58970dbb-ebce-4eb3-8fc8-14861f37c0f5@googlegroups.com> |
| In reply to | #66108 |
On Tuesday, July 21, 2015 at 2:12:41 PM UTC+1, David Brown wrote: > > Usually the best development method (following Heathfield's law) is to > write the code clearly and correctly, and if it is too slow in practice > then you can fiddle with it until it runs faster. If the recursion is > easily converted to iteration, then gcc (with high enough optimisation > level) or other good compilers can usually do the job, saving you the > effort. > Heathfield's law is pretty good, but recursion is a bit of an exception. it's easy enough to write recursive solutions that work reasonably well on medium sized inputs, but blow the stack when the input gets large. The real rule is to remember that if you recurse, it's over a tree. Any anary tree can be converted to a binary tree by renaming the the pointers child, and next, and adding an additional link. That covers the vast majority of situations, except a few complex graph problems where we've got to consider cycles. All other recursion is over binary trees. Now you've got several situations. The first is that the tree is degenerate tree that consists either all of siblings or all of single descendants. In that case, don't recurse, iterate through the list. The second is that you've got a roughly balanced binary tree. So recurse down left and right, and let the compiler worry about optimisation. Depth is log(N) so you are safe (as long as the tree is vanishingly unlikely to be degenerate). The third is that you've got an xml-type structure with lots of siblings and only a few children. So iterate over the siblings and recurse over the children. The fourth is that you've got a git commit-type tree, with lots of single children and only a few siblings. So iterate over the children and recurse over the siblings. The last is you don't know, and I'm not sure what the best strategy is there. But those are the possibilities, and the answers are not difficult.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-21 19:43 +0100 |
| Message-ID | <mom3p5$o45$1@dont-email.me> |
| In reply to | #66117 |
On 21/07/15 18:56, Malcolm McLean wrote: > On Tuesday, July 21, 2015 at 2:12:41 PM UTC+1, David Brown wrote: >> >> Usually the best development method (following Heathfield's law) is to >> write the code clearly and correctly, and if it is too slow in practice >> then you can fiddle with it until it runs faster. If the recursion is >> easily converted to iteration, then gcc (with high enough optimisation >> level) or other good compilers can usually do the job, saving you the >> effort. >> > Heathfield's law I can't help liking the sound of that. > is pretty good, but recursion is a bit of an exception. I disagree. Heathfield's Law, roughly stated, is that readability trumps correctness and correctness trumps speed (on the grounds that it's easier to fix readable programs than to make working programs readable, and it's easier to speed up correct programs than it is to fix fast programs). Let's see where that takes us with recursion: > it's easy enough to write recursive solutions that work reasonably > well on medium sized inputs, but blow the stack when the input gets > large. So use big test cases. > The real rule is to remember that if you recurse, it's over a tree. If that's true, it's also true that if you iterate, it's over a tree. So it doesn't really move us on. What is worse, your use of the words "the real rule" suggests (in the context in which you used it) that you think that "remember that if you recurse, it's over a tree" is an improvement on "favour readability over correctness, and correctness over performance". I suspect that this is due to sloppy editing, because I don't think you would wish to try justifying any logical connection between those two statements. > Any anary tree can be converted to a binary tree by renaming > the the pointers child, and next, and adding an additional link. > That covers the vast majority of situations, except a few complex > graph problems where we've got to consider cycles. All other > recursion is over binary trees. It's probably truer to say that recursion explores a solution space that can (if desired) be expressed as a graph. If that graph happens to be acyclic, then it can be thought of as a tree, yes, but I'm not sure I'd want to defend the claim that most graphs are acyclic. <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]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-21 12:52 -0700 |
| Message-ID | <5d00d598-093b-4d37-b260-e361aa34b01d@googlegroups.com> |
| In reply to | #66119 |
On Tuesday, July 21, 2015 at 7:43:22 PM UTC+1, Richard Heathfield wrote: > On 21/07/15 18:56, Malcolm McLean wrote: > > > Heathfield's law > > I can't help liking the sound of that. > > > is pretty good, but recursion is a bit of an exception. > > I disagree. Heathfield's Law, roughly stated, is that readability trumps > correctness and correctness trumps speed (on the grounds that it's > easier to fix readable programs than to make working programs readable, > and it's easier to speed up correct programs than it is to fix fast > programs). Let's see where that takes us with recursion: > > > it's easy enough to write recursive solutions that work reasonably > > well on medium sized inputs, but blow the stack when the input gets > > large. > > So use big test cases. > > > The real rule is to remember that if you recurse, it's over a tree. > > If that's true, it's also true that if you iterate, it's over a tree. So > it doesn't really move us on. What is worse, your use of the words "the > real rule" suggests (in the context in which you used it) that you think > that "remember that if you recurse, it's over a tree" is an improvement > on "favour readability over correctness, and correctness over > performance". I suspect that this is due to sloppy editing, because I > don't think you would wish to try justifying any logical connection > between those two statements. > Malcolm's rule is "iterate over the major axis (children for a tall tree, siblings for a short one), recurse over the minor axis. Heathfield's is "write the function in the clearest way possible". The rules can contradict - that's not to say that we can't see the sense in both, but where there's a contradiction we must chose one. > > > Any anary tree can be converted to a binary tree by renaming > > the the pointers child, and next, and adding an additional link. > > That covers the vast majority of situations, except a few complex > > graph problems where we've got to consider cycles. All other > > recursion is over binary trees. > > It's probably truer to say that recursion explores a solution space that > can (if desired) be expressed as a graph. If that graph happens to be > acyclic, then it can be thought of as a tree, yes, but I'm not sure I'd > want to defend the claim that most graphs are acyclic. > Problems with cyclic graphs tend to be too hard to solve easily. A lot of graphs are cyclic, e.g. the road network, but the problems aren't. Generally if someone presents you with a road map they'll want to know the shortest route from A to B. However that route can never contain a cycle. Once you allow cyclic solutions as well the problem either becomes totally trivial (cycle between the best two nodes), or very hard indeed (what's the shortest route that visits all cities on a road network, rather than just the shortest path from A to B).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-21 21:17 +0100 |
| Message-ID | <mom99j$elg$1@dont-email.me> |
| In reply to | #66123 |
On 21/07/15 20:52, Malcolm McLean wrote:
> On Tuesday, July 21, 2015 at 7:43:22 PM UTC+1, Richard Heathfield wrote:
>> On 21/07/15 18:56, Malcolm McLean wrote:
>>
>> > Heathfield's law
>>
>> I can't help liking the sound of that.
>>
>> > is pretty good, but recursion is a bit of an exception.
>>
>> I disagree. Heathfield's Law, roughly stated, is that readability trumps
>> correctness and correctness trumps speed (on the grounds that it's
>> easier to fix readable programs than to make working programs readable,
>> and it's easier to speed up correct programs than it is to fix fast
>> programs). Let's see where that takes us with recursion:
>>
>> > it's easy enough to write recursive solutions that work reasonably
>> > well on medium sized inputs, but blow the stack when the input gets
>> > large.
>>
>> So use big test cases.
>>
>> > The real rule is to remember that if you recurse, it's over a tree.
>>
>> If that's true, it's also true that if you iterate, it's over a tree. So
>> it doesn't really move us on. What is worse, your use of the words "the
>> real rule" suggests (in the context in which you used it) that you think
>> that "remember that if you recurse, it's over a tree" is an improvement
>> on "favour readability over correctness, and correctness over
>> performance". I suspect that this is due to sloppy editing, because I
>> don't think you would wish to try justifying any logical connection
>> between those two statements.
>>
> Malcolm's rule is "iterate over the major axis (children for a
> tall tree, siblings for a short one), recurse over the minor axis.
> Heathfield's is "write the function in the clearest way possible".
> The rules can contradict - that's not to say that we can't see
> the sense in both, but where there's a contradiction we must
> chose one.
There are a couple of *very* important things about Heathfield's Law
that I ought to clarify:
1) it is given that we have put some thought into appropriate data
structures and algorithms - we don't just write void foo(void){} on the
grounds that it's hard to write a clearer function! We expect the
function to /do the job/, and do it well. But the emphasis is on
clarity, rather than on "getting it working" first (because, once it
/is/ working, we're not motivated to make it readable, and we'll pay for
that when we have to maintain it). If we are addressing a
recursively-defined data structure such as your sibling/child model,
then we would expect to choose an appropriate model for addressing that
data structure, which may well be to iterate over the major axis (as you
put it) and recurse into the minor one.
2) having written our clear function, *then* we test, and fix as
required, *while keeping it readable*. (And *then* we look at the
performance.)
Given those two facts, I see no contradiction between Heathfield's Law
and McLean's Rule.
>> > Any anary tree can be converted to a binary tree by renaming
>> > the the pointers child, and next, and adding an additional link.
>> > That covers the vast majority of situations, except a few complex
>> > graph problems where we've got to consider cycles. All other
>> > recursion is over binary trees.
>>
>> It's probably truer to say that recursion explores a solution space that
>> can (if desired) be expressed as a graph. If that graph happens to be
>> acyclic, then it can be thought of as a tree, yes, but I'm not sure I'd
>> want to defend the claim that most graphs are acyclic.
>>
> Problems with cyclic graphs tend to be too hard to solve easily.
That's a relief. It would be dreadful if they were too easy to solve
easily. :-)
> A lot of graphs are cyclic, e.g. the road network, but the problems
> aren't. Generally if someone presents you with a road map they'll
> want to know the shortest route from A to B. However that route
> can never contain a cycle.
Haven't you noticed? The roads are full of them nowadays. More
seriously, when you're trying to find a route, you have to deal with the
fact that the cycles are there, even though your solution won't contain
one. (I just spent far too long trying to imagine a shortest route that
/could/ contain a cycle.) So your algorithm has to cope with the fact
that you might encounter cycles - you can't, for example, just keep
turning left without checking that you haven't come back to your
starting point.
> Once you allow cyclic solutions as
> well the problem either becomes totally trivial (cycle between
> the best two nodes), or very hard indeed (what's the shortest
> route that visits all cities on a road network, rather than
> just the shortest path from A to B).
TSP isn't actually very hard at all, provided you're happy to accept a
"good enough" solution rather than the perfect shortest route.
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-07-21 23:58 +0200 |
| Message-ID | <momf6r$3b9$1@dont-email.me> |
| In reply to | #66119 |
On 21/07/15 20:43, Richard Heathfield wrote: > On 21/07/15 18:56, Malcolm McLean wrote: >> On Tuesday, July 21, 2015 at 2:12:41 PM UTC+1, David Brown wrote: >>> >>> Usually the best development method (following Heathfield's law) is to >>> write the code clearly and correctly, and if it is too slow in practice >>> then you can fiddle with it until it runs faster. If the recursion is >>> easily converted to iteration, then gcc (with high enough optimisation >>> level) or other good compilers can usually do the job, saving you the >>> effort. >>> >> Heathfield's law > > I can't help liking the sound of that. You need to create a Wikipedia entry for it and make it official :-) > >> is pretty good, but recursion is a bit of an exception. > > I disagree. Heathfield's Law, roughly stated, is that readability trumps > correctness and correctness trumps speed (on the grounds that it's > easier to fix readable programs than to make working programs readable, > and it's easier to speed up correct programs than it is to fix fast > programs). Let's see where that takes us with recursion: >
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-22 20:39 +0100 |
| Message-ID | <moorfj$8dv$1@dont-email.me> |
| In reply to | #66128 |
On 21/07/15 22:58, David Brown wrote:
> On 21/07/15 20:43, Richard Heathfield wrote:
>> On 21/07/15 18:56, Malcolm McLean wrote:
>>> On Tuesday, July 21, 2015 at 2:12:41 PM UTC+1, David Brown wrote:
>>>>
>>>> Usually the best development method (following Heathfield's law) is to
>>>> write the code clearly and correctly, and if it is too slow in practice
>>>> then you can fiddle with it until it runs faster. If the recursion is
>>>> easily converted to iteration, then gcc (with high enough optimisation
>>>> level) or other good compilers can usually do the job, saving you the
>>>> effort.
>>>>
>>> Heathfield's law
>>
>> I can't help liking the sound of that.
>
> You need to create a Wikipedia entry for it and make it official :-)
I'm probably not the best judge of whether it is "notable" enough for
Wikipedia. I certainly would not be the best person to discuss
Heathfield's Law from a neutral point of view. (Having said that, I
ought to give some thought to formalising the wording, just in case...)
But that's not why I'm replying! Rather, I have a data point from
today's trawl through the design ocean, that I think is relevant to the
discussion regarding recursion vs iteration.
Today I encountered a problem that is, I think, isomorphic to the
following problem statement:
I have sixteen elements, evenly divided into metals M and non-metals N,
so there are eight elements in each group. We'll call them M[0] to M[7]
and N[0] to N[7].
A molecule consists of 0 or more diatoms { M[a], N[b] } (i.e. a metal
and a non-metal) where a is in the range [0,7] and b in the range [0,6],
terminated by a diatom { M[a], N[7] }.
My problem is that I need to construct all possible molecules containing
a given number of diatoms.
It seemed to me that this was an obvious case for iteration, and I spent
about two hours trying to write a clear, correct function that did the
job. I have no doubt that this is possible, but I couldn't see a way to
do it. Eventually, I gave up, sat back, and thought it through some more
(without result). Time for coffee. And then, without warning, the easy
way jumped out at me. Down went the cup, and in went the code, which
took just a few minutes. So that you don't have to wade through a whole
bunch of housekeeping code, I'll show it here in pseudo-C:
print_set(molecule)
{
for(i = 0; i < M_COUNT; i++)
{
diatom = get_terminal_diatom(i);
print(molecule, diatom, newline);
}
}
gen_atom(molecule, length)
{
if(length == 0)
{
print_set(molecule);
}
else
{
lim = M_COUNT * NTNM_COUNT; /* NTNM=Non-Terminal Non-Metal */
for(mn = 0; mn < lim; mn++)
{
diatom = get_nonterminal_diatom(mn);
gen_atom(molecule + diatom, length - 1);
}
}
}
Now I can generate a complete set of molecules of any (reasonable)
length n+1 using gen_atom("", n); (where n is the number of non-terminal
diatoms).
Obviously it's not quite that neat in reality, because there's a bunch
of string-building going on, which I've handwaved into '+' in the above
pseudo-C, but the essence of the idea is shown above, and it's
remarkably simple. The actual code is a bit longer, but it's still much,
much shorter than the iterative version (the version that didn't work).
Sometimes, recursion is just better. (That doesn't mean it always is!)
--
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-24 00:54 -0400 |
| Message-ID | <Uxjsx.247124$OE7.216212@fx27.iad> |
| In reply to | #66183 |
On 7/22/15 3:39 PM, Richard Heathfield wrote:
> But that's not why I'm replying! Rather, I have a data point from
> today's trawl through the design ocean, that I think is relevant to the
> discussion regarding recursion vs iteration.
>
> Today I encountered a problem that is, I think, isomorphic to the
> following problem statement:
>
> I have sixteen elements, evenly divided into metals M and non-metals N,
> so there are eight elements in each group. We'll call them M[0] to M[7]
> and N[0] to N[7].
>
> A molecule consists of 0 or more diatoms { M[a], N[b] } (i.e. a metal
> and a non-metal) where a is in the range [0,7] and b in the range [0,6],
> terminated by a diatom { M[a], N[7] }.
>
> My problem is that I need to construct all possible molecules containing
> a given number of diatoms.
>
> It seemed to me that this was an obvious case for iteration, and I spent
> about two hours trying to write a clear, correct function that did the
> job. I have no doubt that this is possible, but I couldn't see a way to
> do it. Eventually, I gave up, sat back, and thought it through some more
> (without result). Time for coffee. And then, without warning, the easy
> way jumped out at me. Down went the cup, and in went the code, which
> took just a few minutes. So that you don't have to wade through a whole
> bunch of housekeeping code, I'll show it here in pseudo-C:
>
If I understand the problem, it sounds like a simple solution is just
build a mixed base counter.
In Pseudo code (untested and at the top of my head).
Get number of diatoms (n).
Allocate an array A of 2n elements.
Set all element to 0, except the last, which is set to 7.
Loop:
Print/Record the array as a list of Diatom (i) for i in 0 .. n where
A[2i] is a of M[a], A[2i+1] is b of N[b] of the i'th Diatom.
start at the first element,
Loop1:
if current element it is not at it maximum, increment it and go to Loop
(even elements go 0 to 7, odd eleemnts go 0 to 6)
If it is at the maximum, set it to zero and advance to the next element
and go to Loop1, unless we are at the very last element, then we are done.
Nice simple, none-recursive iterative solution.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-24 09:06 +0100 |
| Message-ID | <mosrj4$1f4$1@dont-email.me> |
| In reply to | #66273 |
On 24/07/15 05:54, Richard Damon wrote: <snip> > If I understand the problem, it sounds like a simple solution is just > build a mixed base counter. I read your solution, and I looked at my solution. It was obvious (to me) that mine works. It was not obvious (to me) that yours works. (FWIW, the more I look at it, the more it seems like it should.) I like simple, as you probably know already. In this case, recursive looks a lot simpler than iterative. (But kudos for finding an iterative solution!) -- 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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-24 08:04 -0400 |
| Message-ID | <1Rpsx.29953$%j1.24509@fx21.iad> |
| In reply to | #66276 |
On 7/24/15 4:06 AM, Richard Heathfield wrote: > On 24/07/15 05:54, Richard Damon wrote: > > <snip> > >> If I understand the problem, it sounds like a simple solution is just >> build a mixed base counter. > > I read your solution, and I looked at my solution. It was obvious (to > me) that mine works. It was not obvious (to me) that yours works. (FWIW, > the more I look at it, the more it seems like it should.) > > I like simple, as you probably know already. In this case, recursive > looks a lot simpler than iterative. > > (But kudos for finding an iterative solution!) > The basis for both solutions is a counter, and a counter can be built iteratively (starting with the fasting changing and moving to the slowest) or recursively (starting with the slowest and moving to the fastest). Which is the more obvious will depend on which you are used to look at. The one big difference is where the answers come. When you recursively iterate through a set like this, your generator needs to call the consumer deep in the nest. With an iterative solution the state is saved explicitly so the consumer can be at the same level or even the caller of the iterator. (Of course, people who think recursively think deeply nesting program flow while iterative thinkers look for broader structures.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-24 13:48 +0100 |
| Message-ID | <motc38$thi$1@dont-email.me> |
| In reply to | #66279 |
On 24/07/15 13:04, Richard Damon wrote: <snip> > is the more obvious will depend on which you are used to > look at. > > The one big difference is where the answers come. Right! > When you recursively > iterate through a set like this, your generator needs to call the > consumer deep in the nest. With an iterative solution the state is saved > explicitly so the consumer can be at the same level or even the caller > of the iterator. > > (Of course, people who think recursively think deeply nesting program > flow while iterative thinkers look for broader structures. An easy way to deal with the issue in a recursive solution (assuming that you can't just printf and redirect to a file, as I did) is to pass int(*f)(void *, void *) and a void *p to the recursive function. The recursive solution generates an answer q and calls (*f)(p, q), and then how *f deals with that answer is its own business. This way, you could easily build up an in-memory data structure if that happened to be your principal small aquatic vessel's flotation medium. -- 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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-25 14:02 -0400 |
| Message-ID | <KaQsx.193554$r46.70220@fx28.iad> |
| In reply to | #66280 |
On 7/24/15 8:48 AM, Richard Heathfield wrote: > On 24/07/15 13:04, Richard Damon wrote: > > <snip> > >> is the more obvious will depend on which you are used to >> look at. >> >> The one big difference is where the answers come. > > Right! > >> When you recursively >> iterate through a set like this, your generator needs to call the >> consumer deep in the nest. With an iterative solution the state is saved >> explicitly so the consumer can be at the same level or even the caller >> of the iterator. >> >> (Of course, people who think recursively think deeply nesting program >> flow while iterative thinkers look for broader structures. > > An easy way to deal with the issue in a recursive solution (assuming > that you can't just printf and redirect to a file, as I did) is to pass > int(*f)(void *, void *) and a void *p to the recursive function. The > recursive solution generates an answer q and calls (*f)(p, q), and then > how *f deals with that answer is its own business. This way, you could > easily build up an in-memory data structure if that happened to be your > principal small aquatic vessel's flotation medium. > I wouldn't make the function a f(void*, void*) but make the type for passing the results something definite (you know at program writting time what you are going to send, so why use void*). Passing it in like this, does also say that we are likely adding two 'words' to the stack frame for each level of recursion used (even if the calling convention passes the value in registers, in general, the function will likely need to save the values when it makes some other non-recursion calls). If the recursion depth isn't large this may not be a problem. The bigger issue with the recursive method here that if you want to 'pause' the sequence generation and be able to start it back up later (perhaps you are presenting selected results to the user to do something with and he wants to go home for the day), the recursive method can't 'naturally' handle this, as the state of where you are is spread out over all the layers of calls, while the iterative method has a nice simple data structure to express its state. I will also admit that there are times when the recursive solution is cleaner that the iterative solution (when the iterative solution starts by creating a 'stack' to store state is one big hint), just as there are cases when the iterative design is cleaner (and a lot of cases where both can be reasonable). As was mentioned, a very powerful skill is to be able to transform one type of solution into the other.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-30 13:41 -0700 |
| Message-ID | <kfna8udcr9l.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66347 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/24/15 8:48 AM, Richard Heathfield wrote:
>> On 24/07/15 13:04, Richard Damon wrote:
>>
>> <snip>
>>
>>> is the more obvious will depend on which you are used to
>>> look at.
>>>
>>> The one big difference is where the answers come.
>>
>> Right!
>>
>>> When you recursively iterate through a set like this, your
>>> generator needs to call the consumer deep in the nest. With an
>>> iterative solution the state is saved explicitly so the consumer
>>> can be at the same level or even the caller of the iterator.
>>>
>>> (Of course, people who think recursively think deeply nesting program
>>> flow while iterative thinkers look for broader structures.
>>
>> An easy way to deal with the issue in a recursive solution
>> (assuming that you can't just printf and redirect to a file, as I
>> did) is to pass int(*f)(void *, void *) and a void *p to the
>> recursive function. The recursive solution generates an answer q
>> and calls (*f)(p, q), and then how *f deals with that answer is its
>> own business. This way, you could easily build up an in-memory
>> data structure if that happened to be your principal small aquatic
>> vessel's flotation medium.
>
> [snip]
>
> The bigger issue with the recursive method here that if you want
> to pause' the sequence generation and be able to start it back up
> later (perhaps you are presenting selected results to the user to
> do something with and he wants to go home for the day), the
> recursive method can't 'naturally' handle this, as the state of
> where you are is spread out over all the layers of calls,
The recursive method presented earlier has that property. Other
recursive methods do not.
> while the iterative method
> has a nice simple data structure to express its state.
That can be true also for a recursive method.
> I will also admit that there are times when the recursive solution
> is cleaner that the iterative solution (when the iterative
> solution starts by creating a 'stack' to store state is one big
> hint), just as there are cases when the iterative design is
> cleaner (and a lot of cases where both can be reasonable).
I agree with this except I would say a recursive solution and
an iterative solution rather than using "the".
> As was mentioned, a very powerful skill is to be able to
> transform one type of solution into the other.
And more generally, it is a powerful skill to be able to
switch back and forth between many different design
perspectives. Here's another way to code an iterative
scheme (not very different than what you described, but
different enough I think to be of interest):
#define M_COUNT 8
#define NM_COUNT 8
#define NTNM_COUNT (NM_COUNT-1)
typedef unsigned long long ULL;
void
synthesize_molecules( void f(), int n0 ){
// form chains of n0+1 diatoms
// diatoms stored in x[i] as: nonmetal index * M_COUNT + metal index
enum { N = 50 };
int i, x[N], n = n0 < 0 ? 0 : n0 > N-1 ? N-1 : n0;
ULL radix = NTNM_COUNT * M_COUNT;
ULL counter = 0;
ULL limit = M_COUNT;
for( i = 0; i < n; i++ ) counter *= radix, limit *= radix;
while( counter < limit ){
ULL c = counter;
for( i = 0; i < n; i++ ){
x[i] = c % radix, c /= radix;
}
x[n] = c + radix;
f( x, n+1 );
counter++;
}
}
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-02 15:41 +0200 |
| Message-ID | <mpldmn$msg$1@speranza.aioe.org> |
| In reply to | #66347 |
On 25.07.2015 20:02, Richard Damon wrote: [...] > I will also admit that there are times when the recursive solution is > cleaner that the iterative solution (when the iterative solution starts > by creating a 'stack' to store state is one big hint), just as there are > cases when the iterative design is cleaner (and a lot of cases where > both can be reasonable). As was mentioned, a very powerful skill is to > be able to transform one type of solution into the other. Correct me if I'm wrong, but when a function is called recursively and it hasn't been tail-call optimized, there is at least a very small overhead of calling functions recursively, a couple of instructions and some memory. On the other hand, an iterative solution can do the same as a recursive one, but without the function call overhead. Which means that on any system that has a compliant C compiler, an iterative solution will be faster than a recursive one that hasn't been tail call optimized, and not all systems can be expected to have a compiler that will do tail call optimization. It will also use less memory. The iterative solution will also be limited to the value range of the counter used while a recursive one will be limited by the memory available, which means it will be able to handle "bigger" data on all systems that have a C compiler. Another point might be that a compiler that does tail call optimization might not always be able to do so. -Morten
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-02 21:51 +0000 |
| Message-ID | <55be903b.186109@news.xs4all.nl> |
| In reply to | #66702 |
"Morten W. Petersen" <morphex@gmail.com> wrote: > On 25.07.2015 20:02, Richard Damon wrote: > [...] > > I will also admit that there are times when the recursive solution is > > cleaner that the iterative solution (when the iterative solution starts > > by creating a 'stack' to store state is one big hint), just as there are > > cases when the iterative design is cleaner (and a lot of cases where > > both can be reasonable). As was mentioned, a very powerful skill is to > > be able to transform one type of solution into the other. > > Correct me if I'm wrong, but when a function is called recursively and > it hasn't been tail-call optimized, there is at least a very small > overhead of calling functions recursively, a couple of instructions and > some memory. If it hasn't been optimised, yes. > On the other hand, an iterative solution can do the same as a recursive > one, but without the function call overhead. Usually, and almost always in the typical cases, but not always. The Ackerman function is a notorious (if theoretical) example of a recursive function which cannot, usefully, be made iterative. > Which means that on any system that has a compliant C compiler, an > iterative solution will be faster than a recursive one that hasn't been > tail call optimized, Hmmm... no. Even if an iterative solution is possible, it may be that a recursive solution is more natural, and therefore more efficient. Try running through a tree iteratively: it's certainly possible, but doing it recursively and letting the compiler worry about the stack is almost certainly going to be faster. Richard
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-03 01:20 +0200 |
| Message-ID | <mpm8k6$md5$1@speranza.aioe.org> |
| In reply to | #66748 |
On 02.08.2015 23:51, Richard Bos wrote: > "Morten W. Petersen" <morphex@gmail.com> wrote: [...] >> On the other hand, an iterative solution can do the same as a recursive >> one, but without the function call overhead. > > Usually, and almost always in the typical cases, but not always. The > Ackerman function is a notorious (if theoretical) example of a recursive > function which cannot, usefully, be made iterative. I googled and found this: http://stackoverflow.com/questions/10742322/how-to-rewrite-ackermann-function-in-non-recursive-style It looks like the first answer provides a solution, but also implements something like a stack. But am I wrong in thinking that the solution mentioned there is good enough and better than recursion when it comes to memory use? -Morten
[toc] | [prev] | [next] | [standalone]
Page 6 of 15 — ← Prev page 1 … 4 5 [6] 7 8 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web