Code center > Darwinbots3
2.5 Dimension mode?
jknilinux:
--- Quote from: Numsgil ---Sort of torn, actually. Assuming we do integers, which would people prefer?
--- End quote ---
Personally, I'd prefer whatever is better for mutations, since DB's main goal is making mutation sims. That's just me though.
ikke:
--- Quote from: Numsgil ---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
--- End quote ---
8 (2^3) is included so you can halve the number without taking a larger hit than losing divisibility by 8 and fit it in 16 bit
--- Quote from: Numsgil ---Sort of torn, actually. Assuming we do integers, which would people prefer?
--- End quote ---
I am unclear as to the scope of what we are discussing. Is everything going to be limited to this number (body, speed etc)?
Two comments:
1) an element not included in the discussion is resolution. Do 3600 or 2520 have adequate resolution? Or do we want to be able to have finer increments and or more distinct categories? In that case just multiply by a subset of underlying primes. Smaller and more primes are better I guess, so prefer 4 (2^2) or 6 (2*3 ) over 5.
2) As fas as the 3600 vs 2520 discussion it is important to note that divisibility by al large number of integers is nice, but not all integers are equally relevant. With nine eyes divisiblility by 9 is more relevant than 8, 10 or 11. I can imagine other relevant integers. Aside from that, 360 (or 3600) is as arbitrary as 2520. The advantage of the 360 base is that is is better known and therefore more easily recognised. 2520 would require clear documentation to make people aware.
--- Quote from: Numsgil ---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.
--- End quote ---
Sounds good.
Going of in (yet) another direction: one of the other avenues is making db3 more biological. Is this abandoned, and if it is not, do the different shoot still have their relevance? I can imagine .eat being relevant for an amoeba scale bot, more than body shots.
abyaly:
If we make the cap one less than a prime number, the variable range with the rollover becomes a finite field
In case that matters.
Numsgil:
--- Quote from: ikke ---
--- Quote from: Numsgil ---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
--- End quote ---
8 (2^3) is included so you can halve the number without taking a larger hit than losing divisibility by 8 and fit it in 16 bit
--- End quote ---
Except that divisibility by 8 is important for angles. Without it, you cant express something like 45 degrees exactly.
--- Quote ---
--- Quote from: Numsgil ---Sort of torn, actually. Assuming we do integers, which would people prefer?
--- End quote ---
I am unclear as to the scope of what we are discussing. Is everything going to be limited to this number (body, speed etc)?
--- End quote ---
It'll be the range of sysvars, and probably also the number of sysvars. Numbers on the stack, though, will have a higher precision.
--- Quote ---Two comments:
1) an element not included in the discussion is resolution. Do 3600 or 2520 have adequate resolution? Or do we want to be able to have finer increments and or more distinct categories? In that case just multiply by a subset of underlying primes. Smaller and more primes are better I guess, so prefer 4 (2^2) or 6 (2*3 ) over 5.
--- End quote ---
I think once you get to about a 1000 you have sufficient resolution. I can't think of a reason you'd want more just for resolution's sake.
--- Quote ---2) As fas as the 3600 vs 2520 discussion it is important to note that divisibility by al large number of integers is nice, but not all integers are equally relevant. With nine eyes divisiblility by 9 is more relevant than 8, 10 or 11. I can imagine other relevant integers. Aside from that, 360 (or 3600) is as arbitrary as 2520. The advantage of the 360 base is that is is better known and therefore more easily recognised. 2520 would require clear documentation to make people aware.
--- End quote ---
Eyes probably won't work like in DB2, btw (it'll work more like a camera obscura, with angular ranges that a bot can set to be either rods or cones). But it's a good point. For 3600, I'd choose probably 60 when it was an issue. 60 ins, 60 outs, 60 racial memory slots, etc. For 2520 it's less clear.
--- Quote ---Going of in (yet) another direction: one of the other avenues is making db3 more biological. Is this abandoned, and if it is not, do the different shoot still have their relevance? I can imagine .eat being relevant for an amoeba scale bot, more than body shots.
--- End quote ---
There's just going to be one offensive shot type, and it works to kill the opponent more than eat him. Then you swallow the enemy whole. There's a thread somewhere in the DB3 subforum where I explain what I'm thinking.
--- Quote from: abyaly ---If we make the cap one less than a prime number, the variable range with the rollover becomes a finite field
In case that matters.
--- End quote ---
Well, 2520 is one less than 2521, which is a prime. Does that count the domain [0, 2520] or [-2520, 2520]?
abyaly:
--- Quote from: Numsgil ---
--- Quote from: abyaly ---If we make the cap one less than a prime number, the variable range with the rollover becomes a finite field
In case that matters.
--- End quote ---
Well, 2520 is one less than 2521, which is a prime. Does that count the domain [0, 2520] or [-2520, 2520]?
--- End quote ---
[0, 2520]
I can't think of a good reason we should care whether it makes a field or not, though.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version