For Users

Users are differentiated in the system by having a string field called role. Throughout the application, certain views and options are displayed by checking that field of the User we are concerned with. At the moment, the current structure is as follows:

• There is one "super-user", which has a role of admin. This User can add/delete any type of user, assign roles to new users, and can see all users and their problem-sets within the database.
• Under admin is the teacher role. Teachers also have the ability to sign up new users, be they teachers or students. The only users they are permitted to see, however, are the students assigned to them (via the teacher field).
• The bottom layer of user permissions is student. They cannot view any other student data, and cannot sign up new users. A student can only work on problems.

Suggested Enhancements

• Batch user sign up. As it is now, each user has to be signed up individually. It would be nice if a teacher could sign up many students at once, or even better upload a .csv file with a class roster. The desire to have this ability was expressed by the client also.
• Users could share one password. This is a request of the client, to go along with batch sign up. This should maybe be optional, as not every class may want to share a password.
• Track student progress. This was something we wanted to do all along but just did not have time to implement. It could be done in a variety of ways. One suggestion would be to monitor a students right/wrong answers and the time it took them to complete it over some time period, like a week or a month.
• User rankings. It would be kind of cool to have a "reward" system to motivate users. Maybe not a "best/worst" type of ranking though, as it could discourage students that are further behind.

Estimating Algorithm

The program logic responsible for deciding whether an answer will be accepted by the calculator for a given problem is kept in Rounding.rb, a Ruby file in app/controllers that is required by problems_controller. (Future maintainers may want to move this eventually.) For every problem, a Rounding object is instantiated. The Rounding constructor takes the arguments (a, b, sign, allow, threshold).

• a = Integer representing the first value in the original problem set
• b = Integer representing the second value in the original problem set
• sign = Character representing the operator in the original problem set {+, -, *, /}
• allow = Hash representing what sorts of roundings the calculator should accept (possible keys are :to5, :to10, :to15, :to25)
• threshold = Float representing the percentage margin an answer must be within of the actual to be accepted (i.e. 0.15 means answers must be between 85% and 115% of actual). Note that reducing this below 0.15 may result in problem sets that have no possible answer that will be accepted by the calculator.

When instantiated, a Rounding object sets up its possibility lists -- the numbers it will accept as rounded versions of the original problem set. For addition, multiplication, and subtraction, this is straightforward; an array stores all the possible "roundings" of a, and likewise another array for those of b. For division, a hash is set up, with all roundings of b serving as keys (we'll call the keys b'). It then takes the quotient of a/b' and computes all its possible roundings; each rounding is multiplied by b' and added to an array that's then stored as the value for the key of b'.

Calling the method goodRound?(x, y) returns TRUE only if the integers x and y are considered a good rounded set for the original set a and b.

Calling the methods tightAddEst?(x, y), tightSubEst?(x, y), tightMultiEst?(x, y), and tightDivEst?(x, y), return TRUE only if the integers x and y, when substituted into the original problem set, will provide an answer within the specified threshold (note that division is coded to increase the threshold by .03 automatically).

If you want to test the algorithm's behavior:

• delete =begin and =end from the end of the program to uncomment the test code
• from the command prompt, type "Ruby Rounding.rb"

Suggested Enhancements

• Work on division to ensure all problem sets have at least one answer acceptable by the program. It may be that the program should look for a conflict between its rounding rules and its threshold settings and, if one exists such that the combination allows no possible answer, it should relax the rules somehow.
• Big bug -- make sure there's error handling for when someone attempts to divide by zero. Currently this crashes the program.