Hmmm, that sounds like a bug I may have caused in doing some cleanup recently.
There's a real gotcha here: if we call Species.setup() too early, it will build the prototypical individual and set it up, and the prototypical individual likely relies on the species' various constraint parameters (genome size, gene information, etc.) to be set up already. BUT if we call Species.setup() late, and set up those parameters first, some of those parameters rely on knowing what kind of individual it is. The proper solution is to move the stuff that needs to know what kind of individual it is (namely inNumericalTypeRange()) AFTER Species.setup, but keep the other stuff before. That'd be some work. So a hack for the moment is that early on we will create a prototypical sacrificial individual that's not been set up but exists solely for inNumericalTypeRange() to be happy. Then we destroy and replace it in Species.setup(). A hack but I THINK it should work fine.
I did a commit -- tell me if this seems to work for you.
On May 27, 2014, at 12:08 PM, Eric Scott <[log in to unmask]> wrote:
> I believe I've encountered a bug in FloatVectorSpecies, using the version in the SVN repository.
> I am trying to use the "species.max_gene.i" syntax to set bounds on individual genes. FloatVectorSpecies.loadParameterForGene always dies with a fatal error, however, because its call to inNumericalTypeRange() on line 527 assumes that Species.i_prototype has been initialized.
> Looking at VectorSpecies.setup(), I see that the prototype is always initialized *after* the calls to loadParameterForGene, thus breaking the gene-specific parameter loading mechanism.
> Ph.D student in Computer Science
> George Mason University