RubyNEAT Dashboard

This is a RubyNEAT Plugin to allow you to access RubyNEAT while running to see stats, etc.

Gem Version

Installation

In your Neater project, just include this in your Gemfile

gem 'rubyneat_dashboard'

Usage

localhost:3912

Contributing to RubyNEAT Dashboard

Check out the latest master to make sure the feature hasn’t been implemented or the bug hasn’t been fixed yet.
Check out the issue tracker to make sure someone already hasn’t requested it and/or contributed it.
Fork the project.
Start a feature/bugfix branch.
Commit and push until you are happy with your contribution.
Make sure to add tests for it. This is important so I don’t break it in a future version unintentionally.
Please try not to mess with the Rakefile, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.

Copyright

Internal Documentation

This section is meant for those who might want to fork and modify RubyNEAT Dashboard for their own purposes. More importantly, it reprents my own notes of what I did and what internal standards I set for myelf in the code. I make no promises here, as this is basically my own scratchpad. That which is more formalized shall find itself migrating above this section. :D

Current Plans

I want to create visulaizations of the populations and critters, including the ability to interact with a critter, that is to say being able to manipulate its input layer to see what its output layer does, as well as the hidden activations.

We also need to work on a way to do persistence of these critters. Currently, there is no persistence to speak of, nor is there a clean way to save the results. All of this remains highly experimental at the moment.

Also with persistence comes the means to extract the most fit critters so that they can be used in production. Ideally, there should be some means to do continuous updates. We should be able to churn out standalone code in “any” language, as well as having a minimal engine to run them directly.

D3 Directive Conventions

Becuse I expect there to be a large number of directives defined here, especially for the many D3-based charts I intend to add, I have decided on a naming convention up-front.

Since the organization of the Dashboard will be into various sections, I will try to roughly reflect that here, though it is not set in concrete. For instance, <population-progress-chart> may, of course, be used elsewhere besides the Population section of the Dashboard.

Firstly, most, if not all D3 directives are meant to be dynamic. As such, they will need something to set their data source. The details are yet to be firmed up, and I will firm them up as I move along here. But every effort will be used to avoid hard-coded data sources unless it makes sense. At worse, there may be a default datasource that can be overriden.

Naming Conventions (work ib progress)

Basically, the naming convention shall be:

<sectionname-functionalityname-typename>

For example,

<population-progress-chart>

which will, of course represent the progress of evolution of the population. In this specific case, the datasource shall have a default, but can be set to something else. Currently, there is only one datasource, but that is expected to change down the road.

Some directives may be graphical displays that are not charts, such as the topology of a critter. In that case, the directive would be:

<critter-genotype-topology>

<critter-phenotype-topology>

Which represent 2 diffrent ways of looking at the topology of a critter. The former would simply be a list of connections and their innovation numbers, the latter would actually be a connected graph of the neurons and perhaps their weights.

Active Directives

They are most likely still under development, but you can see them now.

<population-progress-chart>

Upcoming Directives

<population-bridage>
<population-window>
<critter-sandbox>
<critter-ice>

Defunkt Directives that may be deleted

<critter-genotype-topology>
<critter-phenotype-topology>