Code center > Darwinbots3
2.5 Dimension mode?
jknilinux:
Here's the official thread for the 2.5D mode suggestion.
Here's my first mention from a previous thread:
--- Quote ---Also, can we implement some sort of 2.5D mode, so it (DB3) won't actually have to deal with 3D graphics? Maybe a memory location that, if set to 1, brings the bot to a parallel 2D sim, moving it slightly in the 3rd dimension, where things in each 2D level can only interact with that which is in their level. It can switch back to 0 if it wants to return to the original one. Maybe we can implement each 2D sim in this mode on a different core/computer? on second thought, this would be a great way to induce speciation by setting slightly different physics to each parallel 2D plane... Perhaps we can use this as an alternative to the roving teleporter option too for IM?
--- End quote ---
So, add your thoughts here!
Numsgil:
It's an interesting idea, but I don't want to control it discretely inside the DNA. My thinking with DNA is that we do away with "magic numbers" and have the entire -1000 to 1000 values of a memory location be meaningful, and that the ("phenotype") behavior that those memory locations map continuously.
So for example with .up, if you do 10 .up vs. 20 .up, the end behavior is very similar. Whereas with something like .fixpos, it was inherently discontinuous (either fixed or not fixed), and originally even dealt with magic numbers (0 vs. 1).
So I'd be inclined to have moving between layers only indirectly be controlled from DNA. Maybe something similar to "buoyancy".
abyaly:
Why are the memory values being restricted to the range of +- 1000? It seems like it would be easier to let them take up all of the variable's values.
Also, I don't think you meant continuous there, since .fixpos is a continuous map.
Numsgil:
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?).
abyaly:
How does a base 10 representation mean that the upper limit should be a power of 10?
We can still write the numbers in base 10 even if some strange number like 32768 is the cap.
Divisibility, though, is an argument I can stand behind. Having a number with very many divisors does make things pretty nice, but it's only a necessary concern if we are still going to restrict memory values to integers.
In the interest of making bot controls as close to analog as possible, floating point numbers have an advantage. Earlier I mentioned that .fixpos was a continuous function... this is because it has a discrete domain, just like .up does in the current implementation. All such functions are trivially continuous. The jump from (0 .up) to (1 .up) is just as arbitrary as the jump from (0.fixpos) to (1 .fixpos).
Navigation
[0] Message Index
[#] Next page
Go to full version