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 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-09 10:08 -0700 |
| Message-ID | <7e746704-bb7e-4245-92c5-9248dae8a7fb@googlegroups.com> |
| In reply to | #64994 |
On Thursday, July 9, 2015 at 2:08:19 PM UTC+1, Morten W. Petersen wrote:
> On 09.07.2015 14:28, Malcolm McLean wrote:
>
> Well, when you say it that way, I agree that recursion looks better as
> it would be simpler code.
>
> However, I haven't decided on recursion or looping yet, I'll have to
> give it some thought.
>
You do both.
if you think of xml as a binary tree with "left" and "right" children, then it
makes sense to recurse on both - call recursively for left and for right.
Now logically, a tree with a child and next pointer is just the same as one
with a left and a right. It's the way you use it to represent your data that's
different. In fact, the long lists will be the "next" pointers, the "child" pointers
will be relatively shallow.
Now to loop on both is very difficult to manage. But to loop on the next and
recurse on the child is easy.
void depth_vwal(NODE *xmlnode)
{
while(xmlnode)
{
printf("node %s\n", xmlnode->data):
if(xmlnode->child)
depth_walk(xmlnode->child);
xmlnode = xmlnode->next;
}
}
it's really simple code, and following along the next pointers is really fast.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 19:19 +0200 |
| Message-ID | <mnmad4$co7$1@speranza.aioe.org> |
| In reply to | #65033 |
On 09.07.2015 19:08, Malcolm McLean wrote:
> On Thursday, July 9, 2015 at 2:08:19 PM UTC+1, Morten W. Petersen wrote:
[...]
>> Well, when you say it that way, I agree that recursion looks better as
>> it would be simpler code.
>>
>> However, I haven't decided on recursion or looping yet, I'll have to
>> give it some thought.
>>
> You do both.
> if you think of xml as a binary tree with "left" and "right" children, then it
> makes sense to recurse on both - call recursively for left and for right.
> Now logically, a tree with a child and next pointer is just the same as one
> with a left and a right. It's the way you use it to represent your data that's
> different. In fact, the long lists will be the "next" pointers, the "child" pointers
> will be relatively shallow.
> Now to loop on both is very difficult to manage. But to loop on the next and
> recurse on the child is easy.
>
> void depth_vwal(NODE *xmlnode)
> {
> while(xmlnode)
> {
> printf("node %s\n", xmlnode->data):
> if(xmlnode->child)
> depth_walk(xmlnode->child);
> xmlnode = xmlnode->next;
> }
> }
>
> it's really simple code, and following along the next pointers is really fast.
Aha. :)
Looping makes sense on the parsing part for getting through the data
stream (reading from file), while recursing makes more sense running
through the internal representation.
Right?
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 19:11 +0100 |
| Message-ID | <mnmde9$ipe$1@dont-email.me> |
| In reply to | #65034 |
On 09/07/15 18:19, Morten W. Petersen wrote: <snip> > Looping makes sense on the parsing part for getting through the data > stream (reading from file), Absolutely. Your lexing stage should be a simple loop. I'm sorry that I didn't make that clear earlier. It didn't occur to me that you might be considering a recursive lexer. That doesn't make any sense at all, and you're absolutely right to be thinking in terms of a loop for the lexer. But, for parsing... > while recursing makes more sense running > through the internal representation. ...yes. This is where recursion really comes into its own. It's such a natural fit that it's hard to see why you would do this any other way. > Right? Right. -- 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 | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 21:28 +0200 |
| Message-ID | <mnmhvd$v1b$1@speranza.aioe.org> |
| In reply to | #65043 |
On 09.07.2015 20:11, Richard Heathfield wrote: > On 09/07/15 18:19, Morten W. Petersen wrote: > > <snip> > >> Looping makes sense on the parsing part for getting through the data >> stream (reading from file), > > Absolutely. Your lexing stage should be a simple loop. I'm sorry that I > didn't make that clear earlier. It didn't occur to me that you might be > considering a recursive lexer. That doesn't make any sense at all, and > you're absolutely right to be thinking in terms of a loop for the lexer. > But, for parsing... OK. Yeah it might be that the lexer runs through the data and then a function is called on every token, whatever the token might be. Later in the development process the lexer might be setup to do its thing and then the function and data is fed to a thread as the lexer progresses. >> while recursing makes more sense running >> through the internal representation. > > ...yes. This is where recursion really comes into its own. It's such a > natural fit that it's hard to see why you would do this any other way. Well I'm sure there are other ways to do it as well, but yeah. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-09 13:41 +0100 |
| Message-ID | <mnlq37$jpr$1@dont-email.me> |
| In reply to | #64979 |
On 09/07/2015 11:49, Morten W. Petersen wrote: > Hi there. :) > > I'm working on an XML parser and writer, located here: > > https://github.com/morphex/smash_xml > > Now I'm getting to the point where I want to parse an entire > XML file and get an internal representation of the XML file. Are you the chap talking about 10GB XML data a while back? In that case you need to consider the case where the internal rep doesn't fit all into memory (especially if it's already full of a Unicode representation of the source!) > As for internal representation, choosing a linked-list > structure seems like the way to go. > > However, choosing between recursion and looping is less > obvious, to me at least. XML data isn't linear. Why would you use a linear linked list and a linear iterative loop? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 15:22 +0200 |
| Message-ID | <mnlsha$9i8$1@speranza.aioe.org> |
| In reply to | #64988 |
On 09.07.2015 14:41, Bartc wrote: > On 09/07/2015 11:49, Morten W. Petersen wrote: >> Hi there. :) >> >> I'm working on an XML parser and writer, located here: >> >> https://github.com/morphex/smash_xml >> >> Now I'm getting to the point where I want to parse an entire >> XML file and get an internal representation of the XML file. > > Are you the chap talking about 10GB XML data a while back? In that case > you need to consider the case where the internal rep doesn't fit all > into memory (especially if it's already full of a Unicode representation > of the source!) Mm, yes. Well, today you have SSD disks that can be used as virtual memory, etc. etc. Isn't the job of the OS to make memory available? I've landed on having the choice between a 32-bit or 21-bit internal representation, which reduces the size by around 30%. This choice can be done automatically if the amount of available memory is known. Maybe some internal data structure that's suitable for having significant parts of the XML data outside of RAM will crystallize as I work on the project, but it's not a priority now. >> As for internal representation, choosing a linked-list >> structure seems like the way to go. >> >> However, choosing between recursion and looping is less >> obvious, to me at least. > > XML data isn't linear. > > Why would you use a linear linked list and a linear iterative loop? OK, it's tree-like. When I was thinking about linked-lists I was mainly thinking of the linking nature, not choosing away binary trees. -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 18:45 +0200 |
| Message-ID | <mnm8e9$80g$1@speranza.aioe.org> |
| In reply to | #64979 |
On 09.07.2015 18:04, Stefan Ram wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: >> As for internal representation, choosing a linked-list >> structure seems like the way to go. > > There has to be an interface between the parser and the > storage, so that the implementation of the storage can > be changed without the need for changes in the parser. Yeah I was thinking about that, there will be some functions that work the same regardless of internal representation and the rest of the code use those. >> However, choosing between recursion and looping is less >> obvious, to me at least. > > Recursive data-structures want recursive program-structures. > Many typical XML entities do not have such a deep nesting. > > OT: I think, under Microsoft® Windows, you can use > > EDITBIN /STACK:1048576 EXAMPLE.EXE > > to set the stack size (untested). And maybe, there are even > (non-portable) means to check it from within the program. I've landed on looping now so the stack question is pretty much moot, but thanks for the tip. -Morten
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-09 18:05 +0000 |
| Message-ID | <mnmd5c$hum$3@speranza.aioe.org> |
| In reply to | #64979 |
Morten W. Petersen <morphex@gmail.com> wrote: > I'm working on an XML parser and writer, located here: > https://github.com/morphex/smash_xml > Now I'm getting to the point where I want to parse an entire > XML file and get an internal representation of the XML file. > As for internal representation, choosing a linked-list > structure seems like the way to go. > However, choosing between recursion and looping is less > obvious, to me at least. Most recursive algorithms are best written as loops. The most obvious is factorial, but quicksort with a small table also works nice as loops. The big exception, as far as I know, is recursive descent parsers. You didn't say recursive descent, but if that is what you mean, then yes, recursion. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 07:06 -0700 |
| Message-ID | <kfn7fq623gl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65041 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Morten W. Petersen <morphex@gmail.com> wrote: > >> I'm working on an XML parser and writer, located here: >> >> https://github.com/morphex/smash_xml >> >> Now I'm getting to the point where I want to parse an entire >> XML file and get an internal representation of the XML file. >> >> As for internal representation, choosing a linked-list >> structure seems like the way to go. >> >> However, choosing between recursion and looping is less >> obvious, to me at least. > > Most recursive algorithms are best written as loops. Only for people who are ignorant about how to use recursion. > The most obvious is factorial, Hogwash. You're assuming a naive recursive formulation, which is a bad assumption. For small integers it hardly makes a difference - easier just to do a table lookup. For large integers a recursive formulation is better: for example, computing 1000000 factorial (or was it 10000000 factorial? I think it was one of the two), my simple recursive version ran about 50 times faster than the simple looping version. > but quicksort with a small table > also works nice as loops. Hogwash again. Adding code to push/pop subranges lengthens the routine and also obscures the underlying algorithm. Both approaches need to take into account which sub-segment to do first. A looping version probably has a smaller memory footprint in the worst case, but a recursive version probably has a smaller memory footprint in all typical cases. And a looping version almost certainly occupies more instruction-space memory, for systems where that is a consideration. In most environments a recursive formulation looks better than a looping one.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-11 15:51 -0700 |
| Message-ID | <lnegkepau2.fsf@kst-u.example.com> |
| In reply to | #65263 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
>> The most obvious is factorial,
>
> Hogwash. You're assuming a naive recursive formulation, which
> is a bad assumption. For small integers it hardly makes a
> difference - easier just to do a table lookup. For large
> integers a recursive formulation is better: for example,
> computing 1000000 factorial (or was it 10000000 factorial?
> I think it was one of the two), my simple recursive version
> ran about 50 times faster than the simple looping version.
I'm curious about the details. How do you get a 50x speedup using
recursion rather than iteration?
Of course with numbers that big the representation is going to be an
issue.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-15 09:36 -0700 |
| Message-ID | <kfnmvyxqswr.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65359 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
> [...]
>
>>> The most obvious is factorial,
>>
>> Hogwash. You're assuming a naive recursive formulation, which
>> is a bad assumption. For small integers it hardly makes a
>> difference - easier just to do a table lookup. For large
>> integers a recursive formulation is better: for example,
>> computing 1000000 factorial (or was it 10000000 factorial?
>> I think it was one of the two), my simple recursive version
>> ran about 50 times faster than the simple looping version.
>
> I'm curious about the details. How do you get a 50x speedup using
> recursion rather than iteration?
>
> Of course with numbers that big the representation is going to be an
> issue.
Right, and that's the heart of the matter. The key idea is that
when you multiply multiple-precision integers you want to keep
the numbers as small as you can, or in other words have the two
numbers being multiplied as close to being the same size as you
can. With the understanding that I am writing in regular C
rather than a language that has multiple-precision arithmetic
built-in, here is the algorithm:
static unsigned product( unsigned, unsigned );
unsigned
factorial( unsigned n ){
return product( n, 1 );
}
unsigned
product( unsigned n, unsigned v ){
/* the product of 'n' consecutive integers starting at 'v' */
if( n < 2 ) return v;
return product( n-n/2, v ) * product( n/2, v + (n-n/2) );
}
This computes factorial using a binary tree of products, so the
numbers being multiplied at each stage are, roughly, the same
size. Silly for small integers, but a huge win for computing
factorials of large integers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-15 10:49 -0700 |
| Message-ID | <lnlhehjop6.fsf@kst-u.example.com> |
| In reply to | #65634 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>> [...]
>>
>>>> The most obvious is factorial,
>>>
>>> Hogwash. You're assuming a naive recursive formulation, which
>>> is a bad assumption. For small integers it hardly makes a
>>> difference - easier just to do a table lookup. For large
>>> integers a recursive formulation is better: for example,
>>> computing 1000000 factorial (or was it 10000000 factorial?
>>> I think it was one of the two), my simple recursive version
>>> ran about 50 times faster than the simple looping version.
>>
>> I'm curious about the details. How do you get a 50x speedup using
>> recursion rather than iteration?
>>
>> Of course with numbers that big the representation is going to be an
>> issue.
>
> Right, and that's the heart of the matter. The key idea is that
> when you multiply multiple-precision integers you want to keep
> the numbers as small as you can, or in other words have the two
> numbers being multiplied as close to being the same size as you
> can. With the understanding that I am writing in regular C
> rather than a language that has multiple-precision arithmetic
> built-in, here is the algorithm:
>
> static unsigned product( unsigned, unsigned );
>
> unsigned
> factorial( unsigned n ){
> return product( n, 1 );
> }
>
> unsigned
> product( unsigned n, unsigned v ){
> /* the product of 'n' consecutive integers starting at 'v' */
> if( n < 2 ) return v;
> return product( n-n/2, v ) * product( n/2, v + (n-n/2) );
> }
>
> This computes factorial using a binary tree of products, so the
> numbers being multiplied at each stage are, roughly, the same
> size. Silly for small integers, but a huge win for computing
> factorials of large integers.
Interesting. With a simple loop, most of the multiplications are going
to be multiplying a fairly small number by a very large number, yielding
a very large result (that can't be stored in any integer type). With
this technique, most of the multiplications are of small numbers by
small numbers.
Cool!
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-15 13:05 -0500 |
| Message-ID | <hu7dqa5ectm1kvgaa4olcvdnkrhegn4jb6@4ax.com> |
| In reply to | #65634 |
On Wed, 15 Jul 2015 09:36:52 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:
>Keith Thompson <kst-u@mib.org> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>> [...]
>>
>>>> The most obvious is factorial,
>>>
>>> Hogwash. You're assuming a naive recursive formulation, which
>>> is a bad assumption. For small integers it hardly makes a
>>> difference - easier just to do a table lookup. For large
>>> integers a recursive formulation is better: for example,
>>> computing 1000000 factorial (or was it 10000000 factorial?
>>> I think it was one of the two), my simple recursive version
>>> ran about 50 times faster than the simple looping version.
>>
>> I'm curious about the details. How do you get a 50x speedup using
>> recursion rather than iteration?
>>
>> Of course with numbers that big the representation is going to be an
>> issue.
>
>Right, and that's the heart of the matter. The key idea is that
>when you multiply multiple-precision integers you want to keep
>the numbers as small as you can, or in other words have the two
>numbers being multiplied as close to being the same size as you
>can. With the understanding that I am writing in regular C
>rather than a language that has multiple-precision arithmetic
>built-in, here is the algorithm:
>
> static unsigned product( unsigned, unsigned );
>
> unsigned
> factorial( unsigned n ){
> return product( n, 1 );
> }
>
> unsigned
> product( unsigned n, unsigned v ){
> /* the product of 'n' consecutive integers starting at 'v' */
> if( n < 2 ) return v;
> return product( n-n/2, v ) * product( n/2, v + (n-n/2) );
> }
>
>This computes factorial using a binary tree of products, so the
>numbers being multiplied at each stage are, roughly, the same
>size. Silly for small integers, but a huge win for computing
>factorials of large integers.
You've implemented a completely different algorithm, not just a
non-recursive version of the same algorithm. This is like saying that
recursive algorithms are better by comparing Quicksort to a bubble
sort.
And the above algorithm can be done non-recursively as well, although
not nearly as cleanly.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 10:28 -0700 |
| Message-ID | <kfn7fpun3g3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65644 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Wed, 15 Jul 2015 09:36:52 -0700, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>
>>> [...]
>>>
>>>>> The most obvious is factorial,
>>>>
>>>> Hogwash. You're assuming a naive recursive formulation, which
>>>> is a bad assumption. For small integers it hardly makes a
>>>> difference - easier just to do a table lookup. For large
>>>> integers a recursive formulation is better: for example,
>>>> computing 1000000 factorial (or was it 10000000 factorial?
>>>> I think it was one of the two), my simple recursive version
>>>> ran about 50 times faster than the simple looping version.
>>>
>>> I'm curious about the details. How do you get a 50x speedup using
>>> recursion rather than iteration?
>>>
>>> Of course with numbers that big the representation is going to be an
>>> issue.
>>
>> Right, and that's the heart of the matter. The key idea is that
>> when you multiply multiple-precision integers you want to keep
>> the numbers as small as you can, or in other words have the two
>> numbers being multiplied as close to being the same size as you
>> can. With the understanding that I am writing in regular C
>> rather than a language that has multiple-precision arithmetic
>> built-in, here is the algorithm:
>>
>> static unsigned product( unsigned, unsigned );
>>
>> unsigned
>> factorial( unsigned n ){
>> return product( n, 1 );
>> }
>>
>> unsigned
>> product( unsigned n, unsigned v ){
>> /* the product of 'n' consecutive integers starting at 'v' */
>> if( n < 2 ) return v;
>> return product( n-n/2, v ) * product( n/2, v + (n-n/2) );
>> }
>>
>> This computes factorial using a binary tree of products, so the
>> numbers being multiplied at each stage are, roughly, the same
>> size. Silly for small integers, but a huge win for computing
>> factorials of large integers.
>
> You've implemented a completely different algorithm, not just a
> non-recursive version of the same algorithm.
I never claimed to be using a transformed version of the simple
iterative algorithm, only that recursion is useful (or more
accurately, can be useful) in the problem of computing factorial.
> This is like saying that recursive algorithms are better by
> comparing Quicksort to a bubble sort.
First I didn't say that recursive algorithms are better, only
that (for factorial) they aren't always worse (and are better
in this particular case).
Second I don't think your analogy is quite on-point. The
iterative algorithm and the recursive algorithm I gave compute
all the same multiplications, it just computes them in a
different order. The reason Quicksort is better than bubble
sort is because it does very different computations, and most
notably fewer computations. Certainly the recursive factorial
algorithm is not exactly the same as the regular iterative one,
but the differences are not nearly as dramatic as those between
Quicksort and bubble sort.
> And the above algorithm can be done non-recursively as well,
> although not nearly as cleanly.
Sure, it can be done non-recursively, but only by effectively
simulating the recursive version. Approaching the problem from a
recursive perspective is what is valuable, regardless of whether
what is ultimately implemented uses recurive calls or iteration
and a manual stack for simulating the recursion.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-20 12:41 -0700 |
| Message-ID | <829075ea-5aaa-44f9-b0cf-d18ea4f95a9b@googlegroups.com> |
| In reply to | #66027 |
On Monday, July 20, 2015 at 6:28:53 PM UTC+1, Tim Rentsch wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: > > First I didn't say that recursive algorithms are better, only > that (for factorial) they aren't always worse (and are better > in this particular case). > > Second I don't think your analogy is quite on-point. The > iterative algorithm and the recursive algorithm I gave compute > all the same multiplications, it just computes them in a > different order. The reason Quicksort is better than bubble > sort is because it does very different computations, and most > notably fewer computations. Certainly the recursive factorial > algorithm is not exactly the same as the regular iterative one, > but the differences are not nearly as dramatic as those between > Quicksort and bubble sort. > > > And the above algorithm can be done non-recursively as well, > > although not nearly as cleanly. > > Sure, it can be done non-recursively, but only by effectively > simulating the recursive version. Approaching the problem from a > recursive perspective is what is valuable, regardless of whether > what is ultimately implemented uses recurive calls or iteration > and a manual stack for simulating the recursion. > A "divide and conquer" algorithm is naturally recursive. Divide you dataset into low and high, put the low set in the low locations in memory and the high set in the high locations. Then repeat on both sets until the set consists of only one item. You can tail recurse out the second call, but that just confuses the matter - the algorithm works best when the sets are approximately equal in size. Its better to think of it as a binary tree, and the execution flow as splitting in two on each call. The optimisation is best left to the compiler. But factorial is iterative. It's "go from 1 to N, multiplying and collecting the product as you go". You can recast it as recursion and we will admit that the will work, but it seems artificial. If a postman is going down the street delivering mail, he thinks of himself as "for each house, post mail through letterbox". He doesn't think of it as "Deliver mail to the first house in the street. Remove the first house from the street. Treat the rest of the street as a street".
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-20 21:37 +0100 |
| Message-ID | <mojm3b$mcu$1@dont-email.me> |
| In reply to | #66048 |
On 20/07/15 20:41, Malcolm McLean wrote: <snip> > But factorial is iterative. It can be thought of in that way, yes. It can also be thought of as a recursive function. > It's "go from 1 to N, multiplying and > collecting the product as you go". Or it's "multiply N by the factorial of (N-1)" - a natural way to express the function, and inherently recursive. > You can recast it as recursion > and we will admit that the will work, Yes. What's more, you can re-jig the iteration to make it more efficient, *and* you can re-jig the recursion to make it more efficient. Either way, you are no longer doing the multiplications in what you would probably want to call the "natural" order. > but it seems artificial. No, not really. > If a postman is going down the street delivering mail, he thinks > of himself as "for each house, post mail through letterbox". He > doesn't think of it as "Deliver mail to the first house in the > street. Remove the first house from the street. Treat the rest > of the street as a street". Very true, but a factorial is not a street. It's a factorial. -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-24 13:05 -0700 |
| Message-ID | <kfnegjxgw3v.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66048 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, July 20, 2015 at 6:28:53 PM UTC+1, Tim Rentsch wrote: >> Robert Wessel <robertwessel2@yahoo.com> writes: >> >> First I didn't say that recursive algorithms are better, only >> that (for factorial) they aren't always worse (and are better >> in this particular case). >> >> Second I don't think your analogy is quite on-point. The >> iterative algorithm and the recursive algorithm I gave compute >> all the same multiplications, it just computes them in a >> different order. The reason Quicksort is better than bubble >> sort is because it does very different computations, and most >> notably fewer computations. Certainly the recursive factorial >> algorithm is not exactly the same as the regular iterative one, >> but the differences are not nearly as dramatic as those between >> Quicksort and bubble sort. >> >>> And the above algorithm can be done non-recursively as well, >>> although not nearly as cleanly. >> >> Sure, it can be done non-recursively, but only by effectively >> simulating the recursive version. Approaching the problem from a >> recursive perspective is what is valuable, regardless of whether >> what is ultimately implemented uses recurive calls or iteration >> and a manual stack for simulating the recursion. > > A "divide and conquer" algorithm is naturally recursive. Divide > you dataset into low and high, put the low set in the low > locations in memory and the high set in the high locations. Then > repeat on both sets until the set consists of only one item. > [moved to below] - the algorithm works best when the sets are > approximately equal in size. [snip elaboration] Yes, but the last part isn't always possible. Quicksort is an obvious example. > You can tail recurse out the second call, but that just confuses > the matter - On the contrary, usually divide-and-conquer type algorithms are naturally tail recursive for the last portion processed. Given that, it sometimes is a good idea - again Quicksort provides an example - to consider which portion to do first, to take advantage of that natural tail recursion. > But factorial is iterative. [snip elaboration] No, it isn't. I understand you think of it that way, but there is nothing inherent in the factorial function that says how it is computed should be iterative. That is simply your bias, not any sort of inherent or inevitable truth.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-24 15:07 -0700 |
| Message-ID | <39b08b56-6d07-4e6b-a268-7878493771d3@googlegroups.com> |
| In reply to | #66309 |
On Friday, July 24, 2015 at 9:05:23 PM UTC+1, Tim Rentsch wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > On the contrary, usually divide-and-conquer type algorithms are > naturally tail recursive for the last portion processed. Given > that, it sometimes is a good idea - again Quicksort provides an > example - to consider which portion to do first, to take advantage > of that natural tail recursion. > You hide the symmetry if you write the function in C and hand- optimise the second call to a jump. For something as fundamental as a quicksort, it's worth doing. But Heathfield's law usually applies.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-30 12:42 -0700 |
| Message-ID | <kfnegjpctz1.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66318 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, July 24, 2015 at 9:05:23 PM UTC+1, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> On the contrary, usually divide-and-conquer type algorithms are >> naturally tail recursive for the last portion processed. Given >> that, it sometimes is a good idea - again Quicksort provides an >> example - to consider which portion to do first, to take advantage >> of that natural tail recursion. > > You hide the symmetry if you write the function in C and hand- > optimise the second call to a jump. [snip] I wouldn't do that. I would just write the (two sets of) recursive calls, and rely (with suitable verification, of course) on the compiler to turn the tail recursion(s) into a loop. These days I think it is commonplace for C compilers to do that successfully (and in fact has been for some time).
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-24 15:38 -0500 |
| Message-ID | <td85rap7i48qjjlhol9jf9259si94v0h2j@4ax.com> |
| In reply to | #66027 |
On Mon, 20 Jul 2015 10:28:44 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:
>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Wed, 15 Jul 2015 09:36:52 -0700, Tim Rentsch
>> <txr@alumni.caltech.edu> wrote:
>>
>>> Keith Thompson <kst-u@mib.org> writes:
>>>
>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>
>>>> [...]
>>>>
>>>>>> The most obvious is factorial,
>>>>>
>>>>> Hogwash. You're assuming a naive recursive formulation, which
>>>>> is a bad assumption. For small integers it hardly makes a
>>>>> difference - easier just to do a table lookup. For large
>>>>> integers a recursive formulation is better: for example,
>>>>> computing 1000000 factorial (or was it 10000000 factorial?
>>>>> I think it was one of the two), my simple recursive version
>>>>> ran about 50 times faster than the simple looping version.
>>>>
>>>> I'm curious about the details. How do you get a 50x speedup using
>>>> recursion rather than iteration?
>>>>
>>>> Of course with numbers that big the representation is going to be an
>>>> issue.
>>>
>>> Right, and that's the heart of the matter. The key idea is that
>>> when you multiply multiple-precision integers you want to keep
>>> the numbers as small as you can, or in other words have the two
>>> numbers being multiplied as close to being the same size as you
>>> can. With the understanding that I am writing in regular C
>>> rather than a language that has multiple-precision arithmetic
>>> built-in, here is the algorithm:
>>>
>>> static unsigned product( unsigned, unsigned );
>>>
>>> unsigned
>>> factorial( unsigned n ){
>>> return product( n, 1 );
>>> }
>>>
>>> unsigned
>>> product( unsigned n, unsigned v ){
>>> /* the product of 'n' consecutive integers starting at 'v' */
>>> if( n < 2 ) return v;
>>> return product( n-n/2, v ) * product( n/2, v + (n-n/2) );
>>> }
>>>
>>> This computes factorial using a binary tree of products, so the
>>> numbers being multiplied at each stage are, roughly, the same
>>> size. Silly for small integers, but a huge win for computing
>>> factorials of large integers.
>>
>> You've implemented a completely different algorithm, not just a
>> non-recursive version of the same algorithm.
>
>I never claimed to be using a transformed version of the simple
>iterative algorithm, only that recursion is useful (or more
>accurately, can be useful) in the problem of computing factorial.
>
>> This is like saying that recursive algorithms are better by
>> comparing Quicksort to a bubble sort.
>
>First I didn't say that recursive algorithms are better, only
>that (for factorial) they aren't always worse (and are better
>in this particular case).
>
>Second I don't think your analogy is quite on-point. The
>iterative algorithm and the recursive algorithm I gave compute
>all the same multiplications, it just computes them in a
>different order. The reason Quicksort is better than bubble
>sort is because it does very different computations, and most
>notably fewer computations. Certainly the recursive factorial
>algorithm is not exactly the same as the regular iterative one,
>but the differences are not nearly as dramatic as those between
>Quicksort and bubble sort.
Not that it really matters, but I think it's a pretty apt comparision
- in both cases you're turning a simple(r) approach into a
divide-and-conqure approach.
[toc] | [prev] | [next] | [standalone]
Page 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web