AZ Dept. of Education Freethrows Product Part III


This is the final post in an overview of my involvement in the ‘math engine’ development for the AZ Dept. of Education Freethrows product.  The two prior pots are here:

Part I

Part II

I’ll discuss an auxiliary product, the Freethrows Problem Analyzer in this post.  Math problems are defined as a combination of variables and operators along with variable constraints and optional problem-wide constraints.  Problem constraints limit variable generation to a subset of their domain.  Defining a problem can be time-consuming and error-prone since it is not reasonable to expect a curriculum developer to solve all possible problem generations.  In many cases, some combinations of generated variables may lead to a solution that is not in line with the specific grade-level objective for that problem.  The simplest case is K-6 problems in which there is an implicit desire to have no negative solutions.  It is easy, unfortunately, to specify variable constraints that seem largely reasonable, but a very few combinations might lead to negative answers.  In these cases, a problem-wide constraint is necessary to enforce the implicitly stated goal.

The Freethrows Problem Analyzer (FPA) was created as an interactive tool that allows curriculum developers to both create new problems from scratch and completely test/analyze existing problems in the database.  An entire set of utility functions were created in the math engine to support problem solution and analysis for the FPA.

The beta interface is shown below


The application consists of two panes, the upper devoted strictly to problem definition and the lower devoted to problem generation, rendering, and analysis.  Variable windows are color-coded, green for inclusion in the problem and yellow for the unknown.  A light red indicates an error in the variable template in the database (which happens on occasion and the FPA has proven to be an invaluable tool for identifying subtle data errors before they appear in the application).  The default template, W= Y is illustrated.

After loading a problem, the constraint values may be visually validated and edited if desired.  For example, one of the early Kindergarten problems is W + X = ? with W in [0,5], X in [0,5], and the answer range-constrained to [0,5].  This is desired so that finger-counting on a single hand may be used as an aid.  So, the problem 2 + 3 = ? is a valid generation, but 5 + 2 = ? is not valid since the answer violates the problem constraint.  The problem designer may wish to change the problem constraint data to the interval [1,5] and check the generated problems.  This is performed by clicking on the ‘Assign Constraint’s button.  The current constraint values are shown.


The variable constraint may be changed from a range value to a set or the range could be adjusted to the interval [1,5].

The variable constraints editing window is automatically adjusted to the variable type.  If the type is fractional, for example, this window appears.


Some variable constraints can not be defined as individual ranges or sets of numerator and denominator, for example.  In these cases, it is more convenient to use direct fractional or mixed input.  This is called complex data in the math engine since there is no direct ‘fraction’ or ‘mixed number’ variable type in a typical programming language.  These values are represented as IMathType instances and complex data may be entered and processed directly in the FPA.


The upper pane in the FPA interface allows problem constraints to be added or removed.  Once the problem is created to the designer’s satisfaction, the lower pane is used to render an example problem.  The render may be repeated multiple times or a hundred iterations may be rendered and displayed as shown below.



The problem is automatically solved and the solution value (actually an IMathType) is displayed along with the generation.  Inside  the math engine, all math types are promoted to the most complex value.  So, if a whole number and a mixed number are involved in the solution, the whole is promoted to a fraction type.  The same promotion occurs for float math types.  This ensures that all arithmetic operations in the solution are performed in a manner that alleviates possible numerical (rounding) issues from floating-point arithmetic.

A sample problem render is provided below,



The problem analysis feature has proven to be very helpful.  It analyzes the extrema of the solution value if no problem constraints are supplied.


In some cases, this analysis shows the designer that problem constraints are required in order to meet specific curriculum objectives.  In other cases, it helps the designer quickly select constraint ranges.  We have even found that the FPA helps problem designers understand that some problems do not require additional constraints or that the problem is over-constrained.

Overall, I’ve found this to be a highly rewarding project, especially the combined programming and math challenges.  And, it’s always rewarding to see children excited about learning math!

Comments are closed.