Working on 2.42.0

[EricL]

I've been working towards a new drop of the VB version.  Will probably show up this weekend or next week.  Here's what I've fixed so far:

Saving and loading settings with field sizes > 8 was broken.  DB saved a long but was trying to load it into an int.  Overflow crash.

Loading a sim from a file now changes all the settings to match the values in the sim.   Allows for easy tweaking without having to manually set everything.

Lots of misc. fit and finish changes in charting.  They update immediatly upon opening, the lines fit in the chart space correctly, resizing charts works correctly, etc.

Chart dialogs now have an "Update "Now" button which will refresh that chart (and that chart only) immediatly without having to wait the built-in 200 cycles for another data point and refresh.  You can ust click away if you want a bunch of data points right now.  (I'm not planning on adding many features on the 2.4 VB fork, but this was easy and I kind of wanted it so I did it.)

Various overflow and stability fixes.

A few other non crashing fit and finish things:  The Mutation rate slider works better, the Edit menu items invoke the options dialog at the right tab setting and so on.

error.sim outlput enablement in the compiled version.

[you]Things I'm still working on that will probably be in the next drop:[/you]
A couple crashing bugs I'm still working on plus any others reported that I can find/fix.
The issue with mutation being off after saving.
A configurable chart update interval.  This is easy enough that I'm goign to just do it.
Internet Organism Sharing  (I want this!)
More fit and finish stuff.  If it pisses me off sufficiently, I will spend time to fix it.

[you]Things I'm working on that probably will NOT be in the next drop:[/you]
Leagues
Locality-based mutation experimentations.  (personal project)

If you have other priorities, let me know.  My philosophy is to drop a release once there is enough in it to justify people moving to it.

-E

[Numsgil]

By charts you mean graphs I assume?

I'm excited.  Graphs have always been something I wanted to spend time working on but could never justify it over other projects.

[Griz]

on the charts/graphs, Eric ...
it seems the colors don't follow the colors assigned to the bots in the
species window, but rather the default VB colors ...
ie ... yellow, red, blue, purple ... and so on in that order.
so if you want you bots to match the chart, you have to ensure
that you assign yellow to the first species, red to the 2nd, and so on.
I haven't been able to find a way to have the charts can use anything
other than those defaults ...
but seeing as you have been playing with them ...
thought I'd throw the idea out.

great work my man ...
I had sorta lost interest ...
as it's no fun when your toys keep breaking. ;)

thanks for all the effort ...
although I don't guess you'd be doing it if you didn't
love playing at this kind of thing.

I'd like to be able to see the code you changed as well ...
so I can go and see what changes you made and how
the fixes work. that's the only way I have of learning this stuff.
so keep good notes, eh? ;)

thanks again.

[Endy]

Kind of a suggestion than anything else but anyways...

Do you think it'd be possible to add the ability to concatenate and de-concatenate numbers? It'd be possible to transmit and store simply massive amounts of info with these relativly simple code additions. I was thinking something based on the number of digits in front of a decon command would be best. Ie:

Code: [Select]

20300 2 decon
Would leave:

Code: [Select]

20
300
on the stack.

[EricL]

Yes, I mean graphs.  They are called charts in the source some places and something spanish in others.  One of these days I'll have to ask who Carlo is (or was).  :)  

I'm not really adding much new functionality to graphing, besides the update interval and update now button.  I'm really just making them look pretty and work correctly though it would be trivial to add new graph types.  If anyone has something specific they want graphed that the program is already maintaining, I could easily add it.  But custom graphs, well, that will have to wait.  Perhaps one day I'll write a perfmon plugin and export tons of counters.  That would give us some cool capabilities on Windows at least.  Custom graphs, graph logging to file, alerts (including email) on thresholds, etc.

Another thing I may do dig in and speed up the data point calculations.  They look to be always performed whether there are graphs up or not and the calculation for every data point is at least O(nm) where n is the number of bots and M is the number of data points in the (oldest) graph!  The number of decendents chart actually calculates this recursivly for every bot for every datapoint for every cycle insetad of just keeping counters!  All this is done even when no graph is up, every 200 cycles by default.  Do this stuff every time the graph gets updated and its at least O(n^3) to draw a full graph!   Update the graph every 10 cycles and the speed imapct is noticable.  Gack!

Yea, having graphs use the bot color has been bugging me too and I've changed it so graph colors match bot colors.  A little more involved then it seems, but not hard.   Another idea I've toyed with is persisting a bot's color and skin in the DNA file...  That way when you load a bot, it always uses a specific color/skin unless you change it.  Could be the beginnig of more sophsicated persistant visual stuff on day...  (I won't do this without seeking input on file formats, etc.)

Griz, some of the things I'm doing have several changes in multiple places in the code.  Somr are form tweaks, some property tweaks, some brand new code and routines.  Everything is commented in the source and I'll try my best, but I probably won't take the time to write up every detail line by line of everything I've done in a readme.

FYI, one good way to teach yourself is just to find a piece of code your interested in and then just step through it.  Set a break point at the top of the routine and then just F8 through it line by line watching what it does.

Cheers,

-E

[EricL]

Do you think it'd be possible to add the ability to concatenate and de-concatenate numbers?

Yes, certainly.  BUT.....

Right now the stuff I'm doing isn't core.  It's UI and bug fixes and trivial little additions and other superficial stuff I can do with the right brain while the left brain watches Stargate.  To be honest, I don't feel, um...  entitled to add new sysvars or impact the core design in any meaningful way just yet.  

So, while it is within my skill set to write the code to do what you suggest, I am going to shy away from doing anything core like this for a few more weeks at which time if all goes well, everything that was supposed to work in the VB version will be working (reliabily) there will be no reason for anyone to run a 3.X version and Nums will be in a position to tell me whether it's worth my while adding new features to the VB fork or cutting over to the C++ code base...  :)

[shvarz]

Shame on you! Carlo Was, Carlo Is and Carlo Will Be forever.

He's the Supreme Being (look in Members) and all who run DBs must worship him (yes, it is in the user agreement).

[Testlund]

Well, what can I say, Eric? Awesome work! All those things have been bugging me too. I can't wait to try the new version!  :boing:

The thing you mension about data point calculation, maybe fixing that will speed up the program!

When it comes to the color graphs I've been using a workaround; the colors are allways assigned to the bots in a certain order, so I've set the colors of the bots close to the colors on the graphs. Works best if you load the graph before you load the sim. Hehe.

This program is starting to rock! :Headbang:

[Numsgil]

Carlo was the original programmer.  He was also italian and liked to code in italian, which caused me no small mess of headaches (and PY before me even more so I'm sure).

He had(has) a fairly good grasp on basic computer science it seems, from various algorithms he's implemented, but I have a feeling based on the original code architecture that it might have been his first large program (it's my first too, so I guess it takes one to know one) as it was incredibly scalable-unfriendly when I first found it (all the code was pretty much in Form1.) and generally had some program flow issues (incredibly dense and long functions for one).

2.4 was as much a code upgrade as a feature upgrade, as I tried to untangle many of the various functions that had been accumulating randomly from various updates.

[EricL]

Well, I stand in awe of the Supreme Being and all others who have come before me on this code base.  Some of the work here is amazing and the amount of hard core math in the code is quite phenominal.  Wish there were more comments and fewer italian varible names, but all and all the code quality is quite high.  That's saying something for a VB project of this size and I think I can perhaps claim some authority on the subject.  I'm making 2.4 work, but really, I'm only completing the last 1% of a job that was 99% complete already.

That said, 2.42 is going to rock.  Besides the fit and finish stuff and small feature tweaks, I've fixed of couple of really nasty core stabilty bugs, one of which was in the core species data structure and was the root of much evil and I hope, most of the overflows people hit in 2.4.  Anyway, I'm 250,000 cycles into a huge sim on my latest build: largest field size possible, lots of mutation, complex bots using posion and venom and shots and ties.  It routinly knocks up against the 5000 bot limit.  I'll drop the release when I get to 1 million cycles and finish one or two more things.  There will no doubt still be some paths that end in overflows, but I hope those will be fringe - canceling file load dialogs and that sort of thing.  I think, I hope 2.42 is going to be very very stable at the core....

-E

[Endy]

How'd you manage 5K? I was having some really oddball effects at about 2000 :sad2:  not to mention it begins running in real time.

[Numsgil]

As a school project I'm implementing an algorithm in the C++ source (which I started in the VB version, which I called "buckets") that should change the core program from an O(n^2) complexity to an O(n) complexity.  Those huge sims should run incredibly faster.

Most of the really complicated math is mine.  I'm a math major you see.  Like the shot decay log function, etc.

Feel free to add comments to the code around any code block you had to spend time figuring out.  I try to add mucho comments but I'm not always as forthright as I should be.

[EricL]

How'd you manage 5K? I was having some really oddball effects at about 2000

I recently bought a new machine.  3Ghz P4 with a Gig of ram (and a totally wicked 24" screen!).  Even on the biggest, slowest sims it seems to stay above 1 cycle per second and just flys with the bot count below 1000.  Haven't seen any really oddball stuff, but I have fixed a lot of things in my fork and also, with the crazy mutation rates I'm using (mostly to test stuff) I may not notice weird stuff anyway...  :)

As a school project I'm implementing an algorithm in the C++ source (which I started in the VB version, which I called "buckets") that should change the core program from an O(n^2) complexity to an O(n) complexity.

 
I've seen some of that in the VB source.  Most execellent sir.  Hashtables are your friend! :clap:

[EricL]

How'd you manage 5K?

Also, I don't like hitting (or having) the artifical bot limit.  This is a problem a lot of programs like this have I.e. how to keep numbers reasonable when there is an abundnace of energy in the sim.  Microsft's Terrarium had the same problem and used "sickness" to randomly kill off bots when populations got too high for the machine to handle simulating in reasonable time.  Of course, when there is no darwinian selection invovled in which bots live or die, it makes evolution difficult...  

I prefer using environmental conditions that increase selective pressures as a mechanism for keeping populations under control and not having any built in limits.  Someday I'll do some work here.  (The current limit of 5000 is a pretty fundemental artifact of the way the VB code is currently written using arrays instead of linked lists or other more dynamic structures.  Changing this would be a major piece of work and this is exactly what Nums is doing in the C++ fork, though the thigns you do for speed, such as using hashtables are not always compatable with the thigns you do for having no upper bounds...)

Anyway, I limit the energy in the system by using a small number (like 4) of really big, high energy veggys that rarely die (start with one in each corner with it's own little starting bot species and you get isolated populations evolving separatly for a time that evlove to stay near their food source but eventually start to venture and come into contact with the other populations once their populations get large enough).  I also raiseg costs on bots so that they die off if they don't eat fairly regularly.   Adding even a small cost to Flow commands will accomplish this well...

[PurpleYouko]

I recently bought a new machine. 3Ghz P4 with a Gig of ram

How did you manage to find a P4 that fast? :blink:
It is my understanding that P4s only go about as high as 2Ghz
Anything faster than that is a newer generation of chipsets such as Sempron or Athlon.
Semprons run from about 2400 up to 3200(nominal speed) or so and Athlons run up to about 4 Ghz