Code center > Darwinbots3
2.5 Dimension mode?
Numsgil:
--- Quote from: jknilinux ---Alright, well maybe analog dimension-switching isn't going to work out so well...
Evolution should be able to deal with a digitized implementation, such as if .dimension is divisible by 2, be in slate 1, else slate 2. Besides, there's lots of digitization in nature anyway...
--- End quote ---
From our experience in DB2, sysvars that don't use the entire domain are unlikely to be used by evolution. So then you could make it a positive/negative distinction, if you wanted, but that lacks a certain "elegance" that I've been trying to push on to DB3 DNA. But I might be kidding myself that all sysvars can be meaningfully mapped to a continuous range. Some sysvars might just need to be discrete by nature. Maybe some sort of bool memory range...
In nature, on an essentially molecular level things are more or less discrete. A proton pump will pump one proton per pump. But even by the time you get to the cellular level the vast numbers of discrete processes have made biological behavior essentially continuous. Thousands of proton pumps pumping at varying rates creates a continuum.
The core problem is that if you want to do something like discrete read only sysvars (say, *isfixed) and use that to influence continuous output sysvars (if not fixed, then store values to up), you invariably introduce some very crude math or branching behavior.
One idea I'm kind of playing with right now is overloading the sign bit for digital data. I already sort of do it for the sqr command, for instance (sqr operates only on the value component of the value on the stack. It's basically sign(val) * sqrt(abs(val)) ). So then maybe purely digital data could be represented as +-0. But I'm not all that happy about overloading the meaning of the sign bit like that. The fact that there's a sign bit at all kind of rubs me the wrong way. I probably need to look at more microprocessor designs and get some ideas.
--- Quote ---Anyway, to avoid obstacles while dimension-switching... could we implement a sort-of 3d vision system, with 1 eye pointing above and the other pointing below the plane the organism is on? That way, it can detect if there is an organism/object "above" it, and if it tries to teleport when something is above/below it anyway, it just won't be able to.
--- End quote ---
I'll need to think about this a bit more to figure out a good plan. Something like flOw maybe. Where you can get an idea of what's going on in different layers without an exact idea.
ikke:
If you want easy divisibility as a criterion use the following algorithm to define your max number
1) establish the highest prime you want your base to be divisible by
2) decrease the number by 1.
if the number is the highest order of a prime myltiply ense move on to the next lower number
example
I want a number to be divisible by 11
next is 10 10 is not the highest order of a prime so next
9=3^2 so include
8=2^3 so include
7=7^1 so include
6 next
5=5^1 so include
4=2^2 not highest order of 2 so next
3=3^1 so next
2=2^1 so next
11*9*8*7*5 is your number (=27720)
Moonfisher:
Actualy the "fuzzy logics" kinda idea sounds interesting. Things probably aren't as black and white in nature...
And I definately think introducing ranges for the sysvars will help a lot. It's hard for evolution to hit -6 .shoot store... best I've seen is .shoot inc.
And I think I've seen some who used math to push a value into .shoot, but then it also fires energy shots and such. -1 and -2 are one step from eachother, a bot is just as likely to kill itself as it is to feed.
abyaly:
Yeah. Shoot should not end up as a wacky batch purpose variable like it did in DB2.
Info shots, energy shots, feeding shots, and killing shots are all fundamentally different things.
Numsgil:
--- Quote from: ikke ---If you want easy divisibility as a criterion use the following algorithm to define your max number
1) establish the highest prime you want your base to be divisible by
2) decrease the number by 1.
if the number is the highest order of a prime myltiply ense move on to the next lower number
example
I want a number to be divisible by 11
next is 10 10 is not the highest order of a prime so next
9=3^2 so include
8=2^3 so include
7=7^1 so include
6 next
5=5^1 so include
4=2^2 not highest order of 2 so next
3=3^1 so next
2=2^1 so next
11*9*8*7*5 is your number (=27720)
--- End quote ---
The numbers get big really, really fast, which is sort of unfortunate. 27720 is a bit larger than I want. It doesn't quite fit in a 16 bit signed integer and that would be a lot of sysvars
Removing 11 and doing 9*8*7*5 = 2520 would be more manageable. The upshot over 3600 is that it's divisible by 7. The downside is that 3600 maps better to degrees, so 90 degrees, 45 degrees, maps to 900 and 450 with 3600, instead of 630 and 315 for 2520.
Sort of torn, actually. Assuming we do integers, which would people prefer?
--- Quote from: Moonfisher ---Actualy the "fuzzy logics" kinda idea sounds interesting. Things probably aren't as black and white in nature...
And I definately think introducing ranges for the sysvars will help a lot. It's hard for evolution to hit -6 .shoot store... best I've seen is .shoot inc.
And I think I've seen some who used math to push a value into .shoot, but then it also fires energy shots and such. -1 and -2 are one step from eachother, a bot is just as likely to kill itself as it is to feed.
--- End quote ---
--- Quote from: abyaly ---Yeah. Shoot should not end up as a wacky batch purpose variable like it did in DB2.
Info shots, energy shots, feeding shots, and killing shots are all fundamentally different things.
--- End quote ---
That's the prime example of what I want to avoid for DB3. .shoot involved "magic" numbers. And even if you try to level the playing field by modding the value so it takes -6, -16, -26, etc. it's still a real pain. For DB3 I'll break each shot type into its own sysvar and the values the sysvars hold will represent .shootval instead.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version