Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Numsgil

Pages: 1 2 3 [4] 5 6 ... 510
46
Newbie / Re: Where can I find the latest source code (ver 2.48.32)?
« on: May 06, 2017, 06:15:46 AM »
Oh wait, no, scratch that, it's in there I think, at least up to 2.48.32.

It's under SVN control.  The repository lives here.

47
Newbie / Re: Where can I find the latest source code (ver 2.48.32)?
« on: May 06, 2017, 06:12:35 AM »
Looks like Botsareus hasn't been updating the repository with any of his recent changes.  You might shoot him a personal message and ask him to do that.

48
Newbie / Re: Hi
« on: May 06, 2017, 06:08:40 AM »
Yes, I'm doing active development on a next version.  I recently dropped a sort of preview thing here.

If you know/can learn C#, I'm sure I could give you some tasks you'd find interesting.  Information on getting the source code up and running is found here.

If you know Visual Basic 6, you could play around in the current version.  In some ways it's an easier codebase to figure out and modify, but it's also pretty easy to break stuff without knowing since it's not really tested.  Its SVN is here.

49
Suggestions / Re: GPGPU acceleration?
« on: May 01, 2017, 06:46:58 AM »
Why would that be easier for a GPU than DNA as it is? If the node code can mutate, wouldn't you run into the same problem of divergence?

Yeah I guess you're right.

50
Suggestions / Re: GPGPU acceleration?
« on: April 30, 2017, 12:22:01 PM »
So there would be a fixed set of these node functions that, arranged in different tree structures, produce different bot behaviours? With a pre-written kernel for each function?

I was thinking more that the code in a node could change but all bots in a species would share the tree structure and code so you could go wide that way, but using preset nodes works, too.

51
Darwinbots3 / Re: Bot testbed
« on: April 30, 2017, 12:14:29 PM »
Thanks, yeah, it's a bug I know about and on my todo list.  When you resume, the program loses the DirectX context and there's nothing to catch that and reset it.

52
Suggestions / Re: GPGPU acceleration?
« on: April 28, 2017, 08:46:07 PM »
I guess you're probably right. I was thinking that if 90% of the bots have very similar DNA and are doing exactly the same activity, there would be very little divergence and it would effectively be SIMD.  I'd still like to make a prototype, maybe with some minimal language rather than DNA, so I can compare the performance with that on a CPU.

I don't think it's impossible with a bit of ingenuity to come up with something, but it's a bit awkward.  At their core, bots have 1000 inputs (their memory) and 1000 outputs (their memory after storing stuff in to it).  GPUs don't really like mapping inputs to outputs in the large scale like that.  They tend to be more comfortable mapping a small fixed number of inputs to 1 output over and over in parallel, and doing multiple passes if they need to.

One idea: I could imagine a DNA language built around the idea of smaller DNA programs feeding to each other.  Like, imagine a neural network, but instead of a sum and logistic function each node is a small program.  If each small program had 16 inputs, say, and a single output that fed on to the next layer of nodes, each node could be executed massively in parallel using the GPUs quite nicely.  I don't know if this would be even remotely efficient, but it would sort of map to how the hardware works at least.

53
Darwinbots3 / Re: Bot testbed
« on: April 28, 2017, 08:20:35 PM »
Loops don't get decompressed.  There's no mechanism in the DNA to do it, and even if there were, the loop counter is just an integer on the stack and can't be deduced necessarily from a static analysis of a DNA program.

For your example, there are two codules for robot A:

'Main' codule:
3 1 loop

'Codule 1:
a b c d

Likewise for robot B there are two codules:

'Main' codule:
4 1 loop

'Codule 1:
a b z d

Let's say that the main codules and the ones in slot 1 get matched together.  I've marked where they have subsequences in common with ^:

Code: [Select]
3 1 loop
4 1 loop
  ^ ^

a b c d
a b z d
^ ^   ^

In effect any crossover events here would just swap codules between the two different DNA programs.  So in addition to basically having no effect, it's also possible for it to end effectively as:

4 { a b c d } loop

and

3 { a b z d } loop

54
Darwinbots3 / Re: Bot testbed
« on: April 28, 2017, 02:05:30 PM »
Also a question, how will sexrepro actually work? (sorry for asking the same question more than one time :)
Basically if you have stuff like { } and loop does the instruction set get decompressed first or is { } and loop treated as symbols to crossover?

{} mark the boundaries of codules.  The codules get matched up based on longest common subsequences, and crossover events happen in the matched up subsequences.  "loop" is just a command so it gets treated the same as other commands.  But there are details that aren't finalized yet here.

And of course, the physics of actually splitting the bots in two is also not really finalized yet.

55
Suggestions / Re: GPGPU acceleration?
« on: April 28, 2017, 05:58:10 AM »
Problem is GPUs only benefit when they can do the same operation (add, multiply, etc.) in parallel.  Even if you put the DNA on the GPUs somehow, you still can't execute more than one DNA program at a time.

It's a problem of SIMD vs. MIMD.  GPUs need SIMD to overcome the additional cost of transferring the data to/from the GPU and starting up a processing batch, but most of Darwinbots is either SISD or MIMD.  The DNA execution is MIMD, certainly.  The physics has passes of MIMD but then everything bottlenecks in places through a SISD section.  In that sort of problem, CPUs are still king.

56
Darwinbots3 / Re: Bot testbed
« on: April 27, 2017, 05:29:36 PM »
Looks good but I think shadowgod still has you beat :)

If you can figure out under which circumstances it bugs out that would be good.  It's possible it's a bug in the program that I should fix.

57
Suggestions / Re: GPGPU acceleration?
« on: April 27, 2017, 05:16:27 PM »
Executing the DNA isn't really well suited for GPUs, unfortunately, since each bot has to run its own DNA on its own data.  Getting the physics to execute on GPUs is possible in principle but rarely done in practice.  Probably only shots are really suited for GPU calculations, but we just don't have enough shots in a typical sim to outweigh the upfront CPU cost of transferring things to/from the GPU.

58
Yes, I think it's a reasonable approach and yes, it was one of the plans for a while.  It needs server side support, either PHP or python or whatever, and I'm not really a web programmer so I didn't know how to do that.
 There's also security concerns and I'm not enough of a web programmer or linux guy to know what is or isn't a good idea here.  I'd want to jail the custom server side code as much as possible so it can't break things and can't be used as an entry point to attack the server.

59
Darwinbots3 / Re: Bot testbed
« on: April 12, 2017, 08:03:16 AM »
Where'd 9600 come from?
Anyway, 9000 seems a pretty nice value.

Okay, I might just go with 9000, even though I think 9600 is better in a lot of ways, since 9000 is both a round number and evenly divided by 360, which should make math easier for humans.

In terms of where they come from: the prime factors help to determine how many different ways you can divide up the full circle evenly.  3, 4, and 6 are important, since triangles, squares, and hexagons form a full tesselation of the plane, and are the only regular shapes to do so, so you need some multiple of 12 at least (the lowest common multiple of 3, 4, and 6).

If you ever wondered why there's 360 degrees in a circle, it's because it's the closest round number to 365 in base 60 (which was the base the Sumerians used thousands of years ago).  Their number system was base 60 because it makes math easy: 60 divides cleanly in to all sorts of different divisors.  For Darwinbots, we have a similar requirement.  The more ways there are to divide the circle in to even parts, the more different symmetries are possible, or at least easy.  The prime factors show you the raw ingredients to combine to divide the circle up.

2 is an important prime factor, because splitting things in to halves, or quarters, or sixteenths, etc. are very natural ways to break things apart, and can easily mimic the way cells in biology cleave in half during reproduction.  3 is important, but multiple copies of 3 aren't so much: being able to split things in to thirds and being able to represent 30, 45, and 60 degrees is important, but being able to represent 40 degrees or divide things in to 9ths isn't very important.

Sunweaver is sort of built to be base 10, to make math easy for humans, so 5 is an important factor in so far as 10 is.

But 7 isn't an important factor.  It would let you split circles in to 7ths, but there probably isn't much call for that.    As the prime factors get larger, they become less useful.  About the only use 101 would be for is if the bot had 101 segments.  Otherwise there's not much call for splitting a circle evenly in to 101 pieces.

So generally speaking finding a good number is balancing the needs for 2, 3, and 5 as prime factors, taking up as much of the [0,9999] range as possible, and making it easy for humans to do the math.

60
Darwinbots3 / Re: Bot testbed
« on: April 10, 2017, 05:47:23 PM »
They take units in whatever forms a full circle (as of this moment, that'd be 1080), and convert them in to degrees (so in this case, divide the values by 3), then run sin/cos on them.  Normally the results of sin and cos are in the range [-1, 1], but they get scaled so it's easier to make use of them, up to [-1080, 1080].

So for example, 90 degrees would be 360 units in Sunweaver.  Sine of 90 degrees is 1.0, so 360 sin would return 1080.

Pages: 1 2 3 [4] 5 6 ... 510