Re: Particle Swarm Optimization

mhx@[EMAIL PROTECTED]
 (Marcel Hendrix) writes:
>anton@[EMAIL PROTECTED]
 (Anton Ertl) writes Re: Particle Swarm
Optimization
>> mhx@[EMAIL PROTECTED]
 (Marcel Hendrix) writes:
>>> Triggered by a (German) C't article, last week I experimented a bit 
>>> with Particle Swarm Optimization.
>> ...
>>> Unfortunately, I found the results quite unconvincing. 
>[..]
>> Yes.  Maybe I missed something, but the particle swarm stuff seems to
>> be similar to ant algorithms to me; and that fails to convince me, too
>> (but maybe I miss the point of that, too): We know the best path yet
>> after the first ant walks it, no need to simulate multiple ants
>> walking the same path.  Such algorithms may have a place if you have
>> massive parallelism, and very limited communication bandwidth compared
>> to computation, but not in settings that most of us use.
>
>Well, ant algorithms can solve 'discrete' problems (without 
>derivatives) which is useful. AFAIK, particle swarms can't 
>handle such discrete problems, and are very bad at accurately 
>finding derivatives.

Ok.  I was not looking at the algorithms in such detail.  It just
seems to me that, as soon as the first ant or particle hits a (local)
optimum, the others are unnecessary for finding that optimum, and
these algorithms also don't seem to provide a useful way to get out of
the local optimum and find another one.

>>> STRUCT
>>>   dfloat% FIELD .myBestResult
>[..]
>>> END-STRUCT node%        
>
>> Nice to see that you picked up my STRUCT syntax (although it's too
>> late for Forth200x).
>
>I'd rather keep on using it.

Go ahead.  There's an implementation of it in standard Forth
<http://www.complang.tuwien.ac.at/forth/struct.fs>,
so no reason to
switch.

What I meant was: Had this package been known to be widely used a year
or two ago, it may have had a good chance to be standardized in
Forth200x.

>Would the following be close enough 
>for Forth 200x? I think the word +FIELD can be combined with 
>Gforth's structures? (An obvious problem would be that a Gforth
>structure has an aligned size and would produce wrong results 
>when creating structures of structures.)
>
>( @[EMAIL PROTECTED]
 HEAD> @[EMAIL PROTECTED]
 >BODY  finds the body address of the last word 
>  defined ).
>
>-- ANS 200x 
>: +FIELD ( align1 offset1 size "name" -- align2 offset2 ) 1 SWAP FIELD ;
>: BEGIN-STRUCTURE ( "name" -- addr 1 0 ) 0 VALUE  @[EMAIL PROTECTED]
 HEAD> @[EMAIL PROTECTED]
 >BODY 1
0 ;
>: END-STRUCTURE   ( addr align size -- ) NIP SWAP ! ;
>: CFIELD:  char%   FIELD ; 
>: FIELD:   cell%   FIELD ; 
>: FFIELD:  float%  FIELD ;
>: SFFIELD: dfloat% FIELD ;
>: DFFIELD: sfloat% FIELD ;

I don't think that this is a correct implementation of Forth200x
X:structures, because it requires that there is the alignment on the
stack.  E.g., code like this would not work:

0
  cfield: x
  field:  y
constant xy

I would build (and have built) the X:structures implementation on
lower-level words than those provided by struct.fs.  But if you really
want to do it, you can build it on top of struct.fs:

: +field ( n1 n2 "name" -- n3 ) >r 1 swap 1 r> field nip ;
: cfield:   ( n1 "name" -- n2 ) 1 swap char% field nip ;
: field:    ( n1 "name" -- n2 ) 1 swap cell% field nip ;
....
: begin-structure ( "name" -- addr 0 )
  create
    here 0  0 ,
  does> ( -- size )
    @[EMAIL PROTECTED]
  ;
: end-structure  ( addr n -- )
  swap !  ;

- 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 2008:
http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html