I misspoke about it being 1000. It's actually 10000. Here's the reasoning:
1. DNA for DB3 is base 10. Evolution doesn't really care what base the underlying system is in and base 10 is easier for us humans to read and understand. So there's no bit shifting or ANDing and the like. Everything's set up as if it were in base 10 (underlying representation isn't, necessarily, though)
2. I wanted to be able to store the value in a 16 bit integer (so it had to be < 16000)
3. The number should be nice and round to remember. ie: some power of 10. (so it had to be 1, 10, 100, 1000, or 10000)
4. I wanted to be able to store essentially pointers to other memory locations. So it had to be at least 1000. (that meant 1000 or 10000)
5. I wanted it to be +-1000, but for angles, 1080 is the nearest number to 1000 that still has nice division properties (360*3 = 1080. 1080 has numerous ways to evenly divide it up).
So 10000 was the only cap that fulfilled all properties.
...
Though I wrote the DNA module several years ago, so I might want to rethink some of the underlying assumptions before a first release.
Specifically, 1080 might be a better cap. I'd probably expand it to each bot having 1080 memory locations as well. Maybe just generally expand things as if it were a base 60 number system.
For the uninitiated, a little history lesson might be illustrative. Has anyone ever wondered why there are 360 degrees for a circle? Why not 100, or 1000? The answer is that it was roughly equal to the number of days in a year (early math was astronomy based) and it's a nice round number in base 60, which is what most early number systems were based on.
See wiki. Why base 60? Because it is an extremely composite number system. Meaning it has lots of ways to evenly fraction numbers. We still use base 60 for time (60 seconds in a minute fractions up really nicely).
...
Or maybe go for broke and fully do base 60. Have 60^2 - 1 = 3599 memory locations (0 is special). Have them each hold a value between -3599 and 3599 (two digits base 60, with an extra bit for sign).
It would be
really weird. I don't think there are any base 60 based computer languages But it would make doing things like evenly dividing up the memory locations and converting from linear to angular units easier. sine, for instance, could operate on a domain of -3600 to 3600, or the full 3600 decidegree circle forwards and back. And then output values normalized to the -3600, 3600 range. If you want to reproduce 60/40 with a kid you can do that. But more exotic fractions are equally meaningful.
Or I might even decide to lop of negative numbers. Just do 0..3599 as the entire range and domain of all operations. Negative numbers tend to cause problems because not all things make sense to go negative (negative nrg?).