Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #7740 > unrolled thread

Readable code and refactoring for optimization

Back to article view | Back to comp.lang.forth

Contents

  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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#7878

Elizabeth D. Rather wrote:
> How's this:

You missed 1+ before allot and erase.  If I was doing 1-based array
indices, I think I would add the 1 into ndoors so I wouldn't have to
worry about errors like that.

And you could avoid indexing inside the loop if that helps the speed.

>: toggle ( caddr -- ) \ Toggle the byte at caddr
>     dup c@ 1 xor swap c! ;  \ Many systems already have this.
>
100  1+ constant ndoors
> create doors ndoors allot
>
>: init ( -- )   doors ndoors erase ;

: pass ( n -- )  \ toggle every nth door in the array.
	dup doors ndoors bounds rot + do
		i toggle
	dup ( n ) +loop drop ;

: run ( -- )   ndoors 1 do  i pass  loop ;
: display ( -- )   ndoors 1 do  doors i + c@ if  i . then  loop cr ;

--Josh

[toc] | [prev] | [next] | [standalone]

#8290

On Dec 10, 3:39 am, Josh Grams <j...@qualdan.com> wrote:
> Elizabeth D. Rather wrote:
> > How's this:
>
> You missed 1+ before allot and erase.  If I was doing 1-based array
> indices, I think I would add the 1 into ndoors so I wouldn't have to
> worry about errors like that.
>
> And you could avoid indexing inside the loop if that helps the speed.
>
> >: toggle ( caddr -- ) \ Toggle the byte at caddr
> >     dup c@ 1 xor swap c! ;  \ Many systems already have this.
>
> 100  1+ constant ndoors
>
> > create doors ndoors allot
>
> >: init ( -- )   doors ndoors erase ;
>
> : pass ( n -- )  \ toggle every nth door in the array.
>         dup doors ndoors bounds rot + do
>                 i toggle
>         dup ( n ) +loop drop ;
>
> : run ( -- )   ndoors 1 do  i pass  loop ;
> : display ( -- )   ndoors 1 do  doors i + c@ if  i . then  loop cr ;
>
> --Josh

Thanks for updating Rosetta Code with the improved example! This was a
very productive discussion.

If you like, there are hundreds of other examples to review. Just
click on the "Forth" category to see them all.

There are also hundreds of Rosetta Code problems which have no Forth
solution. There is a link from the infobox on the Category:Forth page
to list them. It is a public wiki; all are encouraged to contribute!

* regex (Gray parser, perhaps?)
* matrix operations (FSL demos?)
* md5
* Levenshtein distance
* many parsing problems
* many object-oriented examples
* etc.

Ian Osgood
(original unfactored dunderhead)

[toc] | [prev] | [next] | [standalone]

#7887

On 12/9/11 10:46 PM, Elizabeth D. Rather wrote:

> How's this:

Are we suffering the old "off by one" array index problem?

-Doug

0 value here'
: toggle ( caddr -- ) \ Toggle the byte at caddr
    dup c@ 1 xor swap c! ;  \ Many systems already have this.

100 constant ndoors
create doors ndoors allot
here to here' 1 c,

: init ( -- )   doors ndoors erase ;

: pass ( n -- )   \ toggle every nth door in the array.
    dup ndoors 1+ rot do
       doors i + toggle dup
    ( n ) +loop drop ;

: run ( -- )   ndoors 1+ 1 do  i pass  loop ;
: display ( -- )   ndoors 1+ 1 do  doors i + c@ if  i . then  loop cr ;

init run display
\ => 1 4 9 16 25 36 49 64 81

0 here' c!
init run display
\ => 1 4 9 16 25 36 49 64 81 100

[toc] | [prev] | [next] | [standalone]

#7994

"Elizabeth D. Rather" <erather@forth.com> writes:
> How's this:
>
> : toggle ( caddr -- ) \ Toggle the byte at caddr
>    dup c@ 1 xor swap c! ;  \ Many systems already have this.
>
> 100 constant ndoors
> create doors ndoors allot
>
> : init ( -- )   doors ndoors erase ;
>
> : pass ( n -- )   \ toggle every nth door in the array.
>    dup ndoors 1+ rot do
>       doors i + toggle dup
>    ( n ) +loop drop ;
>
> : run ( -- )   ndoors 1+ 1 do  i pass  loop ;
> : display ( -- )   ndoors 1+ 1 do  doors i + c@ if  i . then  loop cr ;

1. The repeated 1+ seems a bit ugly to me.
2. I'm not sure but I think it reads and writes 1 past the end of the
   array?

Here's yet another version.  It allocates an unused byte at the start of
the vector, but cleaning that up seems like more clutter than it's
worth:

    : toggle ( caddr -- ) \ Toggle the byte at caddr
        dup c@ 1 xor swap c! ;  \ Many systems already have this.

    101 constant limit   \ 1 + number of doors
    create doors limit chars allot

    : init ( -- )   doors limit erase ;

    : pass ( n -- )   \ toggle every nth door in the array.
        limit over do
           doors i + toggle dup
        ( n ) +loop drop ;

    : run ( -- )   limit 1 do  i pass  loop ;
    : display ( -- )   limit 1 do  doors i + c@ if  i . then  loop cr ; 

    init run display bye

[toc] | [prev] | [next] | [standalone]

#8000

On 12/12/11 7:11 AM, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> How's this:
>>
>> : toggle ( caddr -- ) \ Toggle the byte at caddr
>>     dup c@ 1 xor swap c! ;  \ Many systems already have this.
>>
>> 100 constant ndoors
>> create doors ndoors allot
>>
>> : init ( -- )   doors ndoors erase ;
>>
>> : pass ( n -- )   \ toggle every nth door in the array.
>>     dup ndoors 1+ rot do
>>        doors i + toggle dup
>>     ( n ) +loop drop ;
>>
>> : run ( -- )   ndoors 1+ 1 do  i pass  loop ;
>> : display ( -- )   ndoors 1+ 1 do  doors i + c@ if  i . then  loop cr ;
>
> 1. The repeated 1+ seems a bit ugly to me.

I agree, but it's integral to the problem as stated in Rosetta and 
necessary to get results that match the other examples.  It is far more 
natural for us programmers to start at 0 than at 1.

> 2. I'm not sure but I think it reads and writes 1 past the end of the
>     array?

A loop that starts 100 0 DO ... will have values of I from 0 through 99. 
This problem needs values 1 through 100. Forth DO loops are exclusive at 
the upper end because the test is at the end of the loop.

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]

#8006

On 12/12/11 12:48 PM, Elizabeth D. Rather wrote:
> On 12/12/11 7:11 AM, Paul Rubin wrote:
>> "Elizabeth D. Rather"<erather@forth.com> writes:
>>> How's this:
>>>
>>> : toggle ( caddr -- ) \ Toggle the byte at caddr
>>> dup c@ 1 xor swap c! ; \ Many systems already have this.
>>>
>>> 100 constant ndoors
>>> create doors ndoors allot
>>>
>>> : init ( -- ) doors ndoors erase ;
>>>
>>> : pass ( n -- ) \ toggle every nth door in the array.
>>> dup ndoors 1+ rot do
>>> doors i + toggle dup
>>> ( n ) +loop drop ;
>>>
>>> : run ( -- ) ndoors 1+ 1 do i pass loop ;
>>> : display ( -- ) ndoors 1+ 1 do doors i + c@ if i . then loop cr ;
>>
>> 1. The repeated 1+ seems a bit ugly to me.
>
> I agree, but it's integral to the problem as stated in Rosetta and
> necessary to get results that match the other examples. It is far more
> natural for us programmers to start at 0 than at 1.


I agree with Elizabeth.

So here is another way (of many) to approach it:

100 constant ndoors   \ number of doors
: toggle ( caddr -- ) \ Toggle the byte at caddr
   dup c@ 1 xor swap c! ;
create doors ndoors chars allot
: init doors ndoors erase ;
: pass { n -- }   \ toggle every nth door in the array.
     ndoors n do doors i + toggle  n 1+ +loop ;
: run ndoors 0 do i pass loop ;
: display \ display as if a 1-based array
   ndoors 0 do  doors i + c@ if  i 1+ . then  loop ;

init run display
1 4 9 16 25 36 49 64 81 100 ok

The local in pass assists readability and correctness IMO.  One could 
then do refinement to get rid of the local if deemed necessary:

\ use an over, a dup, and a drop instead of the local
: pass ( n -- )   \ toggle every nth door in the array.
     ndoors over do doors i + toggle dup ( n ) 1+ +loop drop ;

Or even then pull the "1+" out of the loop (left for the reader).

This addresses the OP's question about first writing for correctness and 
readability.  Then optimize only if needed.

The interesting thing is regardless of one's opinion on objects and 
locals, the example I first showed was the only one that worked.

-Doug

[toc] | [prev] | [next] | [standalone]

#8010

Doug Hoffman <glidedog@gmail.com> writes:
> : pass { n -- }   \ toggle every nth door in the array.
>     ndoors n do doors i + toggle  n 1+ +loop ;
> : run ndoors 0 do i pass loop ;
> : display \ display as if a 1-based array
>   ndoors 0 do  doors i + c@ if  i 1+ . then  loop ;

This subscript faking seems ugly too.  E.g. the "toggle every nth door"
comment is wrong since "pass" now actually toggles every (n+1)th door.

> The local in pass assists readability and correctness IMO.  One could
> then do refinement to get rid of the local if deemed necessary:

I agree that the local helps readability but I defer to you and the
other Forthers whether its use is idiomatic Forth.  I thought though
that the { n -- } locals syntax was gforth specific and that ANS syntax
was different and uglier.

[toc] | [prev] | [next] | [standalone]

#8013

On 12/12/11 2:46 PM, Paul Rubin wrote:
> Doug Hoffman<glidedog@gmail.com>  writes:
>> : pass { n -- }   \ toggle every nth door in the array.
>>      ndoors n do doors i + toggle  n 1+ +loop ;
>> : run ndoors 0 do i pass loop ;
>> : display \ display as if a 1-based array
>>    ndoors 0 do  doors i + c@ if  i 1+ . then  loop ;
>
> This subscript faking seems ugly too.  E.g. the "toggle every nth door"
> comment is wrong since "pass" now actually toggles every (n+1)th door.

I shouldn't have blindly copied that comment from the website.  The 
comment is wrong as you say.  Doesn't change the program though. 
0-based arrays are very common and the indexing scheme then usually 
works out better.  This little program is a classic case.

>> The local in pass assists readability and correctness IMO.  One could
>> then do refinement to get rid of the local if deemed necessary:
>
> I agree that the local helps readability but I defer to you and the
> other Forthers whether its use is idiomatic Forth.  I thought though
> that the { n -- } locals syntax was gforth specific and that ANS syntax
> was different and uglier.

Actually other Forths including Neon, MacForth, and Mops have also been 
using the { n -- } syntax for decades.  I agree with the ANS comment.

-Doug

[toc] | [prev] | [next] | [standalone]

#8015

On Dec 12, 2:46 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> I agree that the local helps readability but I defer to you and the
> other Forthers whether its use is idiomatic Forth.  I thought though
> that the { n -- } locals syntax was gforth specific and that ANS syntax
> was different and uglier.

IMO { is Comus: eg, from the Forth94 Appendix:

: {  ( "name ... }" - )
    BEGIN  BL WORD COUNT
      OVER C@ [CHAR] }
      - OVER 1 -  OR
    WHILE
      (LOCAL)
    REPEAT 2DROP 0 0 (LOCAL)
;  IMMEDIATE

[toc] | [prev] | [next] | [standalone]

#8023

BruceMcF <agila61@netscape.net> writes:
>On Dec 12, 2:46=A0pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>> I thought though
>> that the { n -- } locals syntax was gforth specific and that ANS syntax
>> was different and uglier.
>
>IMO { is Comus: eg, from the Forth94 Appendix:
>
>: {  ( "name ... }" - )
>    BEGIN  BL WORD COUNT
>      OVER C@ [CHAR] }
>      - OVER 1 -  OR
>    WHILE
>      (LOCAL)
>    REPEAT 2DROP 0 0 (LOCAL)
>;  IMMEDIATE

That implementation is broken:

: bla { a b } a b .s ;  ok
1 2 bla <2> 2 1  ok

The proper behaviour is:

: bla { a b } a b .s ;  ok
1 2 bla <2> 1 2  ok

A correct implementation in Forth-94 is available at

<http://www.complang.tuwien.ac.at/forth/anslocal.fs>

(also in <http://www.complang.tuwien.ac.at/forth/compat.zip>).

As mentioned, many systems support this syntax.

- 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]

#8009

"Elizabeth D. Rather" <erather@forth.com> writes:
>> 1. The repeated 1+ seems a bit ugly to me.
>
> I agree, but it's integral to the problem as stated 

I think it can be factored though; that's what I tried to do with
"limit".  

>> 2. I'm not sure but I think it reads and writes 1 past the end of the
>>     array?
>
> A loop that starts 100 0 DO ... will have values of I from 0 through
> 99. This problem needs values 1 through 100. Forth DO loops are
> exclusive at the upper end because the test is at the end of the loop.

Right, but unless I'm confused,

     100 constant ndoors
     create doors ndoors allot 

allocates storage at locations doors+0, doors+1, ..., doors+99.
The loops with +1 then read and write locations doors+1 ... doors+100
where doors+100 is outside the allocated area.

Is there a portable way to make a version of "do" that loops including
the upper bound, rather than just up to it?  Something like

   100 1 do+1 ... loop

that would run from 1 to 100 inclusive.

[toc] | [prev] | [next] | [standalone]

#8014

On Dec 12, 7:42 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erat...@forth.com> writes:
>
> >> 1. The repeated 1+ seems a bit ugly to me.
>
> > I agree, but it's integral to the problem as stated
>
> I think it can be factored though; that's what I tried to do with
> "limit".
>
> >> 2. I'm not sure but I think it reads and writes 1 past the end of the
> >>     array?
>
> > A loop that starts 100 0 DO ... will have values of I from 0 through
> > 99. This problem needs values 1 through 100. Forth DO loops are
> > exclusive at the upper end because the test is at the end of the loop.
>
> Right, but unless I'm confused,
>
>      100 constant ndoors
>      create doors ndoors allot
>
> allocates storage at locations doors+0, doors+1, ..., doors+99.
> The loops with +1 then read and write locations doors+1 ... doors+100
> where doors+100 is outside the allocated area.
>
> Is there a portable way to make a version of "do" that loops including
> the upper bound, rather than just up to it?  Something like
>
>    100 1 do+1 ... loop
>
> that would run from 1 to 100 inclusive.

: do swap 1+ swap [compile] do ; immediate

[toc] | [prev] | [next] | [standalone]

#8016

On 12/12/11 11:35 AM, Mark Wills wrote:
> On Dec 12, 7:42 pm, Paul Rubin<no.em...@nospam.invalid>  wrote:
...
>> Is there a portable way to make a version of "do" that loops including
>> the upper bound, rather than just up to it?  Something like
>>
>>     100 1 do+1 ... loop
>>
>> that would run from 1 to 100 inclusive.
>
> : do swap 1+ swap [compile] do ; immediate

FWIW, the reason DO is like that is so you can do things like this:

	: stars ( n -- )   0 do  star loop ;

	10 stars \ ...and get 10 of 'em

If there were a built-in 1+, you'd have to remember to say

	9 stars

to get 10, which is very tacky.

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]

#8019

"Elizabeth D. Rather" <erather@forth.com> writes:
>> : do swap 1+ swap [compile] do ; immediate

Hmm, I tried

    : do+1 swap 1+ swap [compile] do ; immediate
    : yy 5 1 do+1 i . loop ;

    yy

and got

    yy 1 2 3 4  ok

I'll see if I can figure it out.
 

> FWIW, the reason DO is like that is so you can do things like this:
>
> 	: stars ( n -- )   0 do  star loop ;
> If there were a built-in 1+, you'd have to remember to say
> 	9 stars
> to get 10, which is very tacky.

Of course you'd use 1 do instead of 0 do.  I'm not suggesting
redefining do though, just wondering how to make a variant form.

[toc] | [prev] | [next] | [standalone]

#8026

On Tuesday, 13 December 2011 07:50:49 UTC, Paul Rubin  wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
> >> : do swap 1+ swap [compile] do ; immediate
> 
> Hmm, I tried
> 
>     : do+1 swap 1+ swap [compile] do ; immediate
>     : yy 5 1 do+1 i . loop ;
> 
>     yy
> 
> and got
> 
>     yy 1 2 3 4  ok
> 
> I'll see if I can figure it out.
>  
> 
The "swap 1+ swap" needs to be postponed so that it happens at run time, not at compile time.

 : DO+1 POSTPONE SWAP POSTPONE 1+ POSTPONE SWAP POSTPONE DO ; IMMEDIATE

During the definition of YY 5 and 1 are compiled as literals, so are no longer on the stack when "swap 1+ swap" executes, using whatever was underneath. The fact that the definition compiled at all tells me that:

   The stack either wasn't empty, or your Forth doesn't check for stack underflow
   Your version of : doesn't put anything on the stack for compiler security.

Now you have tow unintentionally altered items on the stack, and the code that YY has actually compiled performs "5 1 DO"

[toc] | [prev] | [next] | [standalone]

#7751

On Mon, 5 Dec 2011 18:14:54 -0800 (PST), Wendell <wendellxe@yahoo.com>
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]

IMHO that is a false dichotomy, certainly for modern Forth compilers
and probably for all languages since the invention of the instruction
cache.

>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? 

Very well.

>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? 

It depends on the implementation. Most experienced Forth programmers
are not great fans of "big" tools, but have toolboxes of small point
tools.

>Does the structure of Forth code allow rewriting isolated routines?

Does the structure of C++ code allow rewriting isolated routines?
Does the structure of Eiffel code allow rewriting isolated routines?
Does the structure of Lua code allow rewriting isolated routines?
...

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#7754

On Dec 6, 6:04 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> >Does the structure of Forth code allow rewriting isolated routines?
>
> Does the structure of C++ code allow rewriting isolated routines?
> Does the structure of Eiffel code allow rewriting isolated routines?
> Does the structure of Lua code allow rewriting isolated routines?
> ...

I'm guessing what the OP meant was that other languages can only
factor at the statement or expression level and Forth lets you factor
below that level.  So he's may be asking if this ability is helpful
for factoring.  The answer is obviously, yes.

[toc] | [prev] | [next] | [standalone]

#7753

On Mon, 05 Dec 2011 18:14:54 -0800, Wendell wrote:

> Does the structure of Forth code allow rewriting isolated routines?

Can't you do this using DEFER? 

DEFER f

: a f ." called F!" ; 

: (F) ." hello " ; ' (F) is F

a
--> hello called F! ok

: (F) ." world " ; ' (F) is F

a
--> world called F! ok

Or you could do something similar with dynamic dispatch using a function 
table.

Cheers,
Arnold

[toc] | [prev] | [next] | [standalone]

#7768

On 12/6/11 3:52 AM, Arnold Doray wrote:
> On Mon, 05 Dec 2011 18:14:54 -0800, Wendell wrote:
>
>> Does the structure of Forth code allow rewriting isolated routines?
>
> Can't you do this using DEFER?
>
> DEFER f
>
> : a f ." called F!" ;
>
> : (F) ." hello " ; ' (F) is F
>
> a
> -->  hello called F! ok
>
> : (F) ." world " ; ' (F) is F
>
> a
> -->  world called F! ok
>
> Or you could do something similar with dynamic dispatch using a function
> table.

You *could* do all those things, but fortunately you don't need to, 
since the easiest thing is to just rewrite the routine itself.

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]

#7776

On Tue, 06 Dec 2011 08:22:03 -1000, Elizabeth D. Rather wrote:

> On 12/6/11 3:52 AM, Arnold Doray wrote:
>> On Mon, 05 Dec 2011 18:14:54 -0800, Wendell wrote:
>>
>>> Does the structure of Forth code allow rewriting isolated routines?
>>
>> Can't you do this using DEFER?
>>
>> DEFER f
>>
>> : a f ." called F!" ;
>>
>> : (F) ." hello " ; ' (F) is F
>>
>> a
>> -->  hello called F! ok
>>
>> : (F) ." world " ; ' (F) is F
>>
>> a
>> -->  world called F! ok
>>
>> Or you could do something similar with dynamic dispatch using a
>> function table.
> 
> You *could* do all those things, but fortunately you don't need to,
> since the easiest thing is to just rewrite the routine itself.
> 
> Cheers,
> Elizabeth

Yes, of course. You could do the same with "C". 

But I think he means re-writing the routine and using the new version at 
runtime. Harder to with "C".  

Cheers,
Arnold

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web