polyworld-develop — For polyworld developer announcements and discussion

[Polyworld-develop] substantial check-in

[Larry Y. <la...@in...>]

Just FYI, since the cvs emails still aren't going out, and so you 
know to do an update if you're working with Polyworld currently...

A significant update has been checked into the SourceForge 
top-of-tree.  It contains a lot of work by Sean Dougherty, adding 
support for:

* a "give" (energy) behavior
* contact/give/fight logging and analysis
* speed proprioception input
* datalib v3 with streaming
* versioned brainFunction files, which now include numOutputNeurons, 
since this can now vary from run to run
* "pwfarm" scripting support for running multiple copies of Polyworld 
and its data analysis scripts on the 10-machine Mac Mini compute farm

One of the coolest things about this update is that it shows off how 
easy it is to add new input sensors and output behaviors, at runtime, 
thanks to some previous code refactoring Sean did on the brain and 
gene modules.  A huge thanks and major kudos to Sean for a lot of 
really great work.

- larryy

[Polyworld-develop] revised build instructions & broken cvs email

[Larry Y. <la...@in...>]

FYI, the instructions for building Polyworld have been substantially 
simplified and revised at 
<http://beanblossom.in.us/larryy/BuildingPolyworld.html>.  Initially 
Snow Leopard presented some real challenges, and wanting to have a 
common environment for my Intro to Programming class's Python and 
Python as used in the Polyworld data analysis presented additional 
challenges.  But in the end I was able to streamline things a fair 
bit and make everything play reasonably well together.

On a less pleasant front, SourceForge is no longer forwarding source 
code-change email messages, for reasons I haven't had time to look 
into yet.  This has been going on for a while now.  Development 
proceeds apace, but until this gets fixed, the changes won't be seen 
in email, I'm sorry to say.  Huh, I wonder if this message will get 
through...  Let me know if it doesn't. :)

- larryy

P.S. Someone finally got Polyworld to build on Windows. 
Unfortunately, it only works with a modified snapshot of the source 
base, not current top-of-tree source, so we're only part way there. 
Links to details on that BuildingPolyworld page.

[Polyworld-develop] bct now required

[Larry Y. <la...@in...>]

I've just checked in code that means the C++ version and Python 
wrapper for the Brain Connectivity Toolbox are now required to run 
CalcMetricsOverRecent.

Get the bct-cpp code, plus instructions to build and install here:

http://code.google.com/p/bct-cpp/

After doing 'make' and 'sudo make install', also follow the 
instructions to build the Python wrapper ('make swig') and either 
copy the bct.py and _bct.so files into .../polyworld/scripts/ or put 
them wherever system-level Python modules get installed on your 
system.  (Eventually bct.py and _bct.so should be installed at the 
system level automatically.)

- larryy

Re: [Polyworld-develop] don't put Polyworld in the background on Macs

[Larry Y. <la...@in...>]

At 11:43 PM -0500 12/28/09, Larry Yaeger wrote:
>A hard-won lesson:  Do not put Polyworld into the background while it is running, ever, if you care about the results, at least on Macintoshes.

Never mind, and apologies for the spam.  No sooner do I send that than I discover a way to leave the POV window a tool window, but prevent it from being auto-hidden when Polyworld is placed into the background.  Problem solved, for now.  (But still don't manually close the POV window!)

- larryy

[Polyworld-develop] don't put Polyworld in the background on Macs

[Larry Y. <la...@in...>]

A hard-won lesson:  Do not put Polyworld into the background while it 
is running, ever, if you care about the results, at least on 
Macintoshes.

All but the main overview window, including the agents' POV window, 
are "tool" windows.  When an app stops being frontmost, tool windows 
are automatically hidden.  That means the agent POV rendering and 
subsequent pixel reading to produce their vision inputs are being 
done to a hidden window, which does not produce valid results, at 
least under some conditions on some machines.

I've confirmed that making the POV window a normal (as opposed to 
tool) window eliminates the problem, but it raises other UI issues I 
don't want to solve right now.  If there's a way to not hide tool 
windows, that might be the easiest fix.  But the best fix would be to 
make the POV rendering work correctly whether the POV window is 
hidden or not.  Someday...

This probably does not affect Linux boxes, because I don't think 
Linux auto-hides tool windows.  Or perhaps rendering to hidden 
windows is no different than rendering to visible windows on Linux. 
In any event, putting Polyworld into the background on at least one 
Linux box did not affect the simulation.

The simulation is also unaffected by manipulating (closing, opening, 
moving) other windows in Polyworld, including on a Mac, even if they 
overlap the POV window.  Just don't close the POV window.

- larryy

[Polyworld-develop] graph theory metrics check-in

[Larry Y. <la...@in...>]

The source code check-in that was just done for Xin Shuai's support 
for calculating and plotting graph theoretical metrics has a few 
issues:

* SciPy, NumPy, and NetworkX are probably now required to run 
CalcMetricOverRecent

* There is sufficient commonality between CalcMetricOverRecent and 
CalcComplexityOverRecent, and between common_complexity.py and 
common_metric.py, that these pairs of scripts could probably be 
merged, but I did not attempt it for this first check-in.

* I'm not sure "value" is the best variable name to stand in for 
"complexity" and "metric", but left this as Xin had it in the plot 
script.

* I solved a few issues, such as zero-length lists, a bit differently 
than Xin did, so Xin needs to confirm that everything still works 
after my changes.

- larryy

[Polyworld-develop] Polyworld now requires Qt 4.5

[Larry Y. <la...@in...>]

Polyworld now requires Qt 4.5 (or later).

Qt 4.5 greatly enhances Qt's compatibility with Mac OS X.  Frameworks 
and executables are placed in correct, default locations, eliminating 
the need for various environment variables and manually entered code 
paths in Xcode, substantially simplifying Polyworld's installation 
(and maintenance).  Qt 4.5 also can be installed from binary 
libraries rather than requiring a multi-hour build from source, 
further simplifying Polyworld's initial installation.  But in order 
to move to Qt 4.5, enough things had to change that Polyworld will 
now only build with Qt 4.5 (or later).

The build instructions at 
http://beanblossom.in.us/larryy/BuildingPolyworld.html have been 
updated.

[Polyworld-develop] "serial_only" tag

[Larry Y. <la...@in...>]

The complete set of current source code has been tagged as 
"serial_only", in preparation for parallelization code coming from 
Sean.

- larryy

Re: [Polyworld-develop] Spore and Genes

[Larry Y. <la...@us...>]

At 4:49 PM -0400 9/7/08, Andrew wrote:
>I think the computational complexity would become overwhelming.  At some point, its faster to watch evolution take place in a test tube than a ALife simuation, isn't it?

Well, considering that it took 3 or 4 *billion* years to go from single-celled organisms to us (plus roughly another billion to go from prebiota to those single-celled organisms), maybe not so much. :)  But, yes, it was worrying a lot about how to blend necessary limits on computational complexity with desired biological verisimilitude plus a desire to ultimately investigate AI that led to all of the design decisions in Polyworld.

- larryy

Re: [Polyworld-develop] Spore and Genes

[Andrew <ber...@gm...>]

I think the computational complexity would become overwhelming.  At some
point, its faster to watch evolution take place in a test tube than a ALife
simuation, isn't it?

On Sun, Sep 7, 2008 at 4:05 PM, <la...@us...> wrote:

> At 2:00 AM -0400 9/7/08, Andrew wrote:
> >Spore has been released!  OK, so only a somewhat related peice of news-
> but I think I might be going out to buy it tomorrow assuming I can find a
> copy.  :)  Anyone else psyched about it?
>
> Oh, heck, I sprung for a pre-order of the "Galactic" edition. :)  Not that
> I will have the time or patience to actually do much with it. :(  But I do
> feel compelled to know something about it.
>
> >The real reason I'm posting to the list to just throw out some thoughts of
> mine I've had today regarding some future features of polyworld and the
> related design approaches, specifically (or probably more acurately just a
> working example) related to the critter genome and genes.
>
> By and large I think it's a good, interesting approach to designing such a
> system.  There are some potential gotchas, I think, such as...  How do the
> genes map to the functionalities they imply?  How did the control structure
> (neural network or whatever) get specified?  How did the outputs get
> computed from the inputs and the control structure?  I think there are
> answers to all of these, but they have implications for the design of the
> code.
>
> But, ultimately, the role of genes, sensors, and actuators, while
> extendable, are still entirely defined by the programmer.  (A reasonable
> complaint lodged against Polyworld and all ALife systems to date.)  In the
> end, you might have a more flexibly-programmed Polyworld-like system, but I
> doubt it could ever do anything that Polyworld couldn't.
>
> Of course, the genetics in Polyworld are, at best, a cartoon of biological
> genetics.  Real genes are expressed continuously, in distinct activation
> patterns, in every cell throughout an organism's life.  They regulate and
> are regulated by other genes and epigenetic components (methylation,
> phosphorylation, etc.).  Their products interact in complex ways to produce
> phenotypic form and function.  Their numbers vary across species.
>  Importantly, they can be duplicated through copying errors.  Polyworld's
> genetics are much more Genetic-Algorithm-like, with fixed numbers and fixed
> meanings for the genes, and the genes are only expressed once, at birth,
> then play no further role in the agents' lives.  An almost embarrassing
> simplification, except, fortunately, standard GA approaches have been shown
> to be excellent at exploring complicated high-dimensional spaces, which is
> what I imagine Polyworld to be doing in "neural-architecture space".
>
> By the way, I'll recommend a book that Virgil Griffith recommended to me:
>  Evolving Brains, by John Morgan Allman <
> http://www.amazon.com/dp/0716750767/>.  (Virgil did a lot of work on
> Polyworld with me as an undergrad at IU before going to the computational
> neuroscience program at CalTech, which is where he read this book as part of
> a course, I think.)
>
> FWIW, I've been thinking off and on about a way to write a much more
> open-ended ALife system.  I think the only way for such a system to be truly
> open-ended is for evolution to produce a situation in which one agent *is*
> the ecological niche for another agent.  I.e., there must a way for
> symbiosis and hierarchical self-organization to take place.  I keep coming
> back to one of two approaches.  It's conceivable that one must step all the
> way down to an artificial chemistry in order to produce the desired outcome.
>  But I think it just may be possible to finesse most (but not all)
> artificial chemistry by working predominantly at the level of the cell.
>  Cells would have key aspects of their physiology and behavior determined by
> their genes, of course.  Cell function would be under the control of
> continuously expressing (and re-expressing) genes, plus some signals
> produced by the cells.  Just how open-ended one can be at the cell level is
> unclear, but at least one could build in th
>  e ability to:
>
> *) vary a level of adherence along the cell surface (how exactly this is
> distributed, spatially, I'm not sure yet)
> *) vary a level of wall stiffness/springiness along the cell surface
> (uniform? spatially distributed?)
> *) propagate a signal (the functional equivalent of an axon action
> potential)
> *) receive a signal (the functional equivalent of a synapse)
> *) modulate received signals (what functional form this takes is unclear)
> *) emit chemicals that affect adjacent cells
> *) absorb chemicals through the cell wall
> *) vary permeability to different chemicals in the cell wall
> *) shrink and expand along multiple axes (in response to both genes and
> received signals and chemicals)
>
> These various cell behaviors are necessarily all temporal.  They are all
> derived from the cell's gene expression, but some of them exhibit their own
> temporal behaviors (signal propagation, reception, and modulation, for
> example, but also shrinking and expanding in response to these signals).  I
> think it might be possible to allow arbitrary aggregations of cells this
> way, that could specialize in form and function, incorporate other cells
> into an existing "body", build muscle tissue, build neural tissue, dissolve
> and consume other cells for energy and chemical resources...  In short,
> support symbiosis, hierarchical form and function, and be genuinely
> open-ended.  Yet only the chemical emission and absorption and the cell
> permeability have to drop down to the artificial chemistry level.  All other
> chemistry is finessed.
>
> Okay, I'll shut up now.  I've been thinking about this a fair bit over the
> years, and have made a few notes to myself, but this is the first time I've
> written anything up for anyone else's consumption.  I think I have too much
> to explore with Polyworld to actually do anything with this, but, then
> again, if the right PhD student came along, or someone wanted to pursue it
> as an open source project, or...
>
> One final note:  Even with all that in place, I fear that the mapping from
> gene to low-level cellular expression is too static.  And it's not
> immediately obvious how to allow genes to be duplicated, unless their impact
> on cell function is mediated through an artificial chemistry, which
> introduces all kinds of additional computational overhead and forces a very
> different design aesthetic on the system.  Ah well.  Nothin's easy.
>
> - larryy
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> polyworld-develop mailing list
> pol...@li...
> https://lists.sourceforge.net/lists/listinfo/polyworld-develop
>

Re: [Polyworld-develop] Spore and Genes

[<la...@us...>]

At 2:00 AM -0400 9/7/08, Andrew wrote:
>Spore has been released!  OK, so only a somewhat related peice of news- but I think I might be going out to buy it tomorrow assuming I can find a copy.  :)  Anyone else psyched about it?

Oh, heck, I sprung for a pre-order of the "Galactic" edition. :)  Not that I will have the time or patience to actually do much with it. :(  But I do feel compelled to know something about it.

>The real reason I'm posting to the list to just throw out some thoughts of mine I've had today regarding some future features of polyworld and the related design approaches, specifically (or probably more acurately just a working example) related to the critter genome and genes.

By and large I think it's a good, interesting approach to designing such a system.  There are some potential gotchas, I think, such as...  How do the genes map to the functionalities they imply?  How did the control structure (neural network or whatever) get specified?  How did the outputs get computed from the inputs and the control structure?  I think there are answers to all of these, but they have implications for the design of the code.

But, ultimately, the role of genes, sensors, and actuators, while extendable, are still entirely defined by the programmer.  (A reasonable complaint lodged against Polyworld and all ALife systems to date.)  In the end, you might have a more flexibly-programmed Polyworld-like system, but I doubt it could ever do anything that Polyworld couldn't.

Of course, the genetics in Polyworld are, at best, a cartoon of biological genetics.  Real genes are expressed continuously, in distinct activation patterns, in every cell throughout an organism's life.  They regulate and are regulated by other genes and epigenetic components (methylation, phosphorylation, etc.).  Their products interact in complex ways to produce phenotypic form and function.  Their numbers vary across species.  Importantly, they can be duplicated through copying errors.  Polyworld's genetics are much more Genetic-Algorithm-like, with fixed numbers and fixed meanings for the genes, and the genes are only expressed once, at birth, then play no further role in the agents' lives.  An almost embarrassing simplification, except, fortunately, standard GA approaches have been shown to be excellent at exploring complicated high-dimensional spaces, which is what I imagine Polyworld to be doing in "neural-architecture space".

By the way, I'll recommend a book that Virgil Griffith recommended to me:  Evolving Brains, by John Morgan Allman <http://www.amazon.com/dp/0716750767/>.  (Virgil did a lot of work on Polyworld with me as an undergrad at IU before going to the computational neuroscience program at CalTech, which is where he read this book as part of a course, I think.)

FWIW, I've been thinking off and on about a way to write a much more open-ended ALife system.  I think the only way for such a system to be truly open-ended is for evolution to produce a situation in which one agent *is* the ecological niche for another agent.  I.e., there must a way for symbiosis and hierarchical self-organization to take place.  I keep coming back to one of two approaches.  It's conceivable that one must step all the way down to an artificial chemistry in order to produce the desired outcome.  But I think it just may be possible to finesse most (but not all) artificial chemistry by working predominantly at the level of the cell.  Cells would have key aspects of their physiology and behavior determined by their genes, of course.  Cell function would be under the control of continuously expressing (and re-expressing) genes, plus some signals produced by the cells.  Just how open-ended one can be at the cell level is unclear, but at least one could build in the ability to:

*) vary a level of adherence along the cell surface (how exactly this is distributed, spatially, I'm not sure yet)
*) vary a level of wall stiffness/springiness along the cell surface (uniform? spatially distributed?)
*) propagate a signal (the functional equivalent of an axon action potential)
*) receive a signal (the functional equivalent of a synapse)
*) modulate received signals (what functional form this takes is unclear)
*) emit chemicals that affect adjacent cells
*) absorb chemicals through the cell wall
*) vary permeability to different chemicals in the cell wall
*) shrink and expand along multiple axes (in response to both genes and received signals and chemicals)

These various cell behaviors are necessarily all temporal.  They are all derived from the cell's gene expression, but some of them exhibit their own temporal behaviors (signal propagation, reception, and modulation, for example, but also shrinking and expanding in response to these signals).  I think it might be possible to allow arbitrary aggregations of cells this way, that could specialize in form and function, incorporate other cells into an existing "body", build muscle tissue, build neural tissue, dissolve and consume other cells for energy and chemical resources...  In short, support symbiosis, hierarchical form and function, and be genuinely open-ended.  Yet only the chemical emission and absorption and the cell permeability have to drop down to the artificial chemistry level.  All other chemistry is finessed.

Okay, I'll shut up now.  I've been thinking about this a fair bit over the years, and have made a few notes to myself, but this is the first time I've written anything up for anyone else's consumption.  I think I have too much to explore with Polyworld to actually do anything with this, but, then again, if the right PhD student came along, or someone wanted to pursue it as an open source project, or...

One final note:  Even with all that in place, I fear that the mapping from gene to low-level cellular expression is too static.  And it's not immediately obvious how to allow genes to be duplicated, unless their impact on cell function is mediated through an artificial chemistry, which introduces all kinds of additional computational overhead and forces a very different design aesthetic on the system.  Ah well.  Nothin's easy.

- larryy

[Polyworld-develop] Spore and Genes

[Andrew <ber...@gm...>]

Spore has been released!  OK, so only a somewhat related peice of news- but
I think I might be going out to buy it tomorrow assuming I can find a copy.
:)  Anyone else psyched about it?

The real reason I'm posting to the list to just throw out some thoughts of
mine I've had today regarding some future features of polyworld and the
related design approaches, specifically (or probably more acurately just a
working example) related to the critter genome and genes.

I've been reading a little toay about biological genetics and refreshin my
memory from my High School biology class as to how genes, codons and all
that jazz work and how I can apply that knowledge to build a more flexible
means of storing a critter's genome - maybe not use it as a blueprint, but
just gleen some understanding to maybe think of the data structures
differently.

The data-related things I took from it (or at least adapted from it) are:
* A "gene" would be an arbitrary length series of codons.
* We could optionally include the concept of a chromosome to collect genes
into sets taht get paired up when a new critter is created through mating.
* The genome would contain an arbitrary number of genes- this number
shouldn't fluctuate terribly much.
* Each gene describes some sort of trait... be it the
existance/location/functuion of a neural group or the internal structure of
a neural group, or the means of locomotion, vision an whatever other sensory
mechanisms we can devise.
*  I think simply stacking traights into a data structure is too
constrictive- when reading about how proteins are generate from the sequence
of codons, I thought to myself "this seems like a much more flexible, *
natural* way of representing the data.  I'm not suggesting we create a DNA
system that generates psuedoproteins and from that collection of proteins we
derive the structure of the organism (though that would be kind of cool), I
guess I'm just inspired (and completely overwhelmed) by the complexity of
the system biology has devised for this.

So heres a data structure somewhat representative of what I'm talking
about... just ignore that there aren't any options on these objects, those
can easily be added later:

typedef Codon unsigned int;

class Gene {
    List<Codon> codons;
}

class Genome {
    List<Gene> genes;
}

Now, supposing we want some different gene types, we simply decide some
basic rules as to how to convert to and from a sequence of codons to an
actual trait.  Not sure what the conversion process would be- it wouldn't
necessarily need to be a 1:1 conversion (a gene can present differently
based on the existance or abence of other genes, and maybe two ifferent
genes could tally up to the same result).

I mean, you can also add the Chromosomes:

class Gene { List<Codon> codons; }
class Chromosome { List<Gene> genes; }
class Genome { List<Chromosome> chromos; }

What I envision with this breakdown is the ability to "plug-in" new stuff in
an object-oriented way:

class Gene {
    List<Codon> codons;
public:
    /* note: would use smart-pointer here to make cleanup easier */
    /* note2: function defined like in java, would really be in a module */
    static Gene* getInstance(const string& instanceType) {
        Gene* gene;
        if instanceType == "basic")
            gene = new BasicGene();
        else if(instanceType == "freaky")
            gene = new FreakyGene();
        else if(instanceType == "no mutate")
            gene = new ImmutatableGene();
        else
            throw ("Unknown Gene Type: "+instanceType);
        return gene;
    }
}

class CritterInput {}
class EyeCritterInput : CritterInput {}
class AntannaCritterInput : CritterInput {}
class CritterOutput {}
class LocomotiveCritterOutput : CritterOutput {}
class ScreamCritterOutput : CritterOutput {}
class MateCritterOutput : CritterOutput {}

In otherwords, create object oriented inherited types... so if in the
critter brain logic you have something like:
class Brain {
    // ...
    List<CritterInput> inputs;
    List<CritterOutput> outputs;
    // ....
public:
    void updateIO() {
        for(List<CritterInput>::iterator itr = inputs.begin(); itr++; itr !=
inputs.end()) {
            // do the logic to update the input
        }
        for(List<CritterOutput>::iterator itr = outputs.begin(); itr++; itr
!= outputs.end()) {
            // do the logic to update the output
        }
   }
}

This way, you can easily add new inputs and outputs that follow a simple
contract and no modifications to the Brain class would even need to be made,
at least not to all the functions.  All the type-specific logic would be
housed inside of that class in virtual member functions.

wow, I've really rambled on a bit here...

I know overhauls of the system are out of the question, but I think a system
like this really lends itself to object-oriented concepts with pluggable
logic and such.  I guess the only thing I'm trying to accomplish here is to
say that I think we should keep this sort of stuff in the back of our minds-
and furthermore, its been nagging at me and I needed to get it typed out and
thought I'd share.  :)

Any feeback would be awesome- even if its something as simple as "your
bloody crazy, come back to earth please...."

Andrew

[Polyworld-develop] PwMoviePlayer and Xcode project changes

[Larry Y. <la...@in...>]

Following is some news about a new release.  Most important to 
developers is that Xcode now requires QTS (path to a static build of 
Qt) and GSL (path to the directory containing the gsl installed libs) 
in order to support an easy way to do static builds of Polyworld and 
PwMoviePlayer.  (Just select Development-static as the active 
configuration.)

Actually, it's possible that everything would continue to work and 
you wouldn't have to create QTS and GSL if you never tried to do a 
static build.  Not sure.

The online build instructions have been updated.

- larryy

---------------------------------------------------------------------------

Command line arguments to PwMoviePlayer have been implemented to make 
it easy to run and script for demo purposes. New options are: 
   -f movieFile 
   -l legendFile 
   -e endFrame 
   -r frameRate 
 
In addition, the Xcode project has been modified to support easy 
static builds. The Xcode project now requires QTS and GSL source tree 
variables (in addition to the previously required QT). 
 
The Polyworld installation and build web page has been updated with 
instructions to match this 1.5.2 release. See: 
http://beanblossom.in.us/larryy/BuildingPolyworld.html

[Polyworld-develop] easier, but broken

[Larry Y. <la...@in...>]

Hi, all  -  I tweaked the build process for polyworld a tiny bit, to 
make the initial install and build process simpler.  I also 
documented the process at 
<http://beanblossom.in.us/larryy/BuildingPolyworld.html>.  This is to 
help other people setting up for the first time.  I had to do this a 
couple of times recently and was amazed how many steps there were, 
that you had to get entirely right, in order for everything to work, 
and Virgil mentioned some folks at Sussex (am I remembering right, 
Virgil?) were looking into setting up Polyworld, so I thought I'd try 
to make the process as easy as I could.

However, in simplifying one thing, I broke the build for anyone who 
is using the old setup.  Fortunately, the fix is trivial and a 
simplification at that....

You can get rid of environment variables QTDIR and QT_INCLUDE_DIR, 
and you no longer need to add anything special to MANPATH or set 
DYLD_LIBRARY_PATH.

Instead you just export QT=/usr/local/Trolltech/qt or wherever you 
installed Qt (and add $QT/bin to your PATH like always).

Similarly, in Xcode, you can delete QtInc, QtBin, and QtLib from your 
"Source Tree" preferences, and replace them with just QT, which 
points to the same installed location for Qt.

Only if you have an unusual installation of Qt (such as for macports, 
nee darwinports) do you have to do anything else, which the web page 
above covers.

Just wanted you to know, so you don't update and wonder why the build 
seems broken.

- larryy

[Polyworld-develop] 1.5 source and apps available

[Larry Y. <la...@in...>]

Just FYI, I've had a couple of people bang their heads on the 
drastically outdated 1.0 source release, instead of checking out the 
latest source from CVS.  And I had another request for a binary 
release of the code.  So I today released what I called a 1.5 set of 
source code, plus Mac/Intel-only Polyworld.app and PwMoviePlayer.app 
executables.  Hopefully that'll make life easier on some folks.

- larryy

[Polyworld-develop] Polyworld vs. random numbers

[Larry Y. <la...@in...>]

Hi, all  -  If you've got a second, could you please compile and run the 
attached rancheck.c program, and then copy and paste the output into an email 
to me, and let me know what kind of machine and what OS release you ran it on?

I'm trying to find out how (in)consistent the random number generators are from 
machine to machine and OS release to OS release.

Thanks  -  larryy

P.S. A few bugs have surfaced in the all-in-one x-sorted list and food patch 
work, but I think I've got them fixed now.  Not checked in yet, but probably 
tomorrow.

[Polyworld-develop] New FoodPatch objects support structured food distribution

[Larry Y. <lsy...@be...>]

Quoting the news tidbit I just posted, to make sure all developers 
know about this somewhat substantial change...

Both FoodBands and the original uniform random distribution of food 
have been replaced with Matt Whitehead's new FoodPatch objects. They 
allow any number of rectangular or elliptical patches, with any 
amount of food and arbitrary food growth rates distributed uniformly, 
with a linear probability distribution, or with a Gaussian/normal 
probability distribution, either probabilistically or 
rigidly/deterministically. 
 
A new worldfile (now version 19) has been checked in that shows how 
to use them (although a known problem with complexity as a fitness 
function will make the code crash after a fairly short time with this 
worldfile). 
 
A FoodPatchNotes.pdf document from Matt on how food patches were 
designed and how they work is in the docs/ directory.

- larryy

P.S. If SourceForge's servers don't strip it, I'm attaching a 
"worldfile_patchtest" that is kind of fun to run, once, just to see 
very different and dramatic patch densities, shapes, and growth rates.

[Polyworld-develop] short updates

[Larry Y. <lsy...@be...>]

As some discovered, I failed to 'cvs add' the 
utils/objectxsortedlist.* files initially.  Those are in.

I also failed to 'cvs add' environment/brick.* files.  Those are now in.

I did a 'cvs remove' on Polyworld.xcode and its contents and 
committed it, as this is strictly for the old version of Xcode, which 
we no longer support.  Next time you do a 'cvs update', make it a 
'cvs update -dAP' to be sure everything is fully up to date and the 
old .xcode project gets purged from your system.

I successfully built and ran Polyworld on my Intel iMac.  Better 
testing is needed, but speed seems comparable on this 2GHz dual core 
Intel box to my dual 2.5 GHz G5 box.  Amazing.  I don't know if 
byte-ordering issues in the genetic bit-twiddling will surface or not 
yet, and whether identical runs on PPC and Intel produce identical 
results is yet to be determined.

PwMoviePlayer has a problem on Intels, due undoubtedly to the byte 
ordering.  It runs and plays the movie, but the entire screen is 
saturated with red, probably due to a 0xff being shoved into the byte 
that was intended for the alpha channel.  Off hand, G looks G, and B 
looks B, but R is messed up, as is, presumably, alpha.

- larryy

[Polyworld-develop] single x-sorted list checked in

[Larry Y. <lsy...@be...>]

Matt Whitehead's changes to put all objects into a single x-sorted 
list are now checked in.  (Before I committed the changes, I tagged 
the existing source with "pre-object-x-sort".)

Detailed behavior is identical up until one encounters a (mostly 
inconsequential) bug in old code.*  As expected, coarser scale 
behavior, measured by performance on one of the Ideal Free 
Distribution runs, is also consistent with the older code.

The new code appears to be marginally faster than the old code, but I 
need to run a longer simulation using the old code on a particular 
CPU to make a precise statement.

Virgil, you can update your source now and have at.  You and MattW 
are both going to be pounding on the gene code, so you'll want to be 
a little careful and maybe keep in touch.

Cullen, I don't think this hurts or helps you, aside from the modest 
speed-up.  And, Matt Ira, I now you're not quite ready to re-sync yet.

- larryy

*Previously, the food was not re-sorted each time step, and while 
food centers remain sorted automatically, because food doesn't move, 
the list is actually sorted on leading edge, which changes as food is 
eaten and shrinks.  The effect is minimal, but detectable.

Re: [Polyworld-develop] touch suggestions?

[Nicolas Z. <kru...@po...>]

Hi,

this touch idea seems very very interesting in terms of perception vs  
camouflage.
I guess the whole point is to provide a way to gather more  
information about the things that exist in the universe, and to  
provide a possibility to mimick it or play with it (for mating  
purposes, say).
I just wonder if the pleasure/pain is a touch sensation, or just the  
way my brain reacts to other sensations. That would be related to the  
extremeness of other sensastions such as hot or (rough and hard).
As for suggestions for added sensations, I'd say animate/inanimate,  
or at least organic/inanimate. That's what causes the most irrational  
(and therefore reflex-oriented) reactions to things we touch...

As a side note, I hope I'll get something to catch up on you guys on  
the topic of neuron programming pretty soon, I feel a little dumb  
with just my programming skills to help you out...

-- 
Nicolas


On 07 Apr 2006, at 03:07, Larry Yaeger wrote:

> The point of telling everyone this is to solicit suggestions for  
> other sensations that might be appropriate.  Anything come to mind?

[Polyworld-develop] touch suggestions?

[Larry Y. <lsy...@be...>]

Hi, all  -  Turns out Matt Whitehead is going to be implementing 
touch, on the way to implementing pick-up/release.  Basically, we 
want the critters to be able to distinguish what it is they would be 
picking up were they to express that behavior.

Rather than implement a pick-up/release-food, pick-up/release-brick, 
etc. suite of behavior neurons, we decided to have a single 
pick-up/release neuron, and the ability to distinguish items by touch 
(as well as vision, of course).

We also decided not to have multiple unique touch neurons 
(touching-food, touching-a-brick, etc.), or unique tags for each item 
(0001 for food, 0010 for bricks, etc.).

Instead, we're going to have a suite of touch sensations that have 
continuous values between 0.0 and 1.0:

   smooth - rough
     soft - hard
     cold - hot   (0.5 is neutral)
      dry - wet
pleasure - pain  (0.5 is neither)

and then assign a value for each of these dimensions/sensations for 
each type of object in the world, as in:

        food  brick  critter  barrier  edge  firepit  underbrush       nothing
rough    .6    .8      .4       .5    0.0      .5    depends on size    0.0
hard     .3   1.0      .3      1.0    1.0     0.0    depends on size    0.0
hot      .5    .5      .6       .5    0.5     1.0        .5             0.5
wet      .3   0.0      .2      0.0    0.0     0.0        .1             0.0
pain     .5    .5      .3       .5    0.5     1.0    depends on size    0.5

and so on.  (Those are just off the cuff numbers.  Nothing set in stone.)

The point of telling everyone this is to solicit suggestions for 
other sensations that might be appropriate.  Anything come to mind?

- larryy

P.S. For example, I just thought of curved - pointy, though I don't 
know if it's particularly useful.

[Polyworld-develop] new capabilities checked in

[Larry Y. <lsy...@be...>]

Major thanks to Cullen Bryan for some significant enhancements to 
Polyworld's interface.  They've just been checked in and

1) revive the overhead view window
2) restore the rotating camera in the main window (and allow rotation 
to be toggled on and off with the 'r' key)
3) support the selection of 1st to 5th fittest agent for monitoring 
(by pressing number keys '1' through '5')
4) support a "tracking" mode that will stick with an agent so chosen, 
until it dies, rather than switching amongst agents as the fitness 
list changes (toggled via 't')
5) allow some interactive control of the camera in the main window 
with the mouse
6) provide the files for using KDevelop on Linux.

Wow!

I tweaked the code slightly so the world would go ahead and rotate as 
long as the rotation rate specified in the worldfile is non-zero.

I also integrated Cullen's changes to the polyworld_linux.pro file 
(actually, the polyworld.pro file he was using on linux), along with 
some Qt flags bracketing platform-specific code, so the main 
polyworld.pro file should now work for both Mac and Linux.  (There's 
a placeholder, but no support for Windows yet.)  We should no longer 
need polyworld_linux.pro, although I'll need Cullen to tell me for 
sure that I didn't break anything before I 'cvs rm' it.

It's really nice to have these features back, Cullen.  I was watching 
the fittest agent in the overhead window and could actually discern 
improvements in behavior from one generation to the next.

Oh, you may notice that the camera used to draw the overhead view is 
now visible in the main view.  I don't like the big white box it is 
currently rendered with, but I do like seeing where it is.  It lets 
you find the agent being tracked in the overhead view over in the 
main view.  Nice.  Just need to make it prettier at some point, by 
giving it its own object and getting it properly oriented.

There may also be some issues with ownership of focus...  I think I 
had to click on the main window in order to get those keystrokes 
recognized.  I'd like to see if we can get them captured by the 
application, instead of a specific window, at some point.

Thanks, Cullen!

- larryy

P.S. Virgil has also checked in some extremely important changes for 
our research lately, most importantly including the native 
calculation of Olaf Sporns's information-theoretic complexity 
measure.  Thanks aren't enough!

Re: [Polyworld-develop] don't update (temporarily)

[Larry Y. <lsy...@be...>]

At 3:40 PM -0500 3/3/06, Larry Yaeger wrote:
>There are some changes checked in that make Polyworld not build 
>(mainly just missing libraries).  Fix coming soon.  Will send email.

Okay, everything builds once more, *if* you install the Gnu 
Scientific Library, per the instructions now included in README.txt:

Download, build, and install gsl (from gnu.org)
* General page for gsl downloading: 
http://www.gnu.org/software/gsl/#downloading
* Or obtain directly from: ftp://ftp.gnu.org/gnu/gsl/gsl-1.7.tar.gz
* Unzip and untar wherever you want
* Then follow the instructions in "INSTALL"
   (./configure ; make ; make install)
   This should install to /usr/local/include and /usr/local/lib.

Virgil needs gsl for his work computing Olaf Sporns's complexity 
metric within Polyworld, and this will be a part of Polyworld from 
now on.  We may embed a copy of gsl in the polyworld project itself, 
to avoid having to download multiple libraries, but we didn't want to 
hassle with the quirks of cvs add today.

Anyone a cvs guru?  Is there any way to do a recursive add?  There 
are over 1,700 files, in multiple nested directory levels.  We can 
potentially use find and a short shell script, but I was wondering if 
cvs import could be made to work for this function?  (Although I want 
to be sure this stuff is Top Of Trunk, not on some branch after it 
gets imported/added.)

- larryy

[Polyworld-develop] don't update (temporarily)

[Larry Y. <lsy...@be...>]

There are some changes checked in that make Polyworld not build 
(mainly just missing libraries).  Fix coming soon.  Will send email.

- larryy

[Polyworld-develop] Polyworld moved to latest tools

[Larry Y. <lsy...@be...>]

Polyworld has been updated to use Qt 4.1, gcc 4.0, Xcode 2.2, and 
-shared (as opposed to -static) libraries. Moving to Qt 4.1, gcc 4.0, 
and Xcode 2.2 is just to keep up with the latest tools. Using 
shared/dynamic libraries greatly speeds up linking, facilitating the 
development cycle.

This probably necessitates everyone upgrading to these latest tools 
and rebuilding Qt.  Just type 'configure' (no -static anymore), 
'make', and 'sudo make install'.  The QTDIR environment variable and 
the source paths (QtInc, QtLib, and QtBin) in Xcode are unchanged. 
You might need to change your PATH from the old setup, but I don't 
think so.

You'll need to use Polyworld.xcodeproj, instead of Polyworld.xcode.

- larryy