Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33379 > unrolled thread
| Started by | Walter Banks <walter@bytecraft.com> |
|---|---|
| First post | 2014-09-16 11:22 -0400 |
| Last post | 2014-09-19 02:53 -0700 |
| Articles | 20 on this page of 230 — 25 participants |
Back to article view | Back to comp.lang.forth
Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 11:22 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 11:41 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:20 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 13:39 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:11 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 17:24 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:58 -0400
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 08:47 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 14:41 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-16 18:55 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 14:33 -1000
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 18:30 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-16 15:44 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:22 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 09:18 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:39 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:41 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 16:11 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 16:34 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-17 17:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 07:21 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 10:01 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 07:42 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 14:46 +0000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 08:09 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 03:41 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:31 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 14:53 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 16:44 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 15:52 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-30 00:08 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 04:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:48 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 12:26 -0500
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 17:07 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-17 07:20 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:03 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:40 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 09:56 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:54 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 15:13 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 13:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 11:13 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 21:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 16:57 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-23 00:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 19:53 -1000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 03:48 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-23 16:01 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 08:07 -1000
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-09-23 22:11 +0100
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 16:22 -0500
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 11:28 -1000
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-24 11:56 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:52 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:00 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:04 -0400
Re: Metrics on stack usage Michael Barry <barrym95838@yahoo.com> - 2014-09-24 16:08 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 12:23 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 19:33 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:02 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-25 18:48 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 16:58 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-24 16:02 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 19:14 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 10:15 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 13:54 -1000
Typing, was [Re: Metrics on stack usage] "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-24 21:07 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 15:25 -1000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-24 18:43 -0700
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 16:08 -1000
Re: Typing, was [Re: Metrics on stack usage] Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:11 -0700
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-10-01 09:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:38 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-29 17:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-30 09:13 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-30 22:37 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-03 16:10 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 08:42 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 14:59 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 09:07 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 17:28 -0400
Re: Typing, was [Re: Metrics on stack usage] Howerd <howerdo@yahoo.co.uk> - 2014-10-04 11:15 -0700
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-07 23:37 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-07 15:07 -1000
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-12 03:03 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-12 10:42 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-13 00:26 +0200
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-11 19:30 -1000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-08 03:42 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 02:46 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 00:43 +0200
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 18:45 +0000
Re: Typing, was [Re: Metrics on stack usage] "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-25 09:22 +0200
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 17:09 +0000
Re: Metrics on stack usage Kaz Kylheku <kaz@kylheku.com> - 2014-09-25 01:43 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:15 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:19 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:06 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 04:25 -0400
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 03:15 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 14:43 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 22:23 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:42 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 14:23 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 10:14 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 17:10 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 12:31 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 21:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 01:34 +0200
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-05 03:29 -0500
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-05 13:46 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-05 15:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 03:44 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 00:12 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-05 18:56 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 01:34 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 19:57 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-07 04:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 16:21 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 05:43 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 02:35 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 21:48 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 05:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 01:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 21:27 +0200
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 00:01 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 19:59 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 03:33 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:30 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-11 15:22 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-11 22:24 -0400
Loading libraries (was: Metrics on stack usage) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-11 09:23 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:11 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:36 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:38 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 23:39 -0400
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-11 12:25 +0100
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 07:52 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 00:34 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-01 23:26 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-01 16:15 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-01 21:57 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 01:20 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-02 15:59 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 19:29 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-03 15:03 +0000
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 02:27 +0200
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-05 09:22 +0100
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-23 19:36 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:40 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-16 17:06 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 07:43 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:04 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:34 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:30 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-17 12:42 -1000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:33 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-18 11:53 -1000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-19 01:14 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 03:32 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:41 +0000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 12:14 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:41 +0000
Re: Metrics on stack usage mhx@iae.nl - 2014-09-19 12:31 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 12:59 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:05 +0000
Re: Metrics on stack usage Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-09-21 07:44 +0200
Re: Metrics on stack usage Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-09-17 11:10 +0200
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-17 14:20 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:41 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-17 16:44 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-18 10:26 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-19 00:12 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-18 19:15 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-18 17:14 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:59 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-19 12:20 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-20 09:04 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 18:08 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-30 04:33 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 19:30 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-30 11:24 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-30 10:55 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-30 18:39 -0700
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-10-01 01:44 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-01 03:57 -0500
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 18:45 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-02 07:53 -0400
Re: Metrics on stack usage G Smith <do.not.use@tectimco.com> - 2014-10-02 13:22 +0100
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-02 08:36 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-02 15:34 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:08 +0000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 18:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-19 13:28 -1000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 19:57 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 13:09 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-20 13:27 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 08:04 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 08:55 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:01 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:15 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 06:57 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 07:31 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:04 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:17 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:49 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:57 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 19:47 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 02:58 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:28 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-21 11:24 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:55 -0400
Re: Metrics on stack usage Coos Haak <chforth@hccnet.nl> - 2014-09-20 14:57 +0200
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:22 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:25 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:08 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:38 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:19 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:35 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:00 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 08:54 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 03:26 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 10:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:29 -0400
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:53 -0700
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-20 08:04 -0400 |
| Message-ID | <lvjqgg$uhv$1@dont-email.me> |
| In reply to | #33455 |
On 9/20/2014 7:27 AM, Celeros wrote: > > But as I understand it, you cannot reduce all types of recursive code to > itterative versions is that right? So supposing that there are some > algorithms that simply cannot be made non recursive... I am no expert in computer science, but I believe the two are fundamentally equivalent. When I did a quick search this is stated by several sources. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-20 08:55 -0500 |
| Message-ID | <h8mdnc0empbZGoDJnZ2dnUU7-SmdnZ2d@supernews.com> |
| In reply to | #33456 |
rickman <gnuarm@gmail.com> wrote: > On 9/20/2014 7:27 AM, Celeros wrote: >> >> But as I understand it, you cannot reduce all types of recursive >> code to itterative versions is that right? So supposing that there >> are some algorithms that simply cannot be made non recursive... > > I am no expert in computer science, but I believe the two are > fundamentally equivalent. When I did a quick search this is stated by > several sources. It depends on what is meant by "recursive". It is true that any recursive algorithm can be implemented in a language which doesn't support recursive subroutine calls. It is not true that you can always do it without some auxiliary storage for a stack. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-20 15:01 -0400 |
| Message-ID | <lvkiv1$8to$1@dont-email.me> |
| In reply to | #33458 |
On 9/20/2014 9:55 AM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> On 9/20/2014 7:27 AM, Celeros wrote: >>> >>> But as I understand it, you cannot reduce all types of recursive >>> code to itterative versions is that right? So supposing that there >>> are some algorithms that simply cannot be made non recursive... >> >> I am no expert in computer science, but I believe the two are >> fundamentally equivalent. When I did a quick search this is stated by >> several sources. > > It depends on what is meant by "recursive". It is true that any > recursive algorithm can be implemented in a language which doesn't > support recursive subroutine calls. It is not true that you can > always do it without some auxiliary storage for a stack. I think what you just described is a problem that can't be coded using a defined amount of memory with an undefined input. What is the point of the distinction of recursion and iterative? The question was how deep a stack is needed. The real question is "how much memory" and of course you can find problems that will eat up any amount of memory you have available. So the issue of stack depth for recursive problems is really an issue that is related to the bigger problem of memory size. Recursion uses the stack instead of using main memory which some would say is inappropriate. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-20 17:34 -0500 |
| Message-ID | <-IOdnQkYAeBsnYPJnZ2dnUU7-YudnZ2d@supernews.com> |
| In reply to | #33467 |
rickman <gnuarm@gmail.com> wrote: > On 9/20/2014 9:55 AM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >>> On 9/20/2014 7:27 AM, Celeros wrote: >>>> >>>> But as I understand it, you cannot reduce all types of recursive >>>> code to itterative versions is that right? So supposing that there >>>> are some algorithms that simply cannot be made non recursive... >>> >>> I am no expert in computer science, but I believe the two are >>> fundamentally equivalent. When I did a quick search this is stated by >>> several sources. >> >> It depends on what is meant by "recursive". It is true that any >> recursive algorithm can be implemented in a language which doesn't >> support recursive subroutine calls. It is not true that you can >> always do it without some auxiliary storage for a stack. > > I think what you just described is a problem that can't be coded using a > defined amount of memory with an undefined input. Yes, but that is another distinction. > What is the point of the distinction of recursion and iterative? In order to compare and describe algorithms, we have to make distinctions. A recursive algorithm solves a problem by breaking it into successively smaller instances of the same problem. Many recursive algorithms require you to remember what you were doing and return to that point, as in recursive descent parsing, quicksorting, etc. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-20 19:15 -0400 |
| Message-ID | <lvl1rp$bmg$1@dont-email.me> |
| In reply to | #33473 |
On 9/20/2014 6:34 PM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> On 9/20/2014 9:55 AM, Andrew Haley wrote: >>> rickman <gnuarm@gmail.com> wrote: >>>> On 9/20/2014 7:27 AM, Celeros wrote: >>>>> >>>>> But as I understand it, you cannot reduce all types of recursive >>>>> code to itterative versions is that right? So supposing that there >>>>> are some algorithms that simply cannot be made non recursive... >>>> >>>> I am no expert in computer science, but I believe the two are >>>> fundamentally equivalent. When I did a quick search this is stated by >>>> several sources. >>> >>> It depends on what is meant by "recursive". It is true that any >>> recursive algorithm can be implemented in a language which doesn't >>> support recursive subroutine calls. It is not true that you can >>> always do it without some auxiliary storage for a stack. >> >> I think what you just described is a problem that can't be coded using a >> defined amount of memory with an undefined input. > > Yes, but that is another distinction. > >> What is the point of the distinction of recursion and iterative? > > In order to compare and describe algorithms, we have to make > distinctions. A recursive algorithm solves a problem by breaking it > into successively smaller instances of the same problem. Many > recursive algorithms require you to remember what you were doing and > return to that point, as in recursive descent parsing, quicksorting, > etc. Then if your purpose in the distinction is just to analyze algorithms, then the two are equally capable. No point in taking issue with any data structures that may be required. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-21 03:34 -0500 |
| Message-ID | <pK2dndCBvIwVEIPJnZ2dnUU7-S-dnZ2d@supernews.com> |
| In reply to | #33475 |
rickman <gnuarm@gmail.com> wrote: > On 9/20/2014 6:34 PM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >>> On 9/20/2014 9:55 AM, Andrew Haley wrote: >>>> rickman <gnuarm@gmail.com> wrote: >>>>> On 9/20/2014 7:27 AM, Celeros wrote: >>>>>> >>>>>> But as I understand it, you cannot reduce all types of recursive >>>>>> code to itterative versions is that right? So supposing that there >>>>>> are some algorithms that simply cannot be made non recursive... >>>>> >>>>> I am no expert in computer science, but I believe the two are >>>>> fundamentally equivalent. When I did a quick search this is stated by >>>>> several sources. >>>> >>>> It depends on what is meant by "recursive". It is true that any >>>> recursive algorithm can be implemented in a language which doesn't >>>> support recursive subroutine calls. It is not true that you can >>>> always do it without some auxiliary storage for a stack. >>> >>> I think what you just described is a problem that can't be coded using a >>> defined amount of memory with an undefined input. >> >> Yes, but that is another distinction. >> >>> What is the point of the distinction of recursion and iterative? >> >> In order to compare and describe algorithms, we have to make >> distinctions. A recursive algorithm solves a problem by breaking it >> into successively smaller instances of the same problem. Many >> recursive algorithms require you to remember what you were doing and >> return to that point, as in recursive descent parsing, quicksorting, >> etc. > > Then if your purpose in the distinction is just to analyze algorithms, > then the two are equally capable. What does this mean? Is a non-recursive sorting alorithm just "as capable" as, say, quicksort? > No point in taking issue with any data structures that may be > required. Or this? Is there no point in describing algorithms? You're not making any sense. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-21 06:57 -0400 |
| Message-ID | <lvmauo$3lb$1@dont-email.me> |
| In reply to | #33481 |
On 9/21/2014 4:34 AM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> On 9/20/2014 6:34 PM, Andrew Haley wrote: >>> rickman <gnuarm@gmail.com> wrote: >>>> On 9/20/2014 9:55 AM, Andrew Haley wrote: >>>>> rickman <gnuarm@gmail.com> wrote: >>>>>> On 9/20/2014 7:27 AM, Celeros wrote: >>>>>>> >>>>>>> But as I understand it, you cannot reduce all types of recursive >>>>>>> code to itterative versions is that right? So supposing that there >>>>>>> are some algorithms that simply cannot be made non recursive... >>>>>> >>>>>> I am no expert in computer science, but I believe the two are >>>>>> fundamentally equivalent. When I did a quick search this is stated by >>>>>> several sources. >>>>> >>>>> It depends on what is meant by "recursive". It is true that any >>>>> recursive algorithm can be implemented in a language which doesn't >>>>> support recursive subroutine calls. It is not true that you can >>>>> always do it without some auxiliary storage for a stack. >>>> >>>> I think what you just described is a problem that can't be coded using a >>>> defined amount of memory with an undefined input. >>> >>> Yes, but that is another distinction. >>> >>>> What is the point of the distinction of recursion and iterative? >>> >>> In order to compare and describe algorithms, we have to make >>> distinctions. A recursive algorithm solves a problem by breaking it >>> into successively smaller instances of the same problem. Many >>> recursive algorithms require you to remember what you were doing and >>> return to that point, as in recursive descent parsing, quicksorting, >>> etc. >> >> Then if your purpose in the distinction is just to analyze algorithms, >> then the two are equally capable. > > What does this mean? Is a non-recursive sorting alorithm just "as > capable" as, say, quicksort? I'm saying quicksort implemented either way is equivalent. >> No point in taking issue with any data structures that may be >> required. > > Or this? Is there no point in describing algorithms? You're not > making any sense. Sorry. I'm trying to understand the basis of the equivalence or non-equivalence of recursion and iteration. If you are analyzing algorithms then you can implement an algorithm either way and it makes no difference to the algorithm. This started as a question about stack size requirements and I believe I asked if there was any reason that recursion was required... any algorithms that required recursion. I think the answer was no because you can always use iteration and if needed use memory to store the intermediate values. The real issue is not the need for recursion, but the need for intermediate values which is a memory problem. So the stack size is not so much the issue, but the fact that for some algorithms the memory usage is not bounded. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-21 07:31 -0500 |
| Message-ID | <4YudnXomv6C5WIPJnZ2dnUU7-f-dnZ2d@supernews.com> |
| In reply to | #33484 |
rickman <gnuarm@gmail.com> wrote: > On 9/21/2014 4:34 AM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >>> On 9/20/2014 6:34 PM, Andrew Haley wrote: >>>> rickman <gnuarm@gmail.com> wrote: >>>>> On 9/20/2014 9:55 AM, Andrew Haley wrote: >>>>>> >>>>>> It depends on what is meant by "recursive". It is true that any >>>>>> recursive algorithm can be implemented in a language which doesn't >>>>>> support recursive subroutine calls. It is not true that you can >>>>>> always do it without some auxiliary storage for a stack. >>>>> >>>>> I think what you just described is a problem that can't be coded using a >>>>> defined amount of memory with an undefined input. >>>> >>>> Yes, but that is another distinction. >>>> >>>>> What is the point of the distinction of recursion and iterative? >>>> >>>> In order to compare and describe algorithms, we have to make >>>> distinctions. A recursive algorithm solves a problem by breaking it >>>> into successively smaller instances of the same problem. Many >>>> recursive algorithms require you to remember what you were doing and >>>> return to that point, as in recursive descent parsing, quicksorting, >>>> etc. >>> >>> Then if your purpose in the distinction is just to analyze algorithms, >>> then the two are equally capable. >> >> What does this mean? Is a non-recursive sorting alorithm just "as >> capable" as, say, quicksort? > > I'm saying quicksort implemented either way is equivalent. Ok. But not matter which way you implement quicksort, quicksort is always going to be a recursive algorithm. The important thing to be clear about is that recursive algorithms such as quicksort can be expressed without using recursive calls, but you may need to add a stack. >>> No point in taking issue with any data structures that may be >>> required. >> >> Or this? Is there no point in describing algorithms? You're not >> making any sense. > > Sorry. I'm trying to understand the basis of the equivalence or > non-equivalence of recursion and iteration. If you are analyzing > algorithms then you can implement an algorithm either way and it > makes no difference to the algorithm. > > This started as a question about stack size requirements and I > believe I asked if there was any reason that recursion was > required... any algorithms that required recursion. I think the > answer was no because you can always use iteration and if needed use > memory to store the intermediate values. Indeed. > The real issue is not the need for recursion, but the need for > intermediate values which is a memory problem. So the stack size is > not so much the issue, Isn't that always going to be true? You can limit stack usage in any Forth program by shuffling stack items into data space. I'd hate to do it, though. And I'm sure you would too. > but the fact that for some algorithms the memory usage is not > bounded. Surely stack size is the issue. Of course it doesn't have to be *the data stack*: you can use a stack in data space. It'll be inconvenient, though. And surely that is the point. You can always avoid using the data stack, in recursive and non-recursive programs, but it's going to be a pain. The question therefore isn't whether it can be done but how much it will hurt. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-21 18:04 -0400 |
| Message-ID | <lvni21$oij$1@dont-email.me> |
| In reply to | #33490 |
On 9/21/2014 8:31 AM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> On 9/21/2014 4:34 AM, Andrew Haley wrote: >>> rickman <gnuarm@gmail.com> wrote: >>>> On 9/20/2014 6:34 PM, Andrew Haley wrote: >>>>> rickman <gnuarm@gmail.com> wrote: >>>>>> On 9/20/2014 9:55 AM, Andrew Haley wrote: >>>>>>> >>>>>>> It depends on what is meant by "recursive". It is true that any >>>>>>> recursive algorithm can be implemented in a language which doesn't >>>>>>> support recursive subroutine calls. It is not true that you can >>>>>>> always do it without some auxiliary storage for a stack. >>>>>> >>>>>> I think what you just described is a problem that can't be coded using a >>>>>> defined amount of memory with an undefined input. >>>>> >>>>> Yes, but that is another distinction. >>>>> >>>>>> What is the point of the distinction of recursion and iterative? >>>>> >>>>> In order to compare and describe algorithms, we have to make >>>>> distinctions. A recursive algorithm solves a problem by breaking it >>>>> into successively smaller instances of the same problem. Many >>>>> recursive algorithms require you to remember what you were doing and >>>>> return to that point, as in recursive descent parsing, quicksorting, >>>>> etc. >>>> >>>> Then if your purpose in the distinction is just to analyze algorithms, >>>> then the two are equally capable. >>> >>> What does this mean? Is a non-recursive sorting alorithm just "as >>> capable" as, say, quicksort? >> >> I'm saying quicksort implemented either way is equivalent. > > Ok. But not matter which way you implement quicksort, quicksort is > always going to be a recursive algorithm. The important thing to be > clear about is that recursive algorithms such as quicksort can be > expressed without using recursive calls, but you may need to add a > stack. > >>>> No point in taking issue with any data structures that may be >>>> required. >>> >>> Or this? Is there no point in describing algorithms? You're not >>> making any sense. >> >> Sorry. I'm trying to understand the basis of the equivalence or >> non-equivalence of recursion and iteration. If you are analyzing >> algorithms then you can implement an algorithm either way and it >> makes no difference to the algorithm. >> >> This started as a question about stack size requirements and I >> believe I asked if there was any reason that recursion was >> required... any algorithms that required recursion. I think the >> answer was no because you can always use iteration and if needed use >> memory to store the intermediate values. > > Indeed. > >> The real issue is not the need for recursion, but the need for >> intermediate values which is a memory problem. So the stack size is >> not so much the issue, > > Isn't that always going to be true? You can limit stack usage in any > Forth program by shuffling stack items into data space. I'd hate to > do it, though. And I'm sure you would too. > >> but the fact that for some algorithms the memory usage is not >> bounded. > > Surely stack size is the issue. Of course it doesn't have to be *the > data stack*: you can use a stack in data space. It'll be > inconvenient, though. Hmmmm... you seem hung up on the idea that recursion is somehow different than other approaches to solving problems. That is the point. There is no difference. If you need some amount of memory to solve a problem, it doesn't matter if it is allocated as stack or space in main memory. The amount of memory needed will depend on the problem size. What you said above about shuffling stack items into memory is not used very often because without using the stack for app data storage like we are discussing, the stack doesn't normally need much space. > And surely that is the point. You can always avoid using the data > stack, in recursive and non-recursive programs, but it's going to be a > pain. The question therefore isn't whether it can be done but how > much it will hurt. I think this is a matter of perspective. Recursion is not required to solve coding problems. Whether recursion is used or not, there are a class of problems which require memory in proportion to the size of the data - which include some recursive problems. Recursion simply moves that memory problem to the stacks. An iterative solution is more memory efficient because it only saves the data needed while the recursive approach also needs to store the return addresses. I suppose tail call optimization can be used to deal with that though. So choose your poison. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-21 15:17 -0700 |
| Message-ID | <7xlhpcbou3.fsf@ruckus.brouhaha.com> |
| In reply to | #33494 |
rickman <gnuarm@gmail.com> writes: > I think this is a matter of perspective. Recursion is not required to > solve coding problems. Whether recursion is used or not, there are a > class of problems which require memory in proportion to the size of > the data - which include some recursive problems. One way to look at it is that an iterative program at its deepest point has N levels of nested loops, for some N. But a recursive program in effect can nest loops to unlimited depth.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-21 18:49 -0400 |
| Message-ID | <lvnkmk$69f$2@dont-email.me> |
| In reply to | #33495 |
On 9/21/2014 6:17 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> I think this is a matter of perspective. Recursion is not required to >> solve coding problems. Whether recursion is used or not, there are a >> class of problems which require memory in proportion to the size of >> the data - which include some recursive problems. > > One way to look at it is that an iterative program at its deepest point > has N levels of nested loops, for some N. But a recursive program > in effect can nest loops to unlimited depth. Really? If you are using recursion in a way that can be unlimited, the iteration can also be unlimited... In fact by using tail call optimization to make recursion unlimited, you have turned it into iteration. :) -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-21 15:57 -0700 |
| Message-ID | <7xzjdsoa2z.fsf@ruckus.brouhaha.com> |
| In reply to | #33496 |
rickman <gnuarm@gmail.com> writes: > Really? If you are using recursion in a way that can be unlimited, > the iteration can also be unlimited... In fact by using tail call > optimization to make recursion unlimited, you have turned it into > iteration. :) TCO is only possible in the cases where the recursion is iteration in disguise. Do you know the Ackermann function? How would you implement it with just iteration? This is an extreme example. http://en.wikipedia.org/wiki/Ackermann_function
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-21 19:47 -0400 |
| Message-ID | <lvno2p$qa5$2@dont-email.me> |
| In reply to | #33497 |
On 9/21/2014 6:57 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Really? If you are using recursion in a way that can be unlimited, >> the iteration can also be unlimited... In fact by using tail call >> optimization to make recursion unlimited, you have turned it into >> iteration. :) > > TCO is only possible in the cases where the recursion is iteration in > disguise. > > Do you know the Ackermann function? How would you implement it with > just iteration? This is an extreme example. > > http://en.wikipedia.org/wiki/Ackermann_function Can you calculate the Ackermann function of an arbitrarily large number recursively? Not witholding the width of the word in your computer. Did you see the context? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-09-22 02:58 -0500 |
| Message-ID | <AaidneL9CeU8S4LJnZ2dnUU7-f-dnZ2d@supernews.com> |
| In reply to | #33494 |
rickman <gnuarm@gmail.com> wrote: > On 9/21/2014 8:31 AM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >>> The real issue is not the need for recursion, but the need for >>> intermediate values which is a memory problem. So the stack size is >>> not so much the issue, >> >> Isn't that always going to be true? You can limit stack usage in any >> Forth program by shuffling stack items into data space. I'd hate to >> do it, though. And I'm sure you would too. >> >>> but the fact that for some algorithms the memory usage is not >>> bounded. >> >> Surely stack size is the issue. Of course it doesn't have to be *the >> data stack*: you can use a stack in data space. It'll be >> inconvenient, though. > > Hmmmm... you seem hung up on the idea that recursion is somehow > different than other approaches to solving problems. Well, yes. It is. It's different from non-recursive approaches. > That is the point. There is no difference. If you need some amount > of memory to solve a problem, it doesn't matter if it is allocated > as stack or space in main memory. The amount of memory needed will > depend on the problem size. It may not matter to the computer, but it does matter to human beings when talking about the technique. > What you said above about shuffling stack items into memory is not used > very often because without using the stack for app data storage like we > are discussing, the stack doesn't normally need much space. > >> And surely that is the point. You can always avoid using the data >> stack, in recursive and non-recursive programs, but it's going to be a >> pain. The question therefore isn't whether it can be done but how >> much it will hurt. > > I think this is a matter of perspective. Recursion is not required to > solve coding problems. Sure it is. Even if you implement, say, a recursive descent parser without any recursive calls, it's still recursive: you've implemented recursion manually, with a stack. Maybe the issue here is just one of terminology? > Whether recursion is used or not, there are a class of problems > which require memory in proportion to the size of the data - which > include some recursive problems. Recursion simply moves that memory > problem to the stacks. An iterative solution is more memory > efficient because it only saves the data needed while the recursive > approach also needs to store the return addresses. Maybe. If you have several places to return to, it may be just as efficient simply to store the return address as some data item which tells you what to do next. > I suppose tail call optimization can be used to deal with that > though. Only if the algorithm is tail recursive, surely. > So choose your poison. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-22 05:28 -0400 |
| Message-ID | <lvoq4p$gq6$2@dont-email.me> |
| In reply to | #33504 |
On 9/22/2014 3:58 AM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> On 9/21/2014 8:31 AM, Andrew Haley wrote: >>> rickman <gnuarm@gmail.com> wrote: >>>> The real issue is not the need for recursion, but the need for >>>> intermediate values which is a memory problem. So the stack size is >>>> not so much the issue, >>> >>> Isn't that always going to be true? You can limit stack usage in any >>> Forth program by shuffling stack items into data space. I'd hate to >>> do it, though. And I'm sure you would too. >>> >>>> but the fact that for some algorithms the memory usage is not >>>> bounded. >>> >>> Surely stack size is the issue. Of course it doesn't have to be *the >>> data stack*: you can use a stack in data space. It'll be >>> inconvenient, though. >> >> Hmmmm... you seem hung up on the idea that recursion is somehow >> different than other approaches to solving problems. > > Well, yes. It is. It's different from non-recursive approaches. > >> That is the point. There is no difference. If you need some amount >> of memory to solve a problem, it doesn't matter if it is allocated >> as stack or space in main memory. The amount of memory needed will >> depend on the problem size. > > It may not matter to the computer, but it does matter to human beings > when talking about the technique. > >> What you said above about shuffling stack items into memory is not used >> very often because without using the stack for app data storage like we >> are discussing, the stack doesn't normally need much space. >> >>> And surely that is the point. You can always avoid using the data >>> stack, in recursive and non-recursive programs, but it's going to be a >>> pain. The question therefore isn't whether it can be done but how >>> much it will hurt. >> >> I think this is a matter of perspective. Recursion is not required to >> solve coding problems. > > Sure it is. Even if you implement, say, a recursive descent parser > without any recursive calls, it's still recursive: you've implemented > recursion manually, with a stack. Maybe the issue here is just one of > terminology? > >> Whether recursion is used or not, there are a class of problems >> which require memory in proportion to the size of the data - which >> include some recursive problems. Recursion simply moves that memory >> problem to the stacks. An iterative solution is more memory >> efficient because it only saves the data needed while the recursive >> approach also needs to store the return addresses. > > Maybe. If you have several places to return to, it may be just as > efficient simply to store the return address as some data item which > tells you what to do next. > >> I suppose tail call optimization can be used to deal with that >> though. > > Only if the algorithm is tail recursive, surely. > >> So choose your poison. I'm not going to continue to debate the issues. I suggest you look at the context rather than commenting on each individual statement. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-09-21 11:24 +0000 |
| Message-ID | <541eb567$0$15928$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #33475 |
In article <lvl1rp$bmg$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 9/20/2014 6:34 PM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >>> On 9/20/2014 9:55 AM, Andrew Haley wrote: >>>> rickman <gnuarm@gmail.com> wrote: >>>>> On 9/20/2014 7:27 AM, Celeros wrote: >>>>>> >>>>>> But as I understand it, you cannot reduce all types of recursive >>>>>> code to itterative versions is that right? So supposing that there >>>>>> are some algorithms that simply cannot be made non recursive... >>>>> >>>>> I am no expert in computer science, but I believe the two are >>>>> fundamentally equivalent. When I did a quick search this is stated by >>>>> several sources. >>>> >>>> It depends on what is meant by "recursive". It is true that any >>>> recursive algorithm can be implemented in a language which doesn't >>>> support recursive subroutine calls. It is not true that you can >>>> always do it without some auxiliary storage for a stack. >>> >>> I think what you just described is a problem that can't be coded using a >>> defined amount of memory with an undefined input. >> >> Yes, but that is another distinction. >> >>> What is the point of the distinction of recursion and iterative? >> >> In order to compare and describe algorithms, we have to make >> distinctions. A recursive algorithm solves a problem by breaking it >> into successively smaller instances of the same problem. Many >> recursive algorithms require you to remember what you were doing and >> return to that point, as in recursive descent parsing, quicksorting, >> etc. > >Then if your purpose in the distinction is just to analyze algorithms, >then the two are equally capable. No point in taking issue with any >data structures that may be required. I take issue that you think that describing an algorithm as recursive makes no sense. You know that Knuth describes his algorithms - also the recursive ones - as iterative, may be with an extra stack. Now if you look at the Toom Cook method for multiplication, Knuth's description drives you crazy (unless you just implement and don't want to understand). It is convenient if you have to program in FORTRAN, and that is probably the reason. I've converted it to a recursive version so it became understandable, and implemented it. Bottom line, Toom Cook is a recursive algorithm, and so are others. Despite your "all computers are equivalent to Turing machines so there!" argument. > >-- > >Rick Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-21 07:55 -0400 |
| Message-ID | <lvmed2$mrp$2@dont-email.me> |
| In reply to | #33486 |
On 9/21/2014 7:24 AM, Albert van der Horst wrote: > In article <lvl1rp$bmg$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 9/20/2014 6:34 PM, Andrew Haley wrote: >>> rickman <gnuarm@gmail.com> wrote: >>>> On 9/20/2014 9:55 AM, Andrew Haley wrote: >>>>> rickman <gnuarm@gmail.com> wrote: >>>>>> On 9/20/2014 7:27 AM, Celeros wrote: >>>>>>> >>>>>>> But as I understand it, you cannot reduce all types of recursive >>>>>>> code to itterative versions is that right? So supposing that there >>>>>>> are some algorithms that simply cannot be made non recursive... >>>>>> >>>>>> I am no expert in computer science, but I believe the two are >>>>>> fundamentally equivalent. When I did a quick search this is stated by >>>>>> several sources. >>>>> >>>>> It depends on what is meant by "recursive". It is true that any >>>>> recursive algorithm can be implemented in a language which doesn't >>>>> support recursive subroutine calls. It is not true that you can >>>>> always do it without some auxiliary storage for a stack. >>>> >>>> I think what you just described is a problem that can't be coded using a >>>> defined amount of memory with an undefined input. >>> >>> Yes, but that is another distinction. >>> >>>> What is the point of the distinction of recursion and iterative? >>> >>> In order to compare and describe algorithms, we have to make >>> distinctions. A recursive algorithm solves a problem by breaking it >>> into successively smaller instances of the same problem. Many >>> recursive algorithms require you to remember what you were doing and >>> return to that point, as in recursive descent parsing, quicksorting, >>> etc. >> >> Then if your purpose in the distinction is just to analyze algorithms, >> then the two are equally capable. No point in taking issue with any >> data structures that may be required. > > I take issue that you think that describing an algorithm as recursive > makes no sense. I didn't say that. > You know that Knuth describes his algorithms - also the recursive ones - > as iterative, may be with an extra stack. > Now if you look at the Toom Cook method for multiplication, Knuth's > description drives you crazy (unless you just implement and don't > want to understand). It is convenient if you have to program in > FORTRAN, and that is probably the reason. > > I've converted it to a recursive version so it became understandable, > and implemented it. > > Bottom line, Toom Cook is a recursive algorithm, and so are others. > > Despite your "all computers are equivalent to Turing machines so there!" > argument. I didn't say that. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-09-20 14:57 +0200 |
| Message-ID | <v1lf7lssos2t.mcbph30ukdc2$.dlg@40tude.net> |
| In reply to | #33455 |
Op Sat, 20 Sep 2014 13:27:44 +0200 schreef Celeros: > On 2014-09-19 02:08 PM, Anton Ertl wrote: >> Celeros <kerneels@gmail.com> writes: >>> Interesting thread. Although not related to the link posted above, I >>> seem to recall from Eric LaForest's thesis: >>> >>> http://www.eecg.toronto.edu/~laforest/Second-Generation_Stack_Computer_Architecture.pdf >>> >>> that research has been done into the stack depth / sizes required for >>> even fairly deep recursive algorithmic problems such as the 8 queens >>> problem, and that it has been shown that usually code can be written >>> that would not require a deep stack at all - tens of items as aposed to >>> hundreds or more. >> >> A typical recursive implementation of 8-queens is not deeply >> recursive, as there are at most 8 levels of recursion. A walk of a >> degenerated tree would be a more realistic example. >> > Ok, thanks. I suppose it's not the 8 queens problem but the n-queens > problem then :-). The eight queens problem has to do with chess. There is no way to put more queens on a chessboard than eight. I ran this program, and found that it needed 19 cells on the data stack and 41 on the return stack. > While writing it I thought, hmm.... 8 Queens - can that really be that > recursive - but I did not have time to go refresh my memory on what the > problem actually is, so as a shortcut I replaced my initial "very" with > "fairly" - just in case, and good so else I would have been even more > wrong! :-) No time to google "8 queens problem"? -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-20 15:22 +0000 |
| Message-ID | <2014Sep20.172235@mips.complang.tuwien.ac.at> |
| In reply to | #33457 |
Coos Haak <chforth@hccnet.nl> writes:
>Op Sat, 20 Sep 2014 13:27:44 +0200 schreef Celeros:
>> Ok, thanks. I suppose it's not the 8 queens problem but the n-queens
>> problem then :-).
>
>The eight queens problem has to do with chess. There is no way to put more
>queens on a chessboard than eight.
The n-queens problem is the generalization of that problem: Put n
queens on an n*n board such that no queen is threatened by another
queen (i.e., is in the same row, column, or diagonal as another
queen).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-20 15:25 +0000 |
| Message-ID | <2014Sep20.172524@mips.complang.tuwien.ac.at> |
| In reply to | #33455 |
Celeros <kerneels@gmail.com> writes:
>On 2014-09-19 02:08 PM, Anton Ertl wrote:
[...]
>Need to go check out what is a "degenerated tree ".
A tree that is far from balanced. In the extrem case each node only
has one child.
>> Yes. Many recursive algorithms are of the divide-and-conquer sort,
>> and the expected recursion depth of these algorithms is logarithmic in
>> the problem size. If such a problem can degenerate, one sometimes
>> uses techniques for avoiding the recursion in that case. E.g., for
>> quicksort, you can recurse into the smaller partition, and use
>> tail-recursion (i.e., iteration) for the larger, thus ensuring that the recursion depth does not exceed ld(n).
>>
>
>But as I understand it, you cannot reduce all types of recursive code to
>itterative versions is that right?
You can convert everything, but often you still need a stack for
storing data.
But the usual way to avoid recursion is to choose algorithms and data
structures that don't need recursion.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web