Our team name is EGAD, standing for Expert Generic Algebra Designers, and it consists of Will Fleming, Symon Perriman, and Aaron Wise.
        The basic goal for this design is to create a easily modifiable and expandable computer algebra system. The goal is for a new algebra system to be implementable by writing a new subclass (meaning, defining the algebra object and the operators) and then changing the main program in one place to let the program know a new subsystem has been added.
        We intend to implement all the basic features of the expression tree class, which will work for Arithmetica, an image generator, and other systems. We will also try to extend it to allow for various outputs, and add advanced functionality to the expression tree programs.

All team members will have the same basic functions; that is, coding, breaking up existing code, debugging, and documentation. Since each team member has their own strengths, and we will assign roles tailored to those abilities.

Will Fleming:

Will has had experience in C++, and knows HTML pretty well, so he will likely work on the web page and help other team members with language specific questions on top of assigned coding. He is also decent at designing complex algorithms, which might come in handy.

Symon Perriman:

Symon also has C++ and HTML experience; he is also good at organization, so he will probably help to define how we organize work on the project, as well as doing his assigned coding and helping Will with C++ questions and the website.

Aaron Wise:

Aaron has little experience with C++, but Will and Symon can help him with any language problems he has. He is good at conceptualizing the shape of the project, and has helped to define the general structure of the program as we plan to implement it. He will likely help the team to structure the program, as well as work on assigned coding.

      The arithmetica has now been implemented using of templates, and the code has been refractored to eliminate repeated code.

      The next step is implementing the image class which we are currently in the process of doing.  We don't foresee any problems - it will just be a case of testing and debugging.

Arithmetica:

      The expression abstract class will contain the primary functions of the expression tree program: infixToPostfix, postfixToTree and evaluate. Each expression will have a myObjectPointer field instead of myValue. This allows an expression to contain a pointer to an int, image or other argument.

The expression class will be inherited by 3 (or more) subclasses. These subclasses are the different algebra systems to be implemented (i.e. Image Generator, Arithmetica etc.). The subclasses will be able to use the parent class's functions, and will not need their own implementations of them. The main contents of each subclass will be a list of operator structs. The operator struct has 3 parts.
    1) name - the symbol for the operator, i.e. "+", "plus", or "max"
    2) type - the 'kind' of operator, i.e. binary, prefix unary, function etc.
    3) evaluation expression - how to evaluate it, i.e. LHS + RHS

The expression.evaluate function will be changed as follows: The switch will be removed, and will be replaced by the function call myOp.evaluate(). The expression.postfixToTree will probably undergo the most substantive changes. The function will first call myOp.type() and will then choose how to create this node of the tree (this will probably first be implemented with an if tree, and then refactored later to use a more object-oriented control structure). Each type of operator will have its own subfunction controlling the creation of the tree node. For example, for the function type (i.e., max( 5, 5, 6)) the postfix will look like 556,,max. The function will return a tree like:

      node-> max RHS->6 and the LHS will be created from the postfix 55,max.

expression.infixToPostfix will hopefully not have to change substantially.

Error checking will be implemented in either the postfixtotree function, or before infixtopostfix. After the project begins to take shape, we will decide where error handling can be implemented more effectively.

Time Breakdown

General:

Refactoring/rewriting base expression class
    -evaluate function - 6 hrs
    -postfix to tree - 10 hrs
    -error checking - 10 hrs
    -infix to postfix - 2 hrs
    -restructuring expression class (for example, changing myValue to
         myObjectPointer) - 10 hrs

Arithmetica:
Creating each subclass of Expression - 2 hrs each
Integrating the subclasses and main program (allowing, for example, for the user
        to choose which subsystem of the expression tree) - 4 hr

Image Generator:
Creating each subclass of Expression - 2 hrs each
Integrating the subclasses and main program (allowing, for example, for the user
        to choose which subsystem of the expression tree) - 4 hr