Code center > Darwinbots3
2.5 Dimension mode?
Numsgil:
When I say base I don't mean how humans write the numbers. We need to write in base 10 because that's what we know. I mean more how the virtual machine works. If there was a log function, for instance, it's base would be the base of the virtual machine, for instance (not necessarily meaning you couldn't also have a log10 or log2 function, of course).
I strongly considered floating point numbers. But they aren't any more continuous than integers because of machine epsilon (right now memory is 16 bit, so comparing with 32 bits wouldn't be fair. Comparing with half floats would be more fair). Evolution wouldn't care, but I figured that bot makers wouldn't appreciate .1 = .09999998. And they have a weird property that numbers close to 0 have higher precision. So then I thought about fixed point. But that isn't any different from integers in the end. You can just say that a range of +-10000 is the same as +-1 with an epsilon of .0001.
Numsgil:
Having slept on it I do really like the idea of doing +-3599 as the range, and having 3599 memory locations. I like the idea of doing just positive numbers as well. It plays nicely with most commands and sysvars I can think of. The downside is that it doesn't play nicely with sine and cosine, and it could make for some weird flow control (eg: something like if positive then sub else add).
With codules (functions) present you might be able to fake negative numbers, too, by building a series of functions to manipulate values, and use the boolean stack to store sign information.
jknilinux:
To make the movement more analog, we could add more 2D "planes" to make it 2.75D or 2.9D, etc.... As we keep adding planes, we get closer and closer to true 3D, such as where infinitely many planes = 2.999...D. The problem is that in true 3D, a bot should take up more space than just one plane. Maybe we should implement that possibility?
Or, we could just have values, such as 5000.fixpos = quite well stuck, but a hard enough collision will knock it loose, 10000 = completely stuck, 50 = barely stuck, etc...
Similarly, with 2 planes, value 0 = in plane 1, 5000 = "halfway" between planes (imagine a sphere halfway between two sheets 1" apart, it takes up a small amount of space within each sheet but has most of it's mass inbetween)(this is where we implement weird physics ideas, such as taking up a certain amount of space in both planes, etc...), 10000 = in plane 2. (This is all assuming the values are 0-10000 inclusive)
Also, here's a quick question: Can DB code round up/down for division? For example 11/2 = 5?
Even though it is inexact, it isn't a horrendous issue if one offspring, for example, gets 1 more nrg than the other with offspring_nrg = nrg/2. So maybe this could give the benefit of having divisibility no matter what, like FP? But perhaps there is some application I'm unaware of that requires exact results...
Numsgil:
--- Quote from: jknilinux ---To make the movement more analog, we could add more 2D "planes" to make it 2.75D or 2.9D, etc.... As we keep adding planes, we get closer and closer to true 3D, such as where infinitely many planes = 2.999...D. The problem is that in true 3D, a bot should take up more space than just one plane. Maybe we should implement that possibility?
--- End quote ---
If we wanted, there's nothing stopping us from actually doing 3D. I chose not to because some things are harder to program for in DNA (eyes would be more difficult, for instance) and it would be hard for users to really make heads or tails of what's going on. 2D allows us to match the mental model we have of the microscopic world: large and flat, just like a microscope slide.
So my point is if we asymptotically approach 3D we're better off just going for full 3D. Which isn't something I'm ruling out in the future but not something I think we want to tackle right away.
--- Quote ---Or, we could just have values, such as 5000.fixpos = quite well stuck, but a hard enough collision will knock it loose, 10000 = completely stuck, 50 = barely stuck, etc...
--- End quote ---
That's my plan for something like fixpos, yeah. The details will depend on whether I want to go with drag or friction as the model used to slow things down. But basically it'll involve changing a coefficient.
--- Quote ---Similarly, with 2 planes, value 0 = in plane 1, 5000 = "halfway" between planes (imagine a sphere halfway between two sheets 1" apart, it takes up a small amount of space within each sheet but has most of it's mass inbetween)(this is where we implement weird physics ideas, such as taking up a certain amount of space in both planes, etc...), 10000 = in plane 2. (This is all assuming the values are 0-10000 inclusive)
--- End quote ---
From a technical point of view that's a problem. Which plane do we use to give the bot its sensory readback? And it creates a tight coupling between planes which means you can't distribute planes easily across different computers, etc. Bots need to be discretely in one plane or another for this to really work. Of course this still runs into issues. Imagine a bot trying to switch planes only to find that there's a large shape blocking the way in the new plane. Or even another bot.
--- Quote ---Also, here's a quick question: Can DB code round up/down for division? For example 11/2 = 5?
Even though it is inexact, it isn't a horrendous issue if one offspring, for example, gets 1 more nrg than the other with offspring_nrg = nrg/2. So maybe this could give the benefit of having divisibility no matter what, like FP? But perhaps there is some application I'm unaware of that requires exact results...
--- End quote ---
Most DNA operators in DB3 follow the rounding rules we learned in school (>= 0.5 -> 1, else 0). Division is the exception: it always truncates the result, so that it matches up with mod, which always returns the remainder.
Floating point does not solve this problem, either. Let's say we use 32 bit floating point numbers. That means that there is 23 bits (well, 24 bits denormalized) for mantissa. Ignoring exponent and sign for a moment, that means that we can't represent the difference between, say, 1 and 1 + 2^-25, because they'll both have the same bit pattern in the mantissas. So just in the same way that we can't represent 0.5 in integers, we can't represent 1 + 2^-25 in floating point. We have to round either way.
Floating point has the additional oddity that most fractions can't be represented exactly. The usual ones like 1/3 can't be represented exactly, but we also can't represent something common like 0.1 exactly either. Because the mantissa is base 2. I just absolutely know that if we allow floating point numbers in DNA we'll get someone wondering why 1000.43 1000 sub .43 == is giving false. And I don't want to go down the route of having to code in epsilons in to our DNA code.
Not to mention the equally frustrating problems of NaNs. 0 0 div would produce a NaN. Then every other number it touches, through addition, subtraction, etc. will be NaN. An absolute pain to debug.
See C++ FAQ if you aren't familiar with the pitfalls of float.
Incidentally, double has the same problems, just with higher accuracies.
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...
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version