Tablix 0.4

Wishlist

Following is a list of features that will be considered for inclusion during this development branch:

• Allow using multiple instances of the same module. This is currently possible, but not very useful for modules that define any kind of restrictions, because there is no way to connect a certain restriction to a certain instance of a module.

• Implement a more advanced scheme for migration.

• See export_htmlcss2 module in cvs export_htmlcss should make multiple files instead of one huge HTML page.

• done in 0.3.1 Implement some kind of some kind of "dependent tuples" system (see below)

• Including other XML files (as external entities) is currently not possible, because we only send the physical XML file given on the command line to the computing nodes. The proper way to do this would be to parse the XML file in the master process and send a parsed XML tree dump to the nodes. This would have several benefits: 1. Large problem descriptions could be composed of multiple files for better readability. 2. XML syntax errors would be detected sooner (before sending potentially large files over the network).

• Implement some way of sharing information between different modules. There is currently no simple way for a module to attach some extended information to a resource that could be accessed by some other fitness/export module.

• Done in 0.3.1 Fitness value caching. At the end of computation a lot of crossovers will produce identical offspring. Some caching of fitness value could improve performance. Each timetable could be first tested if the fitness value for it exists in the cache. If it does then table_fitness could just return the cached value. If not, the fitness value would be calculated in the ordinary way and added to the cache.

• libtablix. An independant library for handling tablix problem description files?

• API that would allow modules to provide hints to the kernel [1]

Dependent tuples

A way to tell the genetic algorithm that tuple N always uses the same resource as tuple M. (useful for example for "same-time-as" type of restrictions) Or maybe that tuple N always uses resource with ID R+1, where R is the resource ID of the resource tuple M is using ("consecutive" type of restrictions). This kind of restrictions don't seem to be handled efficiently right now (the genetic algorithm spends time minimizing the fitness function while the solution is obvious and does not depend on other restrictions).

Dependent tuples should not be handled by the standard genetic operators. A quick way to implement that would be to add another genetic operator that would overwrite values in dependent tuples with values from their "master" tuples. Perhaps an API to allow modules to add their own genetic operators? However if modules could add their own genetic operators that could lead to problems because the final result could depend on the order of calling those new operators. What would happen if two modules would have different ideas which resources must a certain tuple use? This could be solved by having a flag in tuplemap structure that would mean "this tuple is handled by a module". So each module could lock a tuple for its own use and if two modules would try to lock the same tuple Tablix would report an error.