HoriAsso - Progress Log: Difference between revisions

From Drorbn
Jump to navigationJump to search
No edit summary
No edit summary
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
===June 2===
====June 2====
*Rewritten the constructors for the class Words, which will be documented in the [[HoriAsso|Documentation]] page of this project.
*Rewritten the constructors for the class Words, which will be documented in the [http://katlas.math.toronto.edu/drorbn/index.php?title=HoriAsso_-_Documentation Documentation] page of this project.


*Written the java code to generate all Lyndon words from length 1 to length N, with k generators. This will be posted in the [http://katlas.math.toronto.edu/svn/HoriAsso/ repository] and documented in [[HoriAsso|Documentation]].
*Written the java code to generate all Lyndon words from length 1 to length N, with k generators. This will be posted in the [http://katlas.math.toronto.edu/svn/HoriAsso/ repository] and documented in [http://katlas.math.toronto.edu/drorbn/index.php?title=HoriAsso_-_Documentation Documentation]].


===June 5===
====June 5====
*Imported the Source code and the executables for the classes Word, Words, and LyndonWords into the [http://katlas.math.toronto.edu/svn/HoriAsso/trunk repository] from a MAC Os.
*Imported the Source code and the executables for the classes Word, Words, and LyndonWords into the [http://katlas.math.toronto.edu/svn/HoriAsso/trunk repository] from a MAC Os.
*Tried to set up a subversion client on AIX Unix.
*Tried to set up a subversion client on AIX Unix.


===August 16===
====August 16====
*Written the Java Free Lie Algebra package and documented it in [[HoriAsso|Documentation]].
*Written the Java Free Lie Algebra package and documented it in [http://katlas.math.toronto.edu/drorbn/index.php?title=HoriAsso_-_Documentation Documentation].

*The trivial but time-consuming part was to try to optimize the add/simplify function. I wrote binary search/sort functions that used the basis of the Free Lie Algebra, but realize afterwards that it would be better to just binary sort the <math>i^{th}</math> term (assuming the summands are already reduced to a linear combination of the basis)into the 1 to <math>i-1^{th}</math> terms because the generated basis takes up a lot of memory and limits the maximum length at which any calculation can be done just because the basis for that length is too big. The latter option is also as efficient as the first. Depending on if we will need to generate the basis anyways for our calculation, the add/simplify method will be changed.

====Sept 19====

*Written algorithm to reduce any Lie Tree of generators in the form <math>t_{i,j}</math> for any i,j pair to a Lie Tree with generators of the same reach only, where <math>reach (t_{i,j})= max \{i, j\}</math>

*I now need to decide how to restructure all the java classes. For instance, should I modify the LieTree class so that any LieTree object involves generators of a generic generator class and make a child class which uses the specific generators <math>t_{i,j}</math> or is <math>t_{i,j}</math> practically the most general form of a generator already?

====Sept 21====

*My plan was originally to have the FreeLieMod4TTree class inherit the FreeLieTree class with the extra mod4T relation only in the child class, s.t. we can use the parent class for plain Free Lie Algebra, and also we can use the parent class as the starting point for other types of modification to the FreeLieAlgebra (e.g., modding another relation); and similarly to have the FreeLieMod4TTreeVector class inherit the FreeLieTreeVector class. The problem is that my parent class, FreeLieTree class have fields, namely the left and right subtrees, that are of the FreeLieTree class itself, and in the child class, I would have to redeclare those fields to be of the child class type, FreeLieTreeMod4TTree, such that for each object of the child class, it would have both the subtrees declared within the child class of the child class type and also the subtrees within the parent class structure. I am not sure if this will simply make each tree too big, even though the subtrees within the parent class structures do not need to be initialized.

Latest revision as of 22:14, 21 September 2006

June 2

  • Rewritten the constructors for the class Words, which will be documented in the Documentation page of this project.
  • Written the java code to generate all Lyndon words from length 1 to length N, with k generators. This will be posted in the repository and documented in Documentation].

June 5

  • Imported the Source code and the executables for the classes Word, Words, and LyndonWords into the repository from a MAC Os.
  • Tried to set up a subversion client on AIX Unix.

August 16

  • Written the Java Free Lie Algebra package and documented it in Documentation.
  • The trivial but time-consuming part was to try to optimize the add/simplify function. I wrote binary search/sort functions that used the basis of the Free Lie Algebra, but realize afterwards that it would be better to just binary sort the term (assuming the summands are already reduced to a linear combination of the basis)into the 1 to terms because the generated basis takes up a lot of memory and limits the maximum length at which any calculation can be done just because the basis for that length is too big. The latter option is also as efficient as the first. Depending on if we will need to generate the basis anyways for our calculation, the add/simplify method will be changed.

Sept 19

  • Written algorithm to reduce any Lie Tree of generators in the form for any i,j pair to a Lie Tree with generators of the same reach only, where
  • I now need to decide how to restructure all the java classes. For instance, should I modify the LieTree class so that any LieTree object involves generators of a generic generator class and make a child class which uses the specific generators or is practically the most general form of a generator already?

Sept 21

  • My plan was originally to have the FreeLieMod4TTree class inherit the FreeLieTree class with the extra mod4T relation only in the child class, s.t. we can use the parent class for plain Free Lie Algebra, and also we can use the parent class as the starting point for other types of modification to the FreeLieAlgebra (e.g., modding another relation); and similarly to have the FreeLieMod4TTreeVector class inherit the FreeLieTreeVector class. The problem is that my parent class, FreeLieTree class have fields, namely the left and right subtrees, that are of the FreeLieTree class itself, and in the child class, I would have to redeclare those fields to be of the child class type, FreeLieTreeMod4TTree, such that for each object of the child class, it would have both the subtrees declared within the child class of the child class type and also the subtrees within the parent class structure. I am not sure if this will simply make each tree too big, even though the subtrees within the parent class structures do not need to be initialized.