Mendix is a fantastic business tool catered to provide business with rapid high quality applications. Some time ago someone made a joke about writing an artificial intelligence application, specifically a genetic algorithm (GA), in Mendix and for some reason I couldn’t let the idea go so I gave myself a time boxed period to model one. I learned a few interesting things about Mendix which I summarize in the last section and have defined more of how I built the GA in the inbetween section.
In order to understand more we need to define some GA terms:
1. An Organism as: A solution contains the blue print to the answer to the problem trying to be solved.
2. A Chromosome as: A building block of the solution contained within the organism.
3. A Population as: A group of organisms, each containing their own specific answer to the problem. Some solutions are better than others and therefore the organisms with the better solutions are deemed to be fitter (more valuable) than others. When the GA is initialized the first populated of organisms gets generated and each chromosome randomly selected, there after each generation is bread by crossing the chromosomes from parent populations to create the next generation. Since organisms are created from parents (2 organisms being joined to create a child organism and in doing so mixing the parents chromosomes into the single child organism) the population is refreshed each generation with a set of organisms.
The Rules Of Game
The purpose of the game is to, by using an endless supply of knight chess pieces, try to find a way to fill each block of a chess board. Practically, and in genetic algorithm language, that meant that each organism gets a random starting point as part of the initial population generation. From that point they can decide which block the knight must move to next (moving in the special way that only knights can). The program allows the knights to move until there are no further free blocks to move to as per their chromosome move choices they’ve made.
The Organism, Fitness and Generations
Organisms that can place more knights on the board are seen to have within themselves a more optimized answer to the problem and are defined as fitter than others. Once the fitness for each organism is calculated then the fittest organisms breed and produce the next generation. The organisms breed by randomly mixing their chromosomes together.
In this game the chromosome is a set of decision choices about where to move next. For example a chromosome will be a decision choice to firstly move 2 places up and one place to the right after the last taken block.
I represented each potential move as a enumeration and saved that in an organism entity.
After all moves had been played out the fitness was calculated by a simple retrieve on open board blocks linked to the organism. After the organisms are scored then their enumeration chromosomes mixed together to form the next generation organism.
The outputs show that after running the algorithm for 6 generations or more than the best solution flattens out at about 76% optimization. To progress to a further optimized solution would probably require the addition of mutated organisms, something I might leave for a time box another day.
I learned a lot in doing a GA with Mendix. Some of the lessons are business related, some of the lessons were things I just picked up during the development of the GA:
1. Mendix promotes a configuration approach
Mendix makes it really easy to add your settings and configuration for running the application in an entity format. Things like setting the number of generations you’d like the program to run for, number of blocks on the chess board and number of organisms per generation are really easy to set. A configuration approach immediately puts a Product Owner/Business in the driving seat allowing them to be responsible for the application solution. When running GA’s you need to tweet with these types of settings to figure out how to optimize things. I found that Mendix naturally lends itself to a configurable approach without having to compile and run each time I wanted to tweak something in the algorithm.
2. The Visual Nature of Microflows
The visual nature of Microflows is an added benefit to creating GA’s with Mendix. The Microflow which calculates where the next knight would move to was visually created as such.
For example the Microflow to move the next knight left 2 blocks and up 1 block was called “West Up” and could be found exactly there: on the left hand side and up.
3. Traditional looping is difficult, but visually easy to interpret
Creating loops in Microflows are interesting to get your mind around. It doesn’t feel natural but it is visually really easy to visually interpret. In a code like fashion looping within a Microflow feels heavy but achievable.
4. Getting my hands on the Data was Cha Ching
I’ve created GA’s in Object Orientated languages before. Typically it takes too much time to persist the data generated by the algorithm so debugging and problem solving is normally done via drudging through app created log files or if you do output data to a database you then have to peruse the data via SQL. The Mendix entities persist with no effort at all so I had no problem getting my hands into the data to source problems because it was so easy to do so especially since it was effortless to create custom screens from which point I could both see and change data while tweaking the algorithm during run time. The result was shorter problem solving time periods and in a time boxed scenario saving time is gold!
5. Good fun
It’s great to do a project like this in Mendix. It’s also good to experience practices like working from the entity model hold true even when dealing with traditionally “Computer Science” type lab problems. As always its great to experience how easy it is in Mendix so create a good quality solution in such a short space of time.