From:  Dean Swan at MITEL on 04/25/2000 11:56 AM


>Okay, I took a crack at it.  The blocks can be removed without making
>things messy.  In general, I divided up SimpleGeneticAlgorithm into 3-4
>classes.  Here are the particulars:


Lex,

     Thanks.  I'll try to take a look at what you've done over the next few
days.

>I toyed with it about 15 minutes, to try and duplicate the trick
>in #fieldAt:width:, but ultimately I gave up. :|  I'm sure someone
>who knows BitBlt better could fix this right up and get performance
>back up.

     That took me quite a while to get right, several hours, at least.  The
inspiration for this was taken from BitBlt>>bitPeekerFromForm:.  I imagine the
put could be done in a similar fashion, using BitBlt>>bitPokerToForm: as a
model, and it is *very* worthwhile, because the speed difference for fields that
are less than 30 bits wide is dramatic.


     As I said, I'll have to play around with what you've done.  Speed is
extremely important for genetic algorithms, since for non-trivial applications,
you may have to run it for thousands or even millions of generations (assuming
you start from a completely random population) to get a usable answer.

>...several methods can get simpler--for example, swapChromosome:with:
> is now just a couple of gets and a couple of sets, instead of 3 BitBlt
> operations.

     I'm not to sure this is a good idea.  Certainly, this is conceptually
cleaner, but gets and sets ultimately end up sending fieldAt:width: and
fieldAt:width:put:, which end up doing a lot more than three BitBlts, even if
the puts are optimized in the same way that the gets are.  It also involves more
message sends, which are a major bottleneck for Squeak, because even my fastest
Mac (my wife's iMac G3/333), and my fastest PC (PII/450) only crank a little
over a million sends/second.  ...And, BitBlt is fast.  That's why I went with
encoding the chromosomes in a form to begin with, in spite of my misgivings
about the obtuseness of the implementation.

     I have to admit the need to reference the original instance of the
SimpleGeneticAlgorithm has always bothered me.  It's a kind of circular
reference thing that just feels "messy".

     I'll see if I can do anything to get the speed back up, but my original
whack at it was primarily focused on making the code small and fast, at the
expense of transparency of design and readability.

>Changing the block to a method didn't seem to hurt things, and
>the non-local features of blocks turned out not to be needed.

     Keep in mind that the class comment demonstrates an absolutely trivial
application.  My real application does involve some other non-local references
to objects that represent the search target, and they are *very* expensive to
compute, so they would have to be made visible to the evaluator method by some
means (class pools? - ick) because recomputing them for every reference is just
out of the question.  I still haven't found very good answers for my target
problem, and I've let this thing crank for days on my fastest machines.

     Exchanges like this is one of the many reasons I'm so attracted to Squeak.
99% of the code I write never gets read by anybody but me.  My employer only
cares if it "meets the spec", and gets done on time.  (They're not really that
brash, but those really are the major things that count come annual review
time).  Actually, they also care about cost targets, so I suppose I get
indirectly graded on target hardware design also.  Such is life developing
embedded firmware.  It also leads to code which places performance and resource
minimization at the top of the priority list, which often leads to less than
totally transparent and obvious designs.

     I'm still inclined to think that blocks are one of the more powerful (and
thus dangerous) constructs in Smalltalk, and I for one don't want to see them go
away.

                                   Thanks Again!

                                         -Dean Swan
                                         dean_swan at mitel.com