Matrix Groups: Week 7 Update

From the initial Applet constructed in the last update, a number of changes have been made, mostly polishing what was already working and trying to get working what was not.

To summarise, last time I had constructed a DOS program that successfully managed to calculate the group of a given set of matrices, and calculated the subgroups generated by an element of that group. I then transferred the working code to an Applet, where the group was still being calculated successfully, but the input method and the displaying of the element generated subgroups was not working.

Matrix Group Calculator (Source Code: GroupApplet.java, Matrix3x3.java. Source Code in PDF Format: code.pdf)
Code Compiled on 8th November, 2000

Week 7 Report

Most of last week's work involved tidying up the code generated by the IDE, namely Borland JBuilder Foundation. A worrying fact was that when constructing some code triggered by a mouse event, the IDE entered the same piece of code twice (or more), therefore executing the same code more than once when a single event such as a mouse click was performed. This resulted in the input errors noted above, where on adding a matrix to the master list, an incorrect message was displayed. This was because the piece of code adding the generator executed correctly but was executed again therefore triggering the incorrect output message.

I went through the entire source code, eliminating these errors, adding comments to the code and reorganising the code so that variables were defined in a logical order and that different sections of the code were clearly labelled.

After 'parsing' the code and understanding better how the IDE generated code, I concentrated on enabling and disabling certain buttons at different stages in the program. For example, when the program starts, we do not want to calculate the group because no matrices have been added yet. Similarly, when the program is in the middle of displaying e.g. the subgroups of a group, we do not want the user to press the "Display" button or who knows what might happen.

To control which buttons are active at different times, I used the setEnabled method on the buttons in the Applet. For example, when there are 3 matrices in the list and the user hits the "Display" button, we want the user to be able to hit the "Next" button to display the next matrix in the list. However, when the user has hit the "Next" button twice, and we are displaying the third matrix out of 3, we do not want the user to hit the "Next" button again as this makes no sense. So after the user has hit the "Next" button twice, the code Next.setEnabled(false); executes and promptly dims the "Next" button. It is enabled again once a suitable event is triggered.

Now that the display problems had been sorted, I proceeded to tackle the problem of getting the program to wait until the user pressed a specific button on screen. I constructed methods called Dim and Undim to implement the control over which buttons are active at any given stage. However, I was unable to get the program to look for a button press and this is one thing I will be concentrating on in the following days. (As a workaround, I managed to pause the program for a given length of time so that the ideas behind what is happening are at least explored).

While experimenting with different combinations of generators and calculating their groups, I came across a set of matrices which generate an infinite group. Before, when the program attempted to calculate the group of this set of matrices, the program failed to notice the infinite group and carried on to calculate new elements of the group until an out of memory message appeared. To work around this, I altered the CalcGroup method to look for these infinite groups. The way I handled it was that in the for loops used in the method, I analysed the number of times a certain piece of code executed. Once this exceeded a set limit, the code fell into a "trap" set up and immediately exited from the for loop, displaying an "Out of Memory" message on screen. This way the user knows that he or she has requested the calculation of a very large (and probably infinite) group.

Next week's work....

Now that the Applet is correctly accepting input, calculating groups successfully and calculating element generated subgroups correctly, (bar the problems with the event handling) the next goal is to calculate the subgroups of a given group. The main problem with this is to construct an algorithm to accomplish such a task. To see the basic theory behind the problem, click here to see a PDF file containing some notes from the G2M31 Abstract Algebra course I took in the second year.