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

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

Bitonic sort

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

Contents

  Bitonic sort Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-10 12:55 +0200
    Re: Bitonic sort mhx@iae.nl - 2014-04-10 12:39 -0700
      Re: Bitonic sort Melzzzzz <mel@zzzzz.com> - 2014-04-12 14:08 +0200
        Re: Bitonic sort mhx@iae.nl - 2014-04-12 05:42 -0700
          Re: Bitonic sort Melzzzzz <mel@zzzzz.com> - 2014-04-12 19:02 +0200
            Re: Bitonic sort Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-12 19:43 +0200
              Re: Bitonic sort Melzzzzz <mel@zzzzz.invalid> - 2014-04-12 20:16 +0200
                Re: Bitonic sort mhx@iae.nl - 2014-04-12 11:54 -0700
                  Re: Bitonic sort Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-12 23:14 +0200
          Re: Bitonic sort "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-12 18:25 -0400
            Re: Bitonic sort anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-13 13:07 +0000
        Re: Bitonic sort Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-12 16:45 +0200
    Re: Bitonic sort "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-10 19:29 -0400
      Re: Bitonic sort Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-11 11:29 +0200
        Re: Bitonic sort albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-11 09:49 +0000
          Re: Bitonic sort m.a.m.hendrix@tue.nl - 2014-04-11 04:17 -0700
            Re: Bitonic sort Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-11 16:18 +0200
            Re: Bitonic sort albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-11 16:29 +0000
              Re: Bitonic sort anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:18 +0000
                Re: Bitonic sort Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-12 00:13 +0200
    Re: Bitonic sort humptydumpty <ouatubi@gmail.com> - 2014-04-11 03:28 -0700
      Re: Bitonic sort humptydumpty <ouatubi@gmail.com> - 2014-04-11 22:35 -0700
        Re: Bitonic sort mhx@iae.nl - 2014-04-12 02:30 -0700
          Re: Bitonic sort humptydumpty <ouatubi@gmail.com> - 2014-04-12 04:09 -0700
          Re: Bitonic sort Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-12 14:16 +0200
            Re: Bitonic sort humptydumpty <ouatubi@gmail.com> - 2014-04-12 12:35 -0700

Page 1 of 2  [1] 2  Next page →

#29505 — Bitonic sort

L.s.

I guess this is the first implementation of a bitonic sort in Forth. Usually
this algorithm is implemented parallel, but this one works fine on a
non-parallel system. Second, bitonic sorts require a number of elements
that is equal to a power of two - this can sort arrays of any size.

It's faster than the Mergesorts I've seen here, but slower than your average
Shellsort, Heapsort or Quicksort. This implementation does quite a bit of
stack trashing - but uses no locals. The EXIT instead of the ELSE you might
expect is due to the tail call optimizer of 4tH.

It's compatible with Wil Baden's QSORT.

Hans Bezemer

---8<---
[UNDEFINED] precedes [IF]
defer precedes                         ( addr addr -- flag )
[THEN]                                 \ compatible with QSORT

: (bitonicMerge)                       ( a n f)
  over 1 > if
    over 1 begin over over > while 1 lshift repeat nip 1 rshift
    rot over - >r rot r> swap          ( f m n-m a)
    over cells over + over 2>r 2swap 2r>
    ?do                                ( n-m a f m)
       over over cells i + i           ( n-m a f m f i+m i)
       rot >r over @ over @ precedes r> =
       if over @ over @ swap rot ! swap ! else drop drop then
    1 cells +loop                      ( n-m a f m)
    >r over over r@ swap recurse       ( n-m a f R: m)
    r> cells rot + -rot recurse exit   ( a+m n-m f )
  then
  drop drop drop
;

: (bitonicSort)                        ( a n f)
  over 1 > if
    >r over over 2/ r@ 0= recurse      ( a n R: f)
    over over 2/ cells + over dup 2/ - r@ recurse
    r> (bitonicMerge) exit
  then
  drop drop drop
;

: sort true (bitonicSort) ;            ( a n --)
---8<---

[toc] | [next] | [standalone]

#29511

On Thursday, April 10, 2014 12:55:59 PM UTC+2, The Beez wrote:
> [censored]

An unquotable, mind curdling mess :-)

ANEW -bitonic

: precedes  ( n1 n2 -- flag ) < ;

: (bitonicMerge) ( a n f -- )
	OVER 1 <= IF  3DROP EXIT  ENDIF
	0 LOCALS| m f n a |
	1 
	BEGIN  n OVER >  
	WHILE  1 LSHIFT  
	REPEAT 1 RSHIFT TO m
	a n m - CELL[]  a 
	       ?DO 
	    	   I m CELLS + @  I @ precedes  
	           f = IF I m CELL[] @   I @   
		   	  I m CELL[] !   I !   
		    ENDIF
	CELL +LOOP
	a          m     f  RECURSE
	a m CELL[] n m - f  RECURSE ; 

: (bitonicSort)	 ( a n f -- )
	OVER 1 <= IF  3DROP EXIT  ENDIF
	LOCALS| f n a |
	a n 2/               f 0= RECURSE
	a n 2/ CELLS +  n 2/ f    RECURSE
	a n f (bitonicMerge) ;

: sort TRUE (bitonicSort) ;  ( a n -- )

\ -- test ----------------------------
#10000000 =: maxsz  0 VALUE sz
maxsz CELLS ALLOCATE ?ALLOCATE =: data
: remove drop  data FREE ?ALLOCATE ;

: fill-data sz 0 ?DO  sz CHOOSE  data I CELL[] !  LOOP ; 
: (BENCH) CR sz U>D (n,3) SPACE fill-data TIMER-RESET  data sz sort .ELAPSED ;
: BENCH  #1000 TO sz  5 0 DO  (bench)  sz #10 * TO sz  LOOP ;

' remove IS-FORGET BENCH

\ FORTH> bench
\ 1,000  0.001 seconds elapsed.
\ 10,000  0.010 seconds elapsed.
\ 100,000  0.085 seconds elapsed.
\ 1,000,000  1.037 seconds elapsed.
\ 10,000,000  13.069 seconds elapsed. ok

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

#29564

On Thu, 10 Apr 2014 12:39:33 -0700 (PDT)
mhx@iae.nl wrote:

> On Thursday, April 10, 2014 12:55:59 PM UTC+2, The Beez wrote:
> > [censored]
> 
> An unquotable, mind curdling mess :-)
> 
> : (bitonicMerge) ( a n f -- )
> 	OVER 1 <= IF  3DROP EXIT  ENDIF
> 	0 LOCALS| m f n a |
> 	1 
> 	BEGIN  n OVER >  
> 	WHILE  1 LSHIFT  
> 	REPEAT 1 RSHIFT TO m
> 	a n m - CELL[]  a 
> 	       ?DO 
> 	    	   I m CELLS + @  I @ precedes  
> 	           f = IF I m CELL[] @   I @   
> 		   	  I m CELL[] !   I !   
> 		    ENDIF
> 	CELL +LOOP
> 	a          m     f  RECURSE
> 	a m CELL[] n m - f  RECURSE ; 
> 

What is CELL[] ?

-- 
Click OK to continue...

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

#29566

On Saturday, April 12, 2014 2:08:52 PM UTC+2, Melzzzzz wrote:
[..] 
> What is CELL[] ?
[..]

: 3DROP  drop drop drop ;
: CELL[] ( addr1 ix -- addr2 ) cells + ;
: CELL   1 cells ;

-marcel

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

#29574

On Sat, 12 Apr 2014 05:42:32 -0700 (PDT)
mhx@iae.nl wrote:

> On Saturday, April 12, 2014 2:08:52 PM UTC+2, Melzzzzz wrote:
> [..] 
> > What is CELL[] ?
> [..]
> 
> : 3DROP  drop drop drop ;
> : CELL[] ( addr1 ix -- addr2 ) cells + ;
> : CELL   1 cells ;
> 
> -marcel

Thanks, but seems that sort is not working properly with gforth, or I a
missing something?

bmaxa@maxa:~/examples/forth$ time gforth-fast -m 400M bitonic1.fs -e bye
1000 
999 
998 
997 
996 
995 
994 
993 
992 
991 
microseconds: 2789 
1 
3 
2 
5 
4 
7 
6 
9 
8 
11 

real	0m0.015s
user	0m0.013s
sys	0m0.002s
bmaxa@maxa:~/examples/forth$ 

: CELL[] CELLS + ;

: 3DROP drop drop drop ;

: precedes  ( n1 n2 -- flag ) < ;

: (bitonicMerge) ( a n f -- )
	OVER 1 <= IF  3DROP EXIT  ENDIF
	0 LOCALS| m f n a |
	1 
	BEGIN  n OVER >  
	WHILE  1 LSHIFT  
	REPEAT 1 RSHIFT TO m
	a n m - CELL[]  a 
	       ?DO 
	    	   I m CELLS + @  I @ precedes  
	           f = IF I m CELL[] @   I @   
		   	  I m CELL[] !   I !   
		    ENDIF
	CELL +LOOP
	a          m     f  RECURSE
	a m CELL[] n m - f  RECURSE ; 

: (bitonicSort)	 ( a n f -- )
	OVER 1 <= IF  3DROP EXIT  ENDIF
	LOCALS| f n a |
	a n 2/               f 0= RECURSE
	a n 2/ CELLS +  n 2/ f    RECURSE
	a n f (bitonicMerge) ;

: sort TRUE (bitonicSort) ;  ( a n -- )

\ -- test ----------------------------
create v 1000 cells allot

: initi
	1000 0 u+do
	1000 i - v i cells + !
	loop ;
: disp
	10 0 u+do
	v i cells + @ . cr
	loop ;
initi
disp
." microseconds: " utime v 1000 sort utime 2swap d- d. cr
disp

-- 
Click OK to continue...

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

#29579

Melzzzzz wrote:
> Thanks, but seems that sort is not working properly with gforth, or I a
> missing something?
No, Marcel missed something ;-)

I replicated the error on gForth and later on 4tH - that made the chances we
stumbled into some obscure compiler error rather remote. My version was
fine ;-)

So change this line:

        a n 2/ CELLS +  n 2/ f    RECURSE

To:

        a n 2/ CELLS +  n dup 2/ - f    RECURSE

And it's fine.

Hans Bezemer

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

#29583

On Sat, 12 Apr 2014 19:43:40 +0200
Hans Bezemer <the.beez.speaks@gmail.com> wrote:

> So change this line:
> 
>         a n 2/ CELLS +  n 2/ f    RECURSE
> 
> To:
> 
>         a n 2/ CELLS +  n dup 2/ - f    RECURSE
> 
> And it's fine.
> 
> Hans Bezemer
> 

Thanks, now it works .


-- 
Click OK to continue...

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

#29584

On Saturday, April 12, 2014 8:16:11 PM UTC+2, Melzzzzz wrote:
> On Sat, 12 Apr 2014 19:43:40 +0200
>>
>>         a n 2/ CELLS +  n dup 2/ - f    RECURSE

n 1+ 2/   also (seems to) work(s).

-marcel

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

#29594

mhx@iae.nl wrote:

> On Saturday, April 12, 2014 8:16:11 PM UTC+2, Melzzzzz wrote:
> n 1+ 2/   also (seems to) work(s).
 Oh, it works. I checked. Except for MAX-N (32 bit):

        1 31 lshift 1- ( MAX-N) 1+ 2/ . -1073741824

Hans Bezemer

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

#29595

On Sat, 12 Apr 2014 08:42:32 -0400, <mhx@iae.nl> wrote:
> On Saturday, April 12, 2014 2:08:52 PM UTC+2, Melzzzzz wrote:

>> What is CELL[] ?
> [..]
>
> : 3DROP  drop drop drop ;
> : CELL[] ( addr1 ix -- addr2 ) cells + ;
> : CELL   1 cells ;
>

Ah, I'm so happy!  More C syntax in Forth...  LOL.

CELLS+ would be the Forth name, wouldn't it?


Rod Pemberton

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

#29609

"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Sat, 12 Apr 2014 08:42:32 -0400, <mhx@iae.nl> wrote:
>> : CELL[] ( addr1 ix -- addr2 ) cells + ;
...
>CELLS+ would be the Forth name, wouldn't it?

TH is relatively common.

- 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 2013: http://www.euroforth.org/ef13/

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

#29570

Melzzzzz wrote:
> What is CELL[] ?
Well, look how it is used:

        array number CELL[]

You'll find this word in many incarnations:

        array number TH
        array number []

If you find something like:

        number array

You can almost be sure there is some kind of DOES> or another word that does
the indexing.

Hans Bezemer

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

#29516

On Thu, 10 Apr 2014 06:55:59 -0400, Hans Bezemer  
<the.beez.speaks@gmail.com> wrote:

> This implementation does quite a bit of
> stack trashing - but uses no locals.

So, Marcel posts a solution with locals!  :-)

As for stack trashing, are you saying you don't have
the following Forth words?

  2DUP 2SWAP -2ROT -ROT


E.g., I think you may have missed optimizing some
of the stack sequences:

over over  -->  2dup
> r rot r> swap  -->  -rot 2swap swap
over 2>r 2swap 2r>  -->  over 2swap -2rot


Rod Pemberton

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

#29520

Rod Pemberton wrote:

> On Thu, 10 Apr 2014 06:55:59 -0400, Hans Bezemer
> <the.beez.speaks@gmail.com> wrote:
> 
>> This implementation does quite a bit of
>> stack trashing - but uses no locals.
> 
> So, Marcel posts a solution with locals!  :-)
> 
> As for stack trashing, are you saying you don't have
> the following Forth words?
> 
>   2DUP 2SWAP -2ROT -ROT
> 
> 
> E.g., I think you may have missed optimizing some
> of the stack sequences:
> 
> over over  -->  2dup
>> r rot r> swap  -->  -rot 2swap swap
> over 2>r 2swap 2r>  -->  over 2swap -2rot

True, but rethinking it may give you some results as well. This got rid of
the 2R> 2SWAP 2R> sequence - and other minor stuff. I think something may
be won as well by getting rid of the ?DO..LOOP and go for
BEGIN..WHILE..REPEAT:

[UNDEFINED] precedes [IF]
defer precedes                         ( addr addr -- flag )
[THEN]                                 \ compatible with QSORT

: (bitonicMerge)                       ( a n f)
  over 1 > if
    rot >r >r                          ( n)
    1 begin over over > while 1 lshift repeat 1 rshift
    tuck - tuck r> -rot cells r@ + r@  ( n-m f m a+n-m a)
    ?do                                ( n-m f m)
       over over cells i + i           ( n-m f m f i+m i)
       rot >r over @ over @ precedes r> =
       if over @ over @ swap rot ! swap ! else drop drop then
    1 cells +loop                      ( n-m f m)
    r> rot >r swap over over r@ recurse
    cells + swap r> recurse exit       ( --)
  then
  drop drop drop
;

: (bitonicSort)                        ( a n f)
  over 1 > if
    >r over over 2/ r@ 0= recurse      ( a n R: f)
    over over 2/ cells + over dup 2/ - r@ recurse
    r> (bitonicMerge) exit
  then
  drop drop drop
;

: sort true (bitonicSort) ;            ( a n --)

I see no real speed improvement though. But no need to go local.. ;-)

Hans Bezemer

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

#29521

In article <5347b5ea$0$2963$e4fe514c@news2.news.xs4all.nl>,
Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>Rod Pemberton wrote:
>
>> On Thu, 10 Apr 2014 06:55:59 -0400, Hans Bezemer
>> <the.beez.speaks@gmail.com> wrote:
>>
>>> This implementation does quite a bit of
>>> stack trashing - but uses no locals.
>>
>> So, Marcel posts a solution with locals!  :-)
>>
>> As for stack trashing, are you saying you don't have
>> the following Forth words?
>>
>>   2DUP 2SWAP -2ROT -ROT
>>
>>
>> E.g., I think you may have missed optimizing some
>> of the stack sequences:
>>
>> over over  -->  2dup
>>> r rot r> swap  -->  -rot 2swap swap
>> over 2>r 2swap 2r>  -->  over 2swap -2rot
>
>True, but rethinking it may give you some results as well. This got rid of
>the 2R> 2SWAP 2R> sequence - and other minor stuff. I think something may
>be won as well by getting rid of the ?DO..LOOP and go for
>BEGIN..WHILE..REPEAT:
>
>[UNDEFINED] precedes [IF]
>defer precedes                         ( addr addr -- flag )
>[THEN]                                 \ compatible with QSORT
>
>: (bitonicMerge)                       ( a n f)
>  over 1 > if
>    rot >r >r                          ( n)
>    1 begin over over > while 1 lshift repeat 1 rshift
>    tuck - tuck r> -rot cells r@ + r@  ( n-m f m a+n-m a)
>    ?do                                ( n-m f m)
>       over over cells i + i           ( n-m f m f i+m i)
>       rot >r over @ over @ precedes r> =
>       if over @ over @ swap rot ! swap ! else drop drop then
>    1 cells +loop                      ( n-m f m)
>    r> rot >r swap over over r@ recurse
>    cells + swap r> recurse exit       ( --)
>  then
>  drop drop drop
>;
>
>: (bitonicSort)                        ( a n f)
>  over 1 > if
>    >r over over 2/ r@ 0= recurse      ( a n R: f)
>    over over 2/ cells + over dup 2/ - r@ recurse
>    r> (bitonicMerge) exit
>  then
>  drop drop drop
>;
>
>: sort true (bitonicSort) ;            ( a n --)
>
>I see no real speed improvement though. But no need to go local.. ;-)

The day someone convinces me I need locals in Forth, is the day
I trade Forth for Lisp for good.

>
>Hans Bezemer

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]

#29523

On Friday, April 11, 2014 11:49:13 AM UTC+2, Albert van der Horst wrote:
> In article <5347b5ea$0$2963$e4fe514c@news2.news.xs4all.nl>,
> 
> The day someone convinces me I need locals in Forth, is the day
> I trade Forth for Lisp for good.

Good programmers can write Forth code in any language :-)

Spass beiseite, I judge comments like yours based in religion
and most certainly unprofessional.
The only concern should be to get the algorithm as clear and as 
efficiently implemented (w.r.t. development and runtime speed, 
program size) as possible.

I am sure that it took me less time to write and debug than Hans did,
and that the result is 10x faster and smaller (more likely 1000 
times). 

Of course, what I should have done was test it against 
quicksort with a 100,000,000 array (to see if the recursion was 
not fouling up the stack), and implement a parallel version :-)

Locals are pure Forth, too. In the dark ages they cost dear header 
space and prevented factoring, but who cares about the former 
with 16GB in the average smart phone?

-marcel

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

#29524

m.a.m.hendrix@tue.nl wrote:

> I am sure that it took me less time to write and debug than Hans did,
> and that the result is 10x faster and smaller (more likely 1000
> times).
Well, that heavily depends on the compiler, since the locals version is on
4tH over twice as large and twice as slow (214 opcodes vs. 106 opcodes and
3.1 secs vs. 1.5 secs).

Hans Bezemer

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

#29525

In article <b03cafe2-d436-4718-98fe-a418c814f59c@googlegroups.com>,
 <m.a.m.hendrix@tue.nl> wrote:
>On Friday, April 11, 2014 11:49:13 AM UTC+2, Albert van der Horst wrote:
>> In article <5347b5ea$0$2963$e4fe514c@news2.news.xs4all.nl>,
>>
>> The day someone convinces me I need locals in Forth, is the day
>> I trade Forth for Lisp for good.
>
>Good programmers can write Forth code in any language :-)
>
>Spass beiseite, I judge comments like yours based in religion
>and most certainly unprofessional.
>The only concern should be to get the algorithm as clear and as
>efficiently implemented (w.r.t. development and runtime speed,
>program size) as possible.

Exactly and if that is by using locals in Forth, I'm sure I'm
better off by using locals in LISP.

>
>I am sure that it took me less time to write and debug than Hans did,
>and that the result is 10x faster and smaller (more likely 1000
>times).

I'm sure that you'll always beat me in speed. I'm sure that if I
where to write it in Python I'll beat the time for me using
Forth with or without locals.

>
>Of course, what I should have done was test it against
>quicksort with a 100,000,000 array (to see if the recursion was
>not fouling up the stack), and implement a parallel version :-)
>
>Locals are pure Forth, too. In the dark ages they cost dear header
>space and prevented factoring, but who cares about the former
>with 16GB in the average smart phone?

As if I ever cared about the speed w.r.t. locals. It is the lack
of orthogonality that blocks the way for further progress, for
good.

A good example is the recent discussion of closures.
Locals will pop up as an extra problem in every context, such as that.
And then closures-with-locals will pop up as an extra problem
in the next context.

>
>-marcel

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]

#29528

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>A good example is the recent discussion of closures.
>Locals will pop up as an extra problem in every context, such as that.

No.  If you just don't allow non-local access to locals, you don't get
closures; you get neither the programming benefits of closures nor the
implementation headaches of closures.  And that's what we are doing in
Gforth.

A more fitting example is return-address manipulations.  They don't
combine well with locals.

- 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 2013: http://www.euroforth.org/ef13/

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

#29546

Anton Ertl wrote:

> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>A good example is the recent discussion of closures.
>>Locals will pop up as an extra problem in every context, such as that.
 
> No.  If you just don't allow non-local access to locals, you don't get
> closures; you get neither the programming benefits of closures nor the
> implementation headaches of closures.  And that's what we are doing in
> Gforth.
Wow, how did we get from "locals" to "closures". Gee, if you want closures,
go straight for OO programming - and get trapped in "pancake programs"*).
IMHO "implementation headaches" is just another euphemism for butt-ugly
design. To quote Dijkstra "if you can't do it elegantly, it ain't worth
doing".
 
> A more fitting example is return-address manipulations.  They don't
> combine well with locals.
"Return-address manipulations" are quite powerful. On the other hand, they
can cause a whole slew of problems - including hard to trace
bugs. "Powerful" and "maintainable" are usually not on the same page - that
much I learned.

Hans Bezemer

*) The OO equivalent of unmaintainable spaghetti code.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web