The goal of this project is to provide a library containing a new abstract data type called **Matrix** with associated function to manipulate them. The final program have to enable a user to test the library in an interactive and practical way.
Since we decided to not store false value \footnote{cellElement does not contains values anymore, their existence is their value}in our matrix and to not store the colElement and rowElement \footnote{they are unified and renamed as listElement}that are empty, we decided not to worry too much about performances and we encapsulated all access to stored data in the Matrix structure to avoid too much complexity and allow more modularity, readability and re-usability. We created high level tools to manipulate our matrix and used it all along the project.
For compilation we didn't used the **-ansi** flag since we had to deal with both clang and gcc for compilation and clang didn't accept this flag. Instead, we used the **-std=c89** flag witch contains the same rules but is accepted on both softwares. Compiling with **-ansi** still works.
We decided to create two different library. One for the graphical interface (which require SDL2) and the other with the Matrix data type) so this way you may just have to compile one lib if you don't need the gui.
# Description of abstract data types
Every function and data type are described in the documentation given with the project. This documentation is generated with doxygen.
The most interesting function are *getCellValue* and *setCellValue*. Those are the one we rely on the most. They are our way of dealing with our complex data structure allowing us to avoid to store false values. They are the functions that need the more computational power on the long run but are really useful due to their level of abstraction and their high level.
Functions *andColSequenceOnMatrix* and *orColSequenceOnMatrix* are implemented with *colSequenceOnMatrix* and are really not interesting so we're gonna provide the algorithm of the last one :
```C
```
This is the same thing for *andRowSequenceOnMatrix* and *orRowSequenceOnMatrix* :
As we said before, we decided to not store false values in our matrix. So, by default, all values are set to false and every time we created a new matrix, we only used setCellValue for true values.
To easily handle errors, we added ERROR to the bool enum. It was handy to detect out of bounds values and could be treated as false values on applyRules with the errorToFalse function.
We created OR, AND and XOR function. OR and AND were created for colSequenceOnMatrix and rowSequenceOnMatrix to be passed as pointers. The XOR function was created for readability. We also added MXOR function to apply XOR on a given array of boolean.
On applyRules, we decided to create an array with a static size of 9 integers. We agreed on this value because it was the maximum possible number of rules that could be applied at the same time and because it was the most balanced choice between performances and memory. Actually, 9 integers doesn't take so much memory and avoided to use malloc and realloc that relied on systems calls and on the operating system will that could slow down the process of factorization.
For boolean matrix, we created a structure to easily handle the size inside all our function and to respect the given prototype where we should have guessed the size.
Our program is fully functional but encounter, as we predicted, some performance issues on big matrix. We tested for our SDL GUI (that should only used on big matrix) a 1900x1080 sized matrix and it was long to process (more than 5 seconds). It was due to the original design we had to follow and would have been a lot faster with only a simple array-based allocated matrix keeping all false values.
We also had troubles with the freeMatrix function that is not really optimized. Our first attempt without slow setCellValue and getCellValue functions was a nightmare to understand and caused memory loss. It was unreadable and we both decided to prioritize readability over performances. Memory loss was unacceptable since the main goal was to sacrifice computational power to save memory.
