Darwinbots Forum
Code center => Suggestions => Dead-End and Solved Suggestion Requests => Topic started by: Anonomous Guest Person on February 21, 2005, 04:32:48 PM
-
Even though the topic should be enough, I really should still write something here.
So... uh....
Add the mathematical functions to conditions. So we can have:
cond
*25 2 mult *26 !=
start
25 inc
26 inc
stop
-
To make it less confusing for the program to fix overflow errors , thats one the worest things you can do.
To make it less confusing for users to read the dna it will be better that the users become more accustomed that [you]all [/you] the math is done in the execution part of the gene, not in the condition part
now be a good boy and explain why you want to
Add the mathematical functions to conditions
-
"add this darn , it" just because bots-are-us wants to add better "math/array system darn , it" so F#$$ annoying, I wonder if this is one of thouse kids I used to know
I am already crazy because of people like you, YOU WANT ME TO COMPLETLY LOSE IT AND GET LUCKED UP IN A MENTAL INSTITUTION? I BET YOU WONT LEAVE ME ALONE THERE EATHER....
if this does not stop that kid nothing will, then good bye darwin bots for me , better stick to ordanary video game development
-
Hm.
I'd say adding mathematics into conditions is more important then keeping you around.
Erm. I forgot to put in the important part of the post.
Why shouldn't there be mathematics in conditions?
And technically, it'd only be for ease of use, since it's quite possible to do conditions outside of the conditions themselves thanks to the stack system!
-
good say ...
The more you explain why the more I listin to you and agree with you (clue)
easy to use maybe , but hurts processing #1 , #2 differnt styles of programing develop one person will rader do everything into a memory and then send it for condition the other person will write stupedly complex conditions themselfs
I have trouble reading code writtin in a different style
-
Maybe so, but it'll give people more of a reason to learn how the whole stack system works.
Which is a good thing, since knowledge of the stack system results in being able to make really good/efficient bots.
And 'sides, which of the two's more complicated?
cond
*.maxvel 10 sub *.vel >
start
*.maxvel *.vel sub .up store
stop
- or -
cond
start
*.maxvel 10 sub
stop
cond
*.vel >
start
*.maxvel *.vel sub .up store
stop
They both do the same thing, but the first is done through conditional mathematics.
The second, however, can be done in version 2.35.
-
ok ok , if you figure out how that naturaly mutates it will be great
A.G.P. why is assembly not visual basic?
-
Eh. I'll leave that up to a programmer, buahahaa.
Though it shouldn't be too hard, or different.
It might even lead to odd genes, like,
cond
2
3
2
53
>
mult
rnd
1
start
store
stop
As a side note, could we get a COPY function, which basically/technically copies the last stacked object, and puts it into the stack without deleting anything?
[Edit] Oh, it already exists! In the form of DUP. Oops.
-
Eh. I'll leave that up to a programmer, buahahaa.
Well I am a programer and I think its a bad idea , it will make programer's life's harder , you know how mutch stuff they are working on already...
I don’t make the choices I am just writing my believes on the subject...
no I dont like to argue and yes I am good at it...
-
Well, I would help them.
However, I lack any sort of VB compiler. :P
-
You lack a compiler? Perish the thought! ;) Look here (http://www.martin2k.co.uk/forums/index.php?showtopic=541). Can't say how long it will be available, so snatch it up! No MSDN though, but you can always find hep on the internet.
The problem with mathematics in conditions, is, as you say, when mutated bots begin doing more than simple stack manipulation in a cond statement.
Store, inc, and dec should not work in a condition statement. Easy enough fix, but what if this happens?:
cond
56
start
10 store
stop
Bad bad, here's some possible solutions. Tell me which you like better:- Ignore problem and live with it.
- Can't add more values to the stack at the end of a condition than were there to begin with. You can, however, remove values from a stack. So this:
cond
start
56
stop
cond
32 >
start
do stuff...
stop
will work, but this won't (won't increment 25 that is):
cond
56 32 >
25
start
inc
stop
The only bug is when two values are removed and one is added. Then the problem I showed above is still possible.
- All newly placed stack vars are removed at the end of the cond. That is, stack values are removed until the stack reaches values that were there before the cond started.
-
cond
56
start
10 store
stop
Why exactly is this bad? It works this way now without any kind of hitch.
Try running this ultra simple test bot. It just moves forward continuously using a system exactly like the one you describe above.
:D PY :D
-
I don't really see this as a problem. You can make some really good use out of this for programming interesting behaviour.
I would agree that no actions should be taken in the cond. Values in memory cells must not be changed so inc, dec and store should not work there but there is no harm in placing stuff on the stack.
At the moment it isn't possible to use these in the cond at all. (modify my tester bot by moving the store command into the cond to see this)
All we would need to do to perform math in the cond is to allow mathematical operators to work without any kind of memory cell manipulation (store, inc, dec)
:D PY :D
-
This should work now in 2.4. Even though no one has tried running it yet...
Anyway, thought people should know.