Cellular automata, WinCA application VIII
This is the last article of the series dedicated to the WinCA application. This application allows the edition and to execution of cellular automata. To finish, I will review the code that implements the automaton itself, using all the classes and interfaces explained in the previous articles.
Here you can find the first article of the series about WinCA application.
In this link you can download the WinCA application executables, and in this other one you can download the source code of the WinCA solution, written in CSharp with Visual Studio 2015.
Automaton control
In the WinCA application, the cellular automata are a network of cells that can have any spatial distribution and can be freely interconnected between them. This distribution and interconnection is determined by the class that implements the automaton, which must implement the ICANetwork interface, defined in the Interfaces namespace of the CellularAutomata class library as follows:
public interface ICANetwork : IValueProvider
{
ICAOptimizer Optimizer { get; set; }
ICAStateProvider StateProvider { get; set; }
IPropertyProvider VariableProvider { get; set; }
ICACellProvider CellProvider { get; set; }
Bitmap ActualImage { get; }
Control Editor { get; }
int ActualStep { get; }
void ConfigureToolBar(ToolStrip tb, int ix, bool remove);
void Initialize();
Bitmap Reset();
Bitmap Step();
Bitmap ZoomIn();
Bitmap ZoomOut();
}
This interface inherits the members of IValueProvider, in order to provide data to the state change expressions, as I showed in the previous article in the series. It also specifies the following properties and methods:
- Optimizer: In this property you can provide an ICAOptimizer class to optimize the execution of the automaton.
- StateProvider, CellProvider, and VariableProvider: These properties provide objects that are used to build the states, cells, and variables of the automaton.
- ActualImage: This property gets the image of the automaton in its current state.
- Editor: With this property you can get a control that allows editing the neighborhood of the automaton cells. It is used in the forms with which the automaton is edited.
- ActualStep: This property provides the number of the current step of the automaton.
- ConfigureToolBar: This method is used by the automaton editing and execution forms to configure the non-standard automaton controls in the toolbar of the form. In the tb parameter you must pass the toolbar to configure, ix is the index for the first control of the automaton and remove indicates if you want to create the controls or delete them.
- Initialize: This method is used to initialize the automaton.
- Reset: Returns the automaton to step 0.
- Step: With this method the automaton advances one step forward.
- ZoomIn and ZoomOut: Control the size of the pixels of the Bitmap with the image of the automaton.
In the WinCA application I have implemented two different automaton classes, in the Automata namespace of the CellularAutomata class library. The Linear1DCA class is a single-dimension automaton, with cells arranged in a line. The Grid2DCA class is a two-dimensional automaton, with the cells arranged in a rectangular grid.
In the Controls namespace of the CellularAutomata class library are the controls used to edit the neighborhood of the cells of these two types of automaton. Linear1DCAEditor allows you to edit the cell neighborhood of a Linear1DCA automaton, while Grid2DCAEditor is used by the Grid2DCA class to edit the cell neighborhood of two-dimensional automata. In case of implementing another different type of automaton, it will also be required to implement an appropriate editor to edit the neighborhood of their cells. As these controls are for internal use of the automaton, there are no restrictions for its implementation.
The GridEditor form, in the same namespace, is also for internal use of these two types of automaton. One of the controls you add to the editor toolbar is a button to set the initial state of the automaton. Since the two automata follow a rectangular pattern, they can use the same initial state editor, one has only one line and the other has more than one, but for the rest they are the same. Again, there is not any restriction for this. In fact, it is not mandatory for an automaton to provide an UI initialization service, so this dialog box is tailor made for these two classes and does not follow any pre-set rules.
Editing and running the automaton
The form that implements the editing and execution of the automata in the WinCA application is frmAutomata, in the Forms namespace of this application. It implements the ICAManager interface, in the Interfaces namespace, also in this application, defined as follows:
public interface ICAManager
{
ICAStateManager StateManager { get; set; }
ICAStateProvider StateProvider { get; }
ICANetwork Automata { get; }
IMainForm MainForm { get; set; }
}
This interface simply defines the links with the main application window, MainForm, and with the form that controls the states editing, StateManager, and provides the object that implements the selected automaton in Automata and the state provider in StateProvider.
The form is divided in two parts, one of them to display the neighborhood editing control of the current automaton and another one to display the automaton image in the current step. The form has two toolbars, in the upper one the automaton type, the cell provider and the optimizer are selected, and in the lower one are the general controls of the automaton and the controls provided by each particular type of automaton.
And that is all regarding this application, I hope you have found it useful and that you can develop your own versions of cellular automata with these indications.