Darwinbots Forum
Code center => Darwinbots3 => Topic started by: Botsareus on October 09, 2007, 02:05:29 PM
-
also will make v3 support desimals in the stack and the following commands:
round ' round to n desimal places
ipart 'integer part
fpart 'fraction part
^ ' to the power of
50 * 'memory location at 50
int 'same as in vb
fix 'same as in vb
nl 'natural log nl(10^3) / nl(10) = 3
e 'nl(e) = 1 e = 2.718...
pi = 3.142...
sin
cos
tan
atn 'reverse of tan
1. Floating point errors are a pain to debug.
Not really , I will use int or round or fix when ever nessisary, and the only trouble will be divide, but even then I can just write:
a b div
if b < 1/32000 then 32000 = ans
-
For starters, read this FAQ (http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.15) articles 15 through 18. Properly using floating point numbers is a delicate art, and I don't have the skill to create a robust DNA system from it. If someone wants to create a system on paper for dealing with floats, I'll consider maybe moving to a floating point system, but probably not.
Second, read the command list (http://www.darwinbots.com/Forum/index.php?showtopic=2207), and the rest of the post. How do I know you haven't?
1. sin and atan already exist.
2. 32000 isn't a special number in the new system. The new "magic" number is 9999 (that's 4 nines, ie: you get 4 digits of precision in base 10 when storing in robot DNA).
Last, if anyone could ever come up with a gene that was seriously impossible to do without floating point math, I would also reconsider floating point numbers. Note, though, that with 9 digits of precision on the stack, you can implement your own fixed point math. Just multiply all your "fractions" by like 100 or 1000.
-
Numsgil I found a compromize. I will post it within the next 2 weeks.
-
Isn't it already possible to emulate a floating point stack for small numbers? All you have to do is scale it up by, say, 100, and then before you use it divide by 100. This way, at least, you can get a higher accuracy for division operations.
-
What you describe is called "fixed point" (as opposed to floating point). It is indeed already possible, but it is a little cumbersome. I could maybe be convinced to work towards a system that automagically handles the multiply and division that comes along with fixed point math, if people have an interest.
-
Sounds good. But if too much trouble forget about it... I realise what Numsgil means when he says that the desimal math is a pain in the a$$...
-
Idea!
It might be easeir for both programmers, bot authors and DB if we supported decimals only as results in functions, we could use Sig Figs to round decimals up to a point easily used for aomparisons, say a sig fig limit of 3 numbers, so no matter what, the conditionals only use at best a y.xx number, or a yxx number depending on how we set it. I say use sig figs only for decimals that go beyond two places; you can still acurately calculate things, but could only compare the more relevant numbers, and since it would be Sig Fig, numbers such as 0.0000000000054 would still show up, only in as 5.4 or 0.54. Doing so, it might be wise to add a sysvar that returns the exponent for Scientific Notation, this could be usefull for decoding purposes, but yes I think this is how most biology handles so called floating numbers. Some insignificant numbers just aren't worth calculating, and it can be hard to identify repeating numbers which are better exspressed as some number over another I.e. .27272727272 = 27/99 so maybe instead of even using decimals, we switch to fractionals, as they are not decimals in form, and both numbers can be used for seperate functions.
-
People can easily look at a fraction and say Okay, that's 5/9 or something like that. The problem is putting it into code.
I found a link which might help this along, although I don't completely understand it myself:
DEC2FRAC.pdf (http://homepage.smc.edu/kennedy_john/DEC2FRAC.PDF)
-
We could maybe implement the idea of rational numbers. Basically just define the stack as operating with some m/n where m and n are integers. We'd need to do a range check to make sure that all the operations (add, sub, mult, div, etc. etc.) produce good results over the given range. If after an arbitrary number of operations the rational numerator and denominator are so large that they overflow the integer math, that's not any better than using floating points.
-
Yeah it would need limitations based on the programming.
-
How about something more simple:
Just round each number to the 5th or the 4th decimal place. This way stuff like 1/0.001 will be in range...
Less pain, although small numbers will be reset to 0.
-
I've been thinking about that too. The upside is that it would allow things like sqr to return more interesting results. But in the end it isn't much different from the integer stack. So I think it's probably the most realistic option. I could be persuaded, I think.
-
I've been thinking about that too. The upside is that it would allow things like sqr to return more interesting results. But in the end it isn't much different from the integer stack. So I think it's probably the most realistic option. I could be persuaded, I think.
Side note: I'd rather have an x^y operator which allows fractions in y than a sqr operator. (Since the square root of x is x^(1/2), and the cube root of x is x^(1/3), etc)
-
What if I just give you a cube root operation?
BTW, I think there's a way to get at a cube root using square root. Wikipedia had this on the cube root (http://en.wikipedia.org/wiki/Cube_root) page for a calculator:
* Press the square root button twice.
* Press the multiplication button.
* Press the square root button twice.
* Press the multiplication button.
* Press the square root button four times.
* Press the multiplication button.
* Press the square root button eight times.
* Press the multiplication button...
Maybe it would work in DNA, too.
-
Well, here it is. It took me way too long make, so I hope it helps. If not, at least I've proven it can be done. It's accuracy varies quite a bit. I haven't done extensive testing on it's limits etc.
It takes the first number (20) and approximates it's cube root and stores it in 61. It displays 3 decimals. Ie. for 1331 (11^3) it gives 10882 (as opposed to 11000) and for 20 it gives 2693 (should be 2714).
20
10000 mult sqr
10000 mult sqr
dup
10 mult sqr
10000 mult sqr
mult 1000 div dup
10 mult sqr
10000 mult sqr
10 mult sqr
10000 mult sqr
mult 1000 div 61 store
-
Ooo, nice. (I looked at http://www.mathpath.org/Algor/cuberoot/algor.cube.root.htm (http://www.mathpath.org/Algor/cuberoot/algor.cube.root.htm) earlier, which has a different method, but I didn't attempt to implement it)