Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #7740 > unrolled thread
| Started by | Wendell <wendellxe@yahoo.com> |
|---|---|
| First post | 2011-12-05 18:14 -0800 |
| Last post | 2011-12-14 15:49 +0200 |
| Articles | 20 on this page of 73 — 21 participants |
Back to article view | Back to comp.lang.forth
Readable code and refactoring for optimization Wendell <wendellxe@yahoo.com> - 2011-12-05 18:14 -0800
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-05 17:54 -1000
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-05 17:58 -1000
Re: Readable code and refactoring for optimization Hans Bezemer <thebeez@xs4all.nl> - 2011-12-06 08:49 +0100
Re: Readable code and refactoring for optimization mhx@iae.nl (Marcel Hendrix) - 2011-12-06 07:26 +0200
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-05 22:02 -1000
Re: Readable code and refactoring for optimization Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-07 00:49 +0100
Re: Readable code and refactoring for optimization Paul Rubin <no.email@nospam.invalid> - 2011-12-08 00:08 -0800
Re: Readable code and refactoring for optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-08 11:25 +0000
Re: Readable code and refactoring for optimization Paul Rubin <no.email@nospam.invalid> - 2011-12-08 23:51 -0800
Re: Readable code and refactoring for optimization Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-08 14:47 +0000
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2011-12-08 14:05 -0500
Re: Readable code and refactoring for optimization Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-09 17:21 +0000
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2011-12-10 09:08 -0500
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-10 07:37 -1000
Re: Readable code and refactoring for optimization Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-12 10:27 +0000
Re: Readable code and refactoring for optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 05:02 -0600
Re: Readable code and refactoring for optimization Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-12 11:18 +0000
Re: Readable code and refactoring for optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 05:25 -0600
Re: Readable code and refactoring for optimization Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-12 12:41 +0000
Re: Readable code and refactoring for optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 07:23 -0600
Re: Readable code and refactoring for optimization Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-12 20:28 +0000
Re: Readable code and refactoring for optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-13 04:07 -0600
Re: Readable code and refactoring for optimization Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-13 21:04 +0000
Re: Readable code and refactoring for optimization Arnold Doray <thinksquared@gmail.com> - 2011-12-12 16:01 +0000
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2011-12-26 09:30 -0500
Re: Readable code and refactoring for optimization Arnold Doray <invalid@invalid.com> - 2012-01-08 16:28 +0000
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2012-01-08 20:17 -0500
Re: Readable code and refactoring for optimization Arnold Doray <invalid@invalid.com> - 2012-01-09 10:41 +0000
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2012-01-09 08:55 -0500
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2012-01-09 11:50 -0500
Re: Readable code and refactoring for optimization Arnold Doray <invalid@invalid.com> - 2012-01-10 06:56 +0000
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2012-01-10 16:34 -0500
Re: Readable code and refactoring for optimization Arnold Doray <invalid@invalid.com> - 2012-01-11 06:57 +0000
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2012-01-11 09:50 -0500
Re: Readable code and refactoring for optimization Arnold Doray <invalid@invalid.com> - 2012-01-11 16:28 +0000
Re: Readable code and refactoring for optimization Fritz Wuehler <fritz@spamexpire-201112.rodent.frell.theremailer.net> - 2011-12-12 22:57 +0100
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2011-12-26 09:30 -0500
Re: Readable code and refactoring for optimization Paul Rubin <no.email@nospam.invalid> - 2011-12-08 23:53 -0800
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-09 17:46 -1000
Re: Readable code and refactoring for optimization Josh Grams <josh@qualdan.com> - 2011-12-10 11:39 +0000
Re: Readable code and refactoring for optimization Ian Osgood <iano@quirkster.com> - 2011-12-21 13:09 -0800
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2011-12-10 08:52 -0500
Re: Readable code and refactoring for optimization Paul Rubin <no.email@nospam.invalid> - 2011-12-12 09:11 -0800
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-12 07:48 -1000
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2011-12-12 13:47 -0500
Re: Readable code and refactoring for optimization Paul Rubin <no.email@nospam.invalid> - 2011-12-12 11:46 -0800
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2011-12-12 16:20 -0500
Re: Readable code and refactoring for optimization BruceMcF <agila61@netscape.net> - 2011-12-12 13:48 -0800
Re: Readable code and refactoring for optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-13 10:31 +0000
Re: Readable code and refactoring for optimization Paul Rubin <no.email@nospam.invalid> - 2011-12-12 11:42 -0800
Re: Readable code and refactoring for optimization Mark Wills <markrobertwills@yahoo.co.uk> - 2011-12-12 13:35 -0800
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-12 11:49 -1000
Re: Readable code and refactoring for optimization Paul Rubin <no.email@nospam.invalid> - 2011-12-12 23:50 -0800
Re: Readable code and refactoring for optimization JennyB <jennybrien@googlemail.com> - 2011-12-13 03:04 -0800
Re: Readable code and refactoring for optimization stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-06 11:04 +0000
Re: Readable code and refactoring for optimization John Passaniti <john.passaniti@gmail.com> - 2011-12-06 05:52 -0800
Re: Readable code and refactoring for optimization Arnold Doray <thinksquared@gmail.com> - 2011-12-06 13:52 +0000
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-06 08:22 -1000
Re: Readable code and refactoring for optimization Arnold Doray <thinksquared@gmail.com> - 2011-12-07 08:55 +0000
Re: Readable code and refactoring for optimization Doug Hoffman <glidedog@gmail.com> - 2011-12-11 07:29 -0500
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-11 08:59 -1000
Re: Readable code and refactoring for optimization Mark Wills <forthfreak@gmail.com> - 2011-12-13 05:33 -0800
Re: Readable code and refactoring for optimization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-13 09:05 -0600
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-13 08:10 -1000
Re: Readable code and refactoring for optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-15 16:44 +0000
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-15 09:15 -1000
Re: Readable code and refactoring for optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 17:13 +0000
Re: Readable code and refactoring for optimization "Elizabeth D. Rather" <erather@forth.com> - 2011-12-16 08:11 -1000
Re: Readable code and refactoring for optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-21 13:57 +0000
Re: Readable code and refactoring for optimization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-13 15:06 +0000
Re: Readable code and refactoring for optimization Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-13 16:18 +0100
Re: Readable code and refactoring for optimization mhx@iae.nl (Marcel Hendrix) - 2011-12-14 15:49 +0200
Page 1 of 4 [1] 2 3 4 Next page →
| From | Wendell <wendellxe@yahoo.com> |
|---|---|
| Date | 2011-12-05 18:14 -0800 |
| Subject | Readable code and refactoring for optimization |
| Message-ID | <4e9b11a0-cc0d-464e-a61c-a7867ffe2bfa@n1g2000yqk.googlegroups.com> |
As is illustrated in the "100 doors" example at Rosetta Code [1], Forth can be written in a highly readable style or restricted to low- level operations for performance. The second style seems to be well presented in the Forth Scientific Library. [2] The common advice to developers in most languages is to write first for clarity and correctness, then optimize only if necessary. How well does that approach work for Forth? If you write an application for maximum readability, then discover that performance is insufficient, what are your options? Are there profiling tools to find the hotspots and bottlenecks? Does the structure of Forth code allow rewriting isolated routines? [1] http://rosettacode.org/wiki/100_doors#Forth [2] http://c2.com/cgi/wiki?ForthScientificLibrary
[toc] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-05 17:54 -1000 |
| Message-ID | <WvOdnUEBnP9pDEDTnZ2dnUVZ_sWdnZ2d@supernews.com> |
| In reply to | #7740 |
On 12/5/11 4:14 PM, Wendell wrote: > As is illustrated in the "100 doors" example at Rosetta Code [1], > Forth can be written in a highly readable style or restricted to low- > level operations for performance. The second style seems to be well > presented in the Forth Scientific Library. [2] > > The common advice to developers in most languages is to write first > for clarity and correctness, then optimize only if necessary. How well > does that approach work for Forth? If you write an application for > maximum readability, then discover that performance is insufficient, > what are your options? Are there profiling tools to find the hotspots > and bottlenecks? Does the structure of Forth code allow rewriting > isolated routines? > > [1] http://rosettacode.org/wiki/100_doors#Forth > [2] http://c2.com/cgi/wiki?ForthScientificLibrary In the first place, I'm not terribly impressed with the Forth code. The person who did this appears to have only a casual familiarity with Forth. Further, a quick test (SwiftForth on OSX 6.8 on Macbook Pro) shows that the Factored version is actually faster than the "slower" Unfactored one: 77 ms vs. 99 ms for 1000 iterations. I wish I had time to do a rewrite, and trust some of the other folks here will improve on this! I believe it's possible to improve both performance and readability. The lack of stack comments in both versions is particularly lamentable. The writeup complains about "keeping track of the Return Stack" in the Unfactored version, although the only thing there to "keep track of" is I which is self-explanatory, but the lack of stack comments in the Factored version makes it pretty opaque, too. As for your questions: I entirely agree with the observation that you should write first for clarity and correctness and then optimize as necessary. "Profiling" tools and strategies are a quality of implementation issue: some Forths have more than others, and programmers tend to have individual strategies. But I have been with numerous major projects in which performance was definitely an issue, and we have always found it extremely easy to gin up profiling strategies optimized for the particular application and getting the information we need. And the extreme modularity of Forth code makes it extremely easy to optimize bottlenecks when found. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-05 17:58 -1000 |
| Message-ID | <WvOdnUABnP9ID0DTnZ2dnUVZ_sWdnZ2d@supernews.com> |
| In reply to | #7741 |
On 12/5/11 5:54 PM, Elizabeth D. Rather wrote: ... > In the first place, I'm not terribly impressed with the Forth code. The > person who did this appears to have only a casual familiarity with > Forth. Further, a quick test (SwiftForth on OSX 6.8 on Macbook Pro) > shows that the Factored version is actually faster than the "slower" > Unfactored one: 77 ms vs. 99 ms for 1000 iterations. Oops, meant to say "the Factored version is actually faster than the 'faster' Unfactored one." Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <thebeez@xs4all.nl> |
|---|---|
| Date | 2011-12-06 08:49 +0100 |
| Message-ID | <4eddc8b6$0$6913$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #7742 |
Elizabeth D. Rather wrote:
May be a lame response, but I do agree with all commenters here. I don't
think this code is particularly readable.
I don't think that all Forth code can be written very readable all the time,
but at a certain moment in the program it should be. Not in the least
because the chances are that is the point where you'll have to do the
majority of the maintenance.
Having to do a significant amount of maintenance on my own code I know this
is of vital importance to adapt your code to real life requirements. Again,
Forth is NOT a "write-only" language, but it takes skill to make and keep
it readable.
And no, this is not a good example. My favorite example is an adventure game
I wrote many years ago. Although I'm putting myself in grave danger to get
flamed to hell, I'll share this snippit with you:
: do-saw \ saw tree
objects decode
if
object@ tree <> \ saw a tree?
tree? _done right? \ is tree cut?
generator missing? \ do we have a generator?
saw missing? \ do we have a saw?
or or or
if CANNOT exit then
where _Garden_ <> \ are we in the garden?
if OUTSIDE exit then
power? _todo right? \ do we have power?
if ." The saw won't work without electricity!!" cr cr exit then
helmet? _todo right? \ are we wearing a helmet?
if ." The tree falls on your unprotected head. Crunch." cr cr DEAD then
tree? done! \ now cut the tree
." The tree falls down on your safety helmet." cr
." An axe falls out of the top of the tree." cr cr
axe where put! \ and show the axe
else
IDUNNO
then
;
Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2011-12-06 07:26 +0200 |
| Message-ID | <96099697918436@frunobulax.edu> |
| In reply to | #7741 |
"Elizabeth D. Rather" <erather@forth.com> writes Re: Readable code and refactoring for optimization > On 12/5/11 5:54 PM, Elizabeth D. Rather wrote: ... >> In the first place, I'm not terribly impressed with the Forth code. The >> person who did this appears to have only a casual familiarity with >> Forth. Further, a quick test (SwiftForth on OSX 6.8 on Macbook Pro) >> shows that the Factored version is actually faster than the "slower" >> Unfactored one: 77 ms vs. 99 ms for 1000 iterations. > Oops, meant to say "the Factored version is actually faster than the > 'faster' Unfactored one." Which code are you talking about? The factored "Doors" code takes less than 2 ms on my machine (iForth64) and is obviously dominated by I/O. The referenced page has actually three versions: Factored, Unfactored and Optimized. I like the last one best, it's easier to add bells and whistles than to remove them. -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-05 22:02 -1000 |
| Message-ID | <QtSdnbvxNPKWUUDTnZ2dnUVZ_vKdnZ2d@supernews.com> |
| In reply to | #7743 |
On 12/5/11 7:26 PM, Marcel Hendrix wrote: > "Elizabeth D. Rather"<erather@forth.com> writes Re: Readable code and refactoring for optimization > >> On 12/5/11 5:54 PM, Elizabeth D. Rather wrote: > ... >>> In the first place, I'm not terribly impressed with the Forth code. The >>> person who did this appears to have only a casual familiarity with >>> Forth. Further, a quick test (SwiftForth on OSX 6.8 on Macbook Pro) >>> shows that the Factored version is actually faster than the "slower" >>> Unfactored one: 77 ms vs. 99 ms for 1000 iterations. > >> Oops, meant to say "the Factored version is actually faster than the >> 'faster' Unfactored one." > > Which code are you talking about? The factored "Doors" code takes less > than 2 ms on my machine (iForth64) and is obviously dominated by I/O. > > The referenced page has actually three versions: Factored, Unfactored > and Optimized. I like the last one best, it's easier to add bells and > whistles than to remove them. Sorry, I didn't run the Optimized version, just the Factored and Unfactored, because I suspected the assertion that Unfactored was faster was bogus, and it was. This particular exercise ends up not being useful for any of the nominal purposes, I'm afraid. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-07 00:49 +0100 |
| Message-ID | <jbm9ma$n34$1@online.de> |
| In reply to | #7743 |
Marcel Hendrix wrote: > The referenced page has actually three versions: Factored, Unfactored > and Optimized. I like the last one best, it's easier to add bells and > whistles than to remove them. The "optimized" is out of competition, because it uses a different algorithm to solve the problem. It is not as awful as with fibonacci, where the "optimized" version is O(n) instead of O(fib(n)). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-12-08 00:08 -0800 |
| Message-ID | <7x8vmnzds3.fsf@ruckus.brouhaha.com> |
| In reply to | #7741 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>> [1] http://rosettacode.org/wiki/100_doors#Forth
> In the first place, I'm not terribly impressed with the Forth
> code. The person who did this appears to have only a casual
> familiarity with Forth.
I'm no expert either, but here is my version (gforth 0.7):
100 constant ndoors \ number of doors
here constant doorvec ndoors cells allot \ allocate the array
: at ( n -- addr ) 1- cells doorvec + ;
: init ( -- ) ndoors 1 ?do i at off loop ;
: toggle ( n -- ) at dup @ invert swap ! ;
: pass ( n -- ) \ toggle every nth door in the vector.
dup ndoors swap ?do i toggle dup +loop drop ;
: run ( -- ) ndoors 1 ?do i pass loop ;
: display ( -- ) ndoors 1 ?do i at @ if i . endif loop cr ;
init run display bye
I think the way I allocated the array may be unsafe or wrong though.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-08 11:25 +0000 |
| Message-ID | <2011Dec8.122550@mips.complang.tuwien.ac.at> |
| In reply to | #7822 |
Paul Rubin <no.email@nospam.invalid> writes:
>I'm no expert either, but here is my version (gforth 0.7):
>
> 100 constant ndoors \ number of doors
> here constant doorvec ndoors cells allot \ allocate the array
...
>I think the way I allocated the array may be unsafe or wrong though.
It is. The proper way is:
here ndoors cells allot constant doorvec
or
create doorvec ndoors cells allot
I was surprised that it actually works in Gforth, because your program
overwrites the word DOORVEC completely (head, neck, and body). The
explanation is that the intelligent COMPILE, turns invocations of
DOORVEC into literals, so at runtime DOORVEC is no longer used, and it
is not destroyed before run-time.
- 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 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-12-08 23:51 -0800 |
| Message-ID | <7xsjku6v42.fsf@ruckus.brouhaha.com> |
| In reply to | #7827 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:> ... >>I think the way I allocated the array may be unsafe or wrong though. > It is. The proper way is: > here ndoors cells allot constant doorvec > or > create doorvec ndoors cells allot Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-12-08 14:47 +0000 |
| Message-ID | <jbqilt$4ld$1@dont-email.me> |
| In reply to | #7822 |
On 08/12/2011 08:08, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com> writes:
>>> [1] http://rosettacode.org/wiki/100_doors#Forth
>> In the first place, I'm not terribly impressed with the Forth
>> code. The person who did this appears to have only a casual
>> familiarity with Forth.
>
> I'm no expert either, but here is my version (gforth 0.7):
>
> 100 constant ndoors \ number of doors
> here constant doorvec ndoors cells allot \ allocate the array
>
> : at ( n -- addr ) 1- cells doorvec + ;
> : init ( -- ) ndoors 1 ?do i at off loop ;
> : toggle ( n -- ) at dup @ invert swap ! ;
> : pass ( n -- ) \ toggle every nth door in the vector.
> dup ndoors swap ?do i toggle dup +loop drop ;
> : run ( -- ) ndoors 1 ?do i pass loop ;
> : display ( -- ) ndoors 1 ?do i at @ if i . endif loop cr ;
>
> init run display bye
>
> I think the way I allocated the array may be unsafe or wrong though.
A lot better but there are still a number of improvements/problems
1. As you say the array allocation is unsafe
2. INIT can use the word ERASE
3. There is no need to use ?DO as we know that ndoors > 1
4. Your program only handles doors 1 to 99, you should do either
ndoors 1+ 1 do
or
ndoors 0 do
The last is better as it simplifies AT although it makes PASS a bit
worse.
5. If the rule that an odd number represents an open door and an even
one closed, TOGGLE can be simplified or eliminated.
6. More Forth-like is to define DOORVEC as an array and get rid of AT
7. Why not use the name DOORS instead of DOORVEC
Resulting in:
100 constant ndoors \ number of doors
: array ( n -- )
create cells allot
does> ( i -- ad ) swap cells + ;
100 array doors \ allocate the array
: init ( -- ) 0 doors ndoors cells erase ;
: pass ( n -- ) \ toggle every nth door in the array.
dup 1+ ndoors rot do 1 i doors +! dup +loop drop ;
: run ( -- ) ndoors 0 do i pass loop ;
: display ( -- ) ndoors 0 do i doors @ 1 and if i 1+ . then loop cr ;
init run display \ bye
Better or clearer - I don't know - opinions will differ.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2011-12-08 14:05 -0500 |
| Message-ID | <4ee10a71$0$283$14726298@news.sunsite.dk> |
| In reply to | #7830 |
On 12/8/11 9:47 AM, Gerry Jackson wrote:
> On 08/12/2011 08:08, Paul Rubin wrote:
>> "Elizabeth D. Rather"<erather@forth.com> writes:
>>>> [1] http://rosettacode.org/wiki/100_doors#Forth
>>> In the first place, I'm not terribly impressed with the Forth
>>> code. The person who did this appears to have only a casual
>>> familiarity with Forth.
>>
>> I'm no expert either, but here is my version (gforth 0.7):
>>
>> 100 constant ndoors \ number of doors
>> here constant doorvec ndoors cells allot \ allocate the array
>>
>> : at ( n -- addr ) 1- cells doorvec + ;
>> : init ( -- ) ndoors 1 ?do i at off loop ;
>> : toggle ( n -- ) at dup @ invert swap ! ;
>> : pass ( n -- ) \ toggle every nth door in the vector.
>> dup ndoors swap ?do i toggle dup +loop drop ;
>> : run ( -- ) ndoors 1 ?do i pass loop ;
>> : display ( -- ) ndoors 1 ?do i at @ if i . endif loop cr ;
>>
>> init run display bye
>>
>> I think the way I allocated the array may be unsafe or wrong though.
>
> A lot better but there are still a number of improvements/problems
>
> 1. As you say the array allocation is unsafe
> 2. INIT can use the word ERASE
> 3. There is no need to use ?DO as we know that ndoors > 1
> 4. Your program only handles doors 1 to 99, you should do either
> ndoors 1+ 1 do
> or
> ndoors 0 do
> The last is better as it simplifies AT although it makes PASS a bit worse.
> 5. If the rule that an odd number represents an open door and an even
> one closed, TOGGLE can be simplified or eliminated.
> 6. More Forth-like is to define DOORVEC as an array and get rid of AT
> 7. Why not use the name DOORS instead of DOORVEC
>
> Resulting in:
>
> 100 constant ndoors \ number of doors
> : array ( n -- )
> create cells allot
> does> ( i -- ad ) swap cells + ;
> 100 array doors \ allocate the array
>
> : init ( -- ) 0 doors ndoors cells erase ;
> : pass ( n -- ) \ toggle every nth door in the array.
> dup 1+ ndoors rot do 1 i doors +! dup +loop drop ;
> : run ( -- ) ndoors 0 do i pass loop ;
> : display ( -- ) ndoors 0 do i doors @ 1 and if i 1+ . then loop cr ;
>
> init run display \ bye
>
> Better or clearer - I don't know - opinions will differ.
I think it is both. Nice. One might hard code the 100 in just one spot.
Also, an array that checks for out of bounds indexes can save a lot of
heartache while writing code. Remove it when done. Maybe you did that.
This makes a good daily crossword puzzle. Here's a version that kicks
it up to a higher level for clarity, though it will surely horrify some.
But what the heck:
0 [if] A door is a physical object. So perhaps use objects. First make
a door object factory and test it with a single door to assure that it
will correctly open, shut, toggle, and can be queried for state. Once
that all works, only then proceed. [then]
:class door <super object
bool shut? \ set = shut \ clear = open
:m open: shut? clear: ;m
:m shut: shut? set: ;m
:m shut?: ( -- f ) shut? @: ;m
:m toggle:
self shut?: IF self open:
ELSE self shut:
THEN ;m
;class
0 [if] \ test on a single door
door d
d open: d shut?: . => 0
d toggle: d shut?: . => -1
d toggle: d shut?: . => 0
[then]
\ same
100 constant ndoors
\ an objArray() will check for valid indexes
ndoors objArray() door doors()
0 [if] openAll is a descriptive name and we are confident that open:
will work as it should on any number of doors. [then]
: openAll ndoors 0 DO i doors() open: LOOP ;
0 [if] displayShut is written and tested next before proceeding.
"shut?:" is used instead of "@ 1 and" [then]
: displayShut \ display as if a 1-based array
ndoors 0 DO i doors() shut?: IF i 1+ . THEN LOOP ;
0 [if] pass is very similar to your pass except we use a local to avoid
stack shuffling and "toggle:" instead of "1 ... +!" [then]
: pass { n -- } \ toggle every (n+1)th door in the array
\ but door(0) is toggled just once
ndoors n DO i doors() toggle: n 1+ +LOOP ;
\ identical run definition
: run ndoors 0 DO i pass LOOP ;
openAll run displayShut
-Doug
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-12-09 17:21 +0000 |
| Message-ID | <jbtg29$nbe$1@dont-email.me> |
| In reply to | #7840 |
On 08/12/2011 19:05, Doug Hoffman wrote:
> On 12/8/11 9:47 AM, Gerry Jackson wrote:
>> On 08/12/2011 08:08, Paul Rubin wrote:
>>> "Elizabeth D. Rather"<erather@forth.com> writes:
>>>>> [1] http://rosettacode.org/wiki/100_doors#Forth
>>>> In the first place, I'm not terribly impressed with the Forth
>>>> code. The person who did this appears to have only a casual
>>>> familiarity with Forth.
>>>
>>> I'm no expert either, but here is my version (gforth 0.7):
>>>
>>> 100 constant ndoors \ number of doors
>>> here constant doorvec ndoors cells allot \ allocate the array
>>>
>>> : at ( n -- addr ) 1- cells doorvec + ;
>>> : init ( -- ) ndoors 1 ?do i at off loop ;
>>> : toggle ( n -- ) at dup @ invert swap ! ;
>>> : pass ( n -- ) \ toggle every nth door in the vector.
>>> dup ndoors swap ?do i toggle dup +loop drop ;
>>> : run ( -- ) ndoors 1 ?do i pass loop ;
>>> : display ( -- ) ndoors 1 ?do i at @ if i . endif loop cr ;
>>>
>>> init run display bye
>>>
>>> I think the way I allocated the array may be unsafe or wrong though.
>>
>> A lot better but there are still a number of improvements/problems
>>
>> 1. As you say the array allocation is unsafe
>> 2. INIT can use the word ERASE
>> 3. There is no need to use ?DO as we know that ndoors > 1
>> 4. Your program only handles doors 1 to 99, you should do either
>> ndoors 1+ 1 do
>> or
>> ndoors 0 do
>> The last is better as it simplifies AT although it makes PASS a bit
>> worse.
>> 5. If the rule that an odd number represents an open door and an even
>> one closed, TOGGLE can be simplified or eliminated.
>> 6. More Forth-like is to define DOORVEC as an array and get rid of AT
>> 7. Why not use the name DOORS instead of DOORVEC
>>
>> Resulting in:
>>
>> 100 constant ndoors \ number of doors
>> : array ( n -- )
>> create cells allot
>> does> ( i -- ad ) swap cells + ;
>> 100 array doors \ allocate the array
>>
>> : init ( -- ) 0 doors ndoors cells erase ;
>> : pass ( n -- ) \ toggle every nth door in the array.
>> dup 1+ ndoors rot do 1 i doors +! dup +loop drop ;
>> : run ( -- ) ndoors 0 do i pass loop ;
>> : display ( -- ) ndoors 0 do i doors @ 1 and if i 1+ . then loop cr ;
>>
>> init run display \ bye
>>
>> Better or clearer - I don't know - opinions will differ.
>
> I think it is both. Nice. One might hard code the 100 in just one spot.
>
> Also, an array that checks for out of bounds indexes can save a lot of
> heartache while writing code. Remove it when done. Maybe you did that.
No I'm afraid not, it didn't seem necessary in this example (thinking
like that is asking for trouble of course).
>
> This makes a good daily crossword puzzle. Here's a version that kicks it
> up to a higher level for clarity, though it will surely horrify some.
> But what the heck:
>
> 0 [if] A door is a physical object. So perhaps use objects. First make a
> door object factory and test it with a single door to assure that it
> will correctly open, shut, toggle, and can be queried for state. Once
> that all works, only then proceed. [then]
>
> :class door <super object
> bool shut? \ set = shut \ clear = open
> :m open: shut? clear: ;m
> :m shut: shut? set: ;m
> :m shut?: ( -- f ) shut? @: ;m
> :m toggle:
> self shut?: IF self open:
> ELSE self shut:
> THEN ;m
> ;class
>
> 0 [if] \ test on a single door
> door d
> d open: d shut?: . => 0
> d toggle: d shut?: . => -1
> d toggle: d shut?: . => 0
> [then]
>
> \ same
> 100 constant ndoors
>
> \ an objArray() will check for valid indexes
> ndoors objArray() door doors()
>
> 0 [if] openAll is a descriptive name and we are confident that open:
> will work as it should on any number of doors. [then]
> : openAll ndoors 0 DO i doors() open: LOOP ;
>
> 0 [if] displayShut is written and tested next before proceeding.
> "shut?:" is used instead of "@ 1 and" [then]
> : displayShut \ display as if a 1-based array
> ndoors 0 DO i doors() shut?: IF i 1+ . THEN LOOP ;
>
> 0 [if] pass is very similar to your pass except we use a local to avoid
> stack shuffling and "toggle:" instead of "1 ... +!" [then]
> : pass { n -- } \ toggle every (n+1)th door in the array
> \ but door(0) is toggled just once
> ndoors n DO i doors() toggle: n 1+ +LOOP ;
>
> \ identical run definition
> : run ndoors 0 DO i pass LOOP ;
>
> openAll run displayShut
>
>
> -Doug
That looks good and ought to be clear even to non-forthers. Perhaps a
version should be submitted to the Rosetta code site as an alternative
Forth example demonstrating what can be achieved with a good OO package.
--
Gerry
.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2011-12-10 09:08 -0500 |
| Message-ID | <4ee367d4$0$293$14726298@news.sunsite.dk> |
| In reply to | #7886 |
On 12/9/11 12:21 PM, Gerry Jackson wrote: > That looks good and ought to be clear even to non-forthers. Perhaps a > version should be submitted to the Rosetta code site as an alternative > Forth example demonstrating what can be achieved with a good OO package. Well, it's huge overkill for this simple problem (though it gave correct results first time through). An object approach might make more sense if there were added complexity such as some doors are locked, open only the green doors, etc. Btw, the Forth example code leads one to believe that all doors start out open, but the top of the page says they start out closed. Makes no difference I guess if we just report those changed from initial state. -Doug
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-10 07:37 -1000 |
| Message-ID | <e5udnfWIW_xtBX7TnZ2dnUVZ_v6dnZ2d@supernews.com> |
| In reply to | #7886 |
On 12/9/11 7:21 AM, Gerry Jackson wrote:
> On 08/12/2011 19:05, Doug Hoffman wrote:
...
>> This makes a good daily crossword puzzle. Here's a version that kicks it
>> up to a higher level for clarity, though it will surely horrify some.
>> But what the heck:
>>
>> 0 [if] A door is a physical object. So perhaps use objects. First make a
>> door object factory and test it with a single door to assure that it
>> will correctly open, shut, toggle, and can be queried for state. Once
>> that all works, only then proceed. [then]
>>
>> :class door <super object
>> bool shut? \ set = shut \ clear = open
>> :m open: shut? clear: ;m
>> :m shut: shut? set: ;m
>> :m shut?: ( -- f ) shut? @: ;m
>> :m toggle:
>> self shut?: IF self open:
>> ELSE self shut:
>> THEN ;m
>> ;class
>>
>> 0 [if] \ test on a single door
>> door d
>> d open: d shut?: . => 0
>> d toggle: d shut?: . => -1
>> d toggle: d shut?: . => 0
>> [then]
>>
>> \ same
>> 100 constant ndoors
>>
>> \ an objArray() will check for valid indexes
>> ndoors objArray() door doors()
>>
>> 0 [if] openAll is a descriptive name and we are confident that open:
>> will work as it should on any number of doors. [then]
>> : openAll ndoors 0 DO i doors() open: LOOP ;
>>
>> 0 [if] displayShut is written and tested next before proceeding.
>> "shut?:" is used instead of "@ 1 and" [then]
>> : displayShut \ display as if a 1-based array
>> ndoors 0 DO i doors() shut?: IF i 1+ . THEN LOOP ;
>>
>> 0 [if] pass is very similar to your pass except we use a local to avoid
>> stack shuffling and "toggle:" instead of "1 ... +!" [then]
>> : pass { n -- } \ toggle every (n+1)th door in the array
>> \ but door(0) is toggled just once
>> ndoors n DO i doors() toggle: n 1+ +LOOP ;
>>
>> \ identical run definition
>> : run ndoors 0 DO i pass LOOP ;
>>
>> openAll run displayShut
>>
>>
>> -Doug
>
> That looks good and ought to be clear even to non-forthers. Perhaps a
> version should be submitted to the Rosetta code site as an alternative
> Forth example demonstrating what can be achieved with a good OO package.
It's a horrible example! It adds massive complexity for no purpose, and
I find it very hard to read. Is it faster, smaller, or in any other
technical way superior? Surely the "Forth way" is to solve problems the
simplest way possible.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-12-12 10:27 +0000 |
| Message-ID | <jc4kss$ht$1@dont-email.me> |
| In reply to | #7899 |
On 10/12/2011 17:37, Elizabeth D. Rather wrote:
> On 12/9/11 7:21 AM, Gerry Jackson wrote:
>> On 08/12/2011 19:05, Doug Hoffman wrote:
> ....
>>> This makes a good daily crossword puzzle. Here's a version that kicks it
>>> up to a higher level for clarity, though it will surely horrify some.
>>> But what the heck:
>>>
>>> 0 [if] A door is a physical object. So perhaps use objects. First make a
>>> door object factory and test it with a single door to assure that it
>>> will correctly open, shut, toggle, and can be queried for state. Once
>>> that all works, only then proceed. [then]
>>>
>>> :class door <super object
>>> bool shut? \ set = shut \ clear = open
>>> :m open: shut? clear: ;m
>>> :m shut: shut? set: ;m
>>> :m shut?: ( -- f ) shut? @: ;m
>>> :m toggle:
>>> self shut?: IF self open:
>>> ELSE self shut:
>>> THEN ;m
>>> ;class
>>>
>>> 0 [if] \ test on a single door
>>> door d
>>> d open: d shut?: . => 0
>>> d toggle: d shut?: . => -1
>>> d toggle: d shut?: . => 0
>>> [then]
>>>
>>> \ same
>>> 100 constant ndoors
>>>
>>> \ an objArray() will check for valid indexes
>>> ndoors objArray() door doors()
>>>
>>> 0 [if] openAll is a descriptive name and we are confident that open:
>>> will work as it should on any number of doors. [then]
>>> : openAll ndoors 0 DO i doors() open: LOOP ;
>>>
>>> 0 [if] displayShut is written and tested next before proceeding.
>>> "shut?:" is used instead of "@ 1 and" [then]
>>> : displayShut \ display as if a 1-based array
>>> ndoors 0 DO i doors() shut?: IF i 1+ . THEN LOOP ;
>>>
>>> 0 [if] pass is very similar to your pass except we use a local to avoid
>>> stack shuffling and "toggle:" instead of "1 ... +!" [then]
>>> : pass { n -- } \ toggle every (n+1)th door in the array
>>> \ but door(0) is toggled just once
>>> ndoors n DO i doors() toggle: n 1+ +LOOP ;
>>>
>>> \ identical run definition
>>> : run ndoors 0 DO i pass LOOP ;
>>>
>>> openAll run displayShut
>>>
>>>
>>> -Doug
>>
>> That looks good and ought to be clear even to non-forthers. Perhaps a
>> version should be submitted to the Rosetta code site as an alternative
>> Forth example demonstrating what can be achieved with a good OO package.
>
> It's a horrible example! It adds massive complexity for no purpose, and
> I find it very hard to read. Is it faster, smaller, or in any other
> technical way superior? Surely the "Forth way" is to solve problems the
> simplest way possible.
>
What you say is true from the perspective of embedded systems where
every byte and processing cycle is important. However it ignores the
fact that to most programmers Forth, even if they have heard of it, is a
write-only language - it is so different to other languages that, if
unfamiliar to someone, requires far more effort to understand than an
unfamiliar conventional language. I think that such a person would stand
more chance of understanding Doug's code than yours as given in another
post - despite the fact that your version is good and clear to an
experienced Forth programmer. Who knows, someone who understood it might
then go on to try using Forth.
It seems to be a sad fact that embedded system programmers don't seem to
realise that getting the smallest, fastest program isn't that important
to those who use run Forth on desktop systems. Of course some
applications need the ultimate in speed and size but mostly those
considerations are irrelevant.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-12 05:02 -0600 |
| Message-ID | <7pmdnYrXSP7KQnjTnZ2dnUVZ_vOdnZ2d@supernews.com> |
| In reply to | #7966 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> On 10/12/2011 17:37, Elizabeth D. Rather wrote:
>> On 12/9/11 7:21 AM, Gerry Jackson wrote:
>>> On 08/12/2011 19:05, Doug Hoffman wrote:
>> ....
>>>> This makes a good daily crossword puzzle. Here's a version that kicks it
>>>> up to a higher level for clarity, though it will surely horrify some.
>>>> But what the heck:
>>>>
>>>> 0 [if] A door is a physical object. So perhaps use objects. First make a
>>>> door object factory and test it with a single door to assure that it
>>>> will correctly open, shut, toggle, and can be queried for state. Once
>>>> that all works, only then proceed. [then]
>>>>
>>>> :class door <super object
>>>> bool shut? \ set = shut \ clear = open
>>>> :m open: shut? clear: ;m
>>>> :m shut: shut? set: ;m
>>>> :m shut?: ( -- f ) shut? @: ;m
>>>> :m toggle:
>>>> self shut?: IF self open:
>>>> ELSE self shut:
>>>> THEN ;m
>>>> ;class
>>>>
>>>> 0 [if] \ test on a single door
>>>> door d
>>>> d open: d shut?: . => 0
>>>> d toggle: d shut?: . => -1
>>>> d toggle: d shut?: . => 0
>>>> [then]
>>>>
>>>> \ same
>>>> 100 constant ndoors
>>>>
>>>> \ an objArray() will check for valid indexes
>>>> ndoors objArray() door doors()
>>>>
>>>> 0 [if] openAll is a descriptive name and we are confident that open:
>>>> will work as it should on any number of doors. [then]
>>>> : openAll ndoors 0 DO i doors() open: LOOP ;
>>>>
>>>> 0 [if] displayShut is written and tested next before proceeding.
>>>> "shut?:" is used instead of "@ 1 and" [then]
>>>> : displayShut \ display as if a 1-based array
>>>> ndoors 0 DO i doors() shut?: IF i 1+ . THEN LOOP ;
>>>>
>>>> 0 [if] pass is very similar to your pass except we use a local to avoid
>>>> stack shuffling and "toggle:" instead of "1 ... +!" [then]
>>>> : pass { n -- } \ toggle every (n+1)th door in the array
>>>> \ but door(0) is toggled just once
>>>> ndoors n DO i doors() toggle: n 1+ +LOOP ;
>>>>
>>>> \ identical run definition
>>>> : run ndoors 0 DO i pass LOOP ;
>>>>
>>>> openAll run displayShut
>>>
>>> That looks good and ought to be clear even to non-forthers. Perhaps a
>>> version should be submitted to the Rosetta code site as an alternative
>>> Forth example demonstrating what can be achieved with a good OO package.
>>
>> It's a horrible example! It adds massive complexity for no purpose, and
>> I find it very hard to read. Is it faster, smaller, or in any other
>> technical way superior? Surely the "Forth way" is to solve problems the
>> simplest way possible.
>
> What you say is true from the perspective of embedded systems where
> every byte and processing cycle is important. However it ignores the
> fact that to most programmers Forth, even if they have heard of it,
> is a write-only language - it is so different to other languages
> that, if unfamiliar to someone, requires far more effort to
> understand than an unfamiliar conventional language. I think that
> such a person would stand more chance of understanding Doug's code
> than yours as given in another post - despite the fact that your
> version is good and clear to an experienced Forth programmer. Who
> knows, someone who understood it might then go on to try using
> Forth.
I think you're being very unfair. This has nothing to do with
embedded programming. Elizabeth's code is simple and clean. Forth is
all about simple and clean. There's no point writing non-idiomatic
code in Rosetta.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-12-12 11:18 +0000 |
| Message-ID | <jc4nsa$fcj$1@dont-email.me> |
| In reply to | #7969 |
On 12/12/2011 11:02, Andrew Haley wrote:
> Gerry Jackson<gerry@jackson9000.fsnet.co.uk> wrote:
>> On 10/12/2011 17:37, Elizabeth D. Rather wrote:
>>> On 12/9/11 7:21 AM, Gerry Jackson wrote:
>>>> On 08/12/2011 19:05, Doug Hoffman wrote:
>>> ....
>>>>> This makes a good daily crossword puzzle. Here's a version that kicks it
>>>>> up to a higher level for clarity, though it will surely horrify some.
>>>>> But what the heck:
>>>>>
>>>>> 0 [if] A door is a physical object. So perhaps use objects. First make a
>>>>> door object factory and test it with a single door to assure that it
>>>>> will correctly open, shut, toggle, and can be queried for state. Once
>>>>> that all works, only then proceed. [then]
>>>>>
>>>>> :class door<super object
>>>>> bool shut? \ set = shut \ clear = open
>>>>> :m open: shut? clear: ;m
>>>>> :m shut: shut? set: ;m
>>>>> :m shut?: ( -- f ) shut? @: ;m
>>>>> :m toggle:
>>>>> self shut?: IF self open:
>>>>> ELSE self shut:
>>>>> THEN ;m
>>>>> ;class
>>>>>
>>>>> 0 [if] \ test on a single door
>>>>> door d
>>>>> d open: d shut?: . => 0
>>>>> d toggle: d shut?: . => -1
>>>>> d toggle: d shut?: . => 0
>>>>> [then]
>>>>>
>>>>> \ same
>>>>> 100 constant ndoors
>>>>>
>>>>> \ an objArray() will check for valid indexes
>>>>> ndoors objArray() door doors()
>>>>>
>>>>> 0 [if] openAll is a descriptive name and we are confident that open:
>>>>> will work as it should on any number of doors. [then]
>>>>> : openAll ndoors 0 DO i doors() open: LOOP ;
>>>>>
>>>>> 0 [if] displayShut is written and tested next before proceeding.
>>>>> "shut?:" is used instead of "@ 1 and" [then]
>>>>> : displayShut \ display as if a 1-based array
>>>>> ndoors 0 DO i doors() shut?: IF i 1+ . THEN LOOP ;
>>>>>
>>>>> 0 [if] pass is very similar to your pass except we use a local to avoid
>>>>> stack shuffling and "toggle:" instead of "1 ... +!" [then]
>>>>> : pass { n -- } \ toggle every (n+1)th door in the array
>>>>> \ but door(0) is toggled just once
>>>>> ndoors n DO i doors() toggle: n 1+ +LOOP ;
>>>>>
>>>>> \ identical run definition
>>>>> : run ndoors 0 DO i pass LOOP ;
>>>>>
>>>>> openAll run displayShut
>>>>
>>>> That looks good and ought to be clear even to non-forthers. Perhaps a
>>>> version should be submitted to the Rosetta code site as an alternative
>>>> Forth example demonstrating what can be achieved with a good OO package.
>>>
>>> It's a horrible example! It adds massive complexity for no purpose, and
>>> I find it very hard to read. Is it faster, smaller, or in any other
>>> technical way superior? Surely the "Forth way" is to solve problems the
>>> simplest way possible.
>>
>> What you say is true from the perspective of embedded systems where
>> every byte and processing cycle is important. However it ignores the
>> fact that to most programmers Forth, even if they have heard of it,
>> is a write-only language - it is so different to other languages
>> that, if unfamiliar to someone, requires far more effort to
>> understand than an unfamiliar conventional language. I think that
>> such a person would stand more chance of understanding Doug's code
>> than yours as given in another post - despite the fact that your
>> version is good and clear to an experienced Forth programmer. Who
>> knows, someone who understood it might then go on to try using
>> Forth.
>
> I think you're being very unfair. This has nothing to do with
> embedded programming. Elizabeth's code is simple and clean.
I don't think you read my post. I didn't Elizabeth's code wasn't simple
and clean. I wrote "despite the fact that your version is good and clear
to an experienced Forth programmer". The key bit being to someone
experienced with Forth. Please read a post before writing a knee-jerk
reaction.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-12 05:25 -0600 |
| Message-ID | <wYWdnX9Z0MAyeXjTnZ2dnUVZ_vSdnZ2d@supernews.com> |
| In reply to | #7971 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> On 12/12/2011 11:02, Andrew Haley wrote:
>> Gerry Jackson<gerry@jackson9000.fsnet.co.uk> wrote:
>>> On 10/12/2011 17:37, Elizabeth D. Rather wrote:
>>>> On 12/9/11 7:21 AM, Gerry Jackson wrote:
>>>>> On 08/12/2011 19:05, Doug Hoffman wrote:
>>>> ....
>>>>>> This makes a good daily crossword puzzle. Here's a version that kicks it
>>>>>> up to a higher level for clarity, though it will surely horrify some.
>>>>>> But what the heck:
>>>>>>
>>>>>> 0 [if] A door is a physical object. So perhaps use objects. First make a
>>>>>> door object factory and test it with a single door to assure that it
>>>>>> will correctly open, shut, toggle, and can be queried for state. Once
>>>>>> that all works, only then proceed. [then]
>>>>>>
>>>>>> :class door<super object
>>>>>> bool shut? \ set = shut \ clear = open
>>>>>> :m open: shut? clear: ;m
>>>>>> :m shut: shut? set: ;m
>>>>>> :m shut?: ( -- f ) shut? @: ;m
>>>>>> :m toggle:
>>>>>> self shut?: IF self open:
>>>>>> ELSE self shut:
>>>>>> THEN ;m
>>>>>> ;class
>>>>>>
>>>>>> 0 [if] \ test on a single door
>>>>>> door d
>>>>>> d open: d shut?: . => 0
>>>>>> d toggle: d shut?: . => -1
>>>>>> d toggle: d shut?: . => 0
>>>>>> [then]
>>>>>>
>>>>>> \ same
>>>>>> 100 constant ndoors
>>>>>>
>>>>>> \ an objArray() will check for valid indexes
>>>>>> ndoors objArray() door doors()
>>>>>>
>>>>>> 0 [if] openAll is a descriptive name and we are confident that open:
>>>>>> will work as it should on any number of doors. [then]
>>>>>> : openAll ndoors 0 DO i doors() open: LOOP ;
>>>>>>
>>>>>> 0 [if] displayShut is written and tested next before proceeding.
>>>>>> "shut?:" is used instead of "@ 1 and" [then]
>>>>>> : displayShut \ display as if a 1-based array
>>>>>> ndoors 0 DO i doors() shut?: IF i 1+ . THEN LOOP ;
>>>>>>
>>>>>> 0 [if] pass is very similar to your pass except we use a local to avoid
>>>>>> stack shuffling and "toggle:" instead of "1 ... +!" [then]
>>>>>> : pass { n -- } \ toggle every (n+1)th door in the array
>>>>>> \ but door(0) is toggled just once
>>>>>> ndoors n DO i doors() toggle: n 1+ +LOOP ;
>>>>>>
>>>>>> \ identical run definition
>>>>>> : run ndoors 0 DO i pass LOOP ;
>>>>>>
>>>>>> openAll run displayShut
>>>>>
>>>>> That looks good and ought to be clear even to non-forthers. Perhaps a
>>>>> version should be submitted to the Rosetta code site as an alternative
>>>>> Forth example demonstrating what can be achieved with a good OO package.
>>>>
>>>> It's a horrible example! It adds massive complexity for no purpose, and
>>>> I find it very hard to read. Is it faster, smaller, or in any other
>>>> technical way superior? Surely the "Forth way" is to solve problems the
>>>> simplest way possible.
>>>
>>> What you say is true from the perspective of embedded systems where
>>> every byte and processing cycle is important. However it ignores the
>>> fact that to most programmers Forth, even if they have heard of it,
>>> is a write-only language - it is so different to other languages
>>> that, if unfamiliar to someone, requires far more effort to
>>> understand than an unfamiliar conventional language. I think that
>>> such a person would stand more chance of understanding Doug's code
>>> than yours as given in another post - despite the fact that your
>>> version is good and clear to an experienced Forth programmer. Who
>>> knows, someone who understood it might then go on to try using
>>> Forth.
>>
>> I think you're being very unfair. This has nothing to do with
>> embedded programming. Elizabeth's code is simple and clean.
>
> I don't think you read my post. I didn't Elizabeth's code wasn't
> simple and clean. I wrote "despite the fact that your version is
> good and clear to an experienced Forth programmer". The key bit
> being to someone experienced with Forth.
Yes, and I'm disagreeing with that. I think you are wrong.
> Please read a post before writing a knee-jerk reaction.
I did.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-12-12 12:41 +0000 |
| Message-ID | <jc4sok$9nl$1@dont-email.me> |
| In reply to | #7972 |
On 12/12/2011 11:25, Andrew Haley wrote: > Gerry Jackson<gerry@jackson9000.fsnet.co.uk> wrote: >> On 12/12/2011 11:02, Andrew Haley wrote: >>> Gerry Jackson<gerry@jackson9000.fsnet.co.uk> wrote: >>>> On 10/12/2011 17:37, Elizabeth D. Rather wrote: [...] >>>>>> That looks good and ought to be clear even to non-forthers. Perhaps a >>>>>> version should be submitted to the Rosetta code site as an alternative >>>>>> Forth example demonstrating what can be achieved with a good OO package. >>>>> >>>>> It's a horrible example! It adds massive complexity for no purpose, and >>>>> I find it very hard to read. Is it faster, smaller, or in any other >>>>> technical way superior? Surely the "Forth way" is to solve problems the >>>>> simplest way possible. >>>> >>>> What you say is true from the perspective of embedded systems where >>>> every byte and processing cycle is important. However it ignores the >>>> fact that to most programmers Forth, even if they have heard of it, >>>> is a write-only language - it is so different to other languages >>>> that, if unfamiliar to someone, requires far more effort to >>>> understand than an unfamiliar conventional language. I think that >>>> such a person would stand more chance of understanding Doug's code >>>> than yours as given in another post - despite the fact that your >>>> version is good and clear to an experienced Forth programmer. Who >>>> knows, someone who understood it might then go on to try using >>>> Forth. >>> >>> I think you're being very unfair. This has nothing to do with >>> embedded programming. Elizabeth's code is simple and clean. >> >> I don't think you read my post. I didn't Elizabeth's code wasn't >> simple and clean. I wrote "despite the fact that your version is >> good and clear to an experienced Forth programmer". The key bit >> being to someone experienced with Forth. > > Yes, and I'm disagreeing with that. I think you are wrong. That's OK, but I'd prefer you said so directly instead of misrepresenting what was written. > >> Please read a post before writing a knee-jerk reaction. > > I did. It wasn't obvious to me. -- Gerry
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web