Patent Application
20070298389
Embodiments of the present system will now be described with reference to
The present system combines stored templates with an algorithm for matching and applying the templates to user inputs to generate intermediate steps in the solution of a math problem. In general, upon inputting a mathematical problem, the algorithm of the present system searches for one or more templates that match the form of the inputs. The templates include code for displaying intermediate steps for solution of the input problem, including the intermediate expressions for the solutions and explanatory text. Once a proper matching template is identified, the template is populated, or materialized, with information from the user input, and then the intermediate steps from the template may be generated from the template and displayed to the user.
The following description relates to the composition of the templates. As equations may include any number of variables and terms, there are in fact an infinite number of equations and mathematical problems which may be posed. As such, the number of templates which may be generated and stored is also limitless. However, in embodiments, templates are generated and stored covering any mathematical problem a student is likely to be presented with, though it is understood that the number of templates may be lesser or greater than that in alternative embodiments.
Moreover, it is understood that a given equation may be written in several different forms. For example, the expression “2x+4y−6=0” may alternatively be expressed “2x=−4y+6.” Thus, a single equation may have several different templates devoted to it, each expressing the equation in different forms.
As indicated in the software block diagram of
The rule portion of a template 100 specifies a matching expression in XML format, though other formats are possible. As explained hereinafter, the matching expression is parsed by the algebra engine 106 into a tree structure usable by the algebra engine. The user input is similarly parsed into a tree structure, so that the algebra engine may compare the user input against the template matching expressions to find those templates that match the user input.
The rule portion of a template 100 may further include conditions in an XML format, though other formats are possible. The conditions specified in the rule portion of the templates may be used in addition to the matching expression to further pair down the list of what templates can be used for a given input. After a matching template is found, the algebra engine 106 uses the rule portion of the template to evaluate coefficients and the intermediary variable values.
The rule portion of a template 100 may further specify intermediary variables that are to be determined by the algebra engine 106. In particular, intermediate steps typically involve conversion and/or simplification of the original input problem. This conversion and/or simplification typically involve the use of one or more intermediary variables that are specified by the author and built into the template. These intermediary variables are solved for and used in the display of the intermediate step. The role of intermediary variables is explained in greater detail hereinafter.
Each rule template portion may be assigned its own unique name, and the name may match with the corresponding display template portion. When an author creates a template, a command line utility can be used to verify the XML format, and the tool will generate error messages if it finds incorrect formats or inconsistencies in the rule template. The same command line utility may be used by a developer to compile the XML file into a binary file as indicated below.
Below is an example of a rule portion of a template 100 showing the format of the rule template portion. The requirements of the different parts are explained below. A complete rule template XML file may be as follows:
The root element may be <Templates>. There can be multiple <Template> elements in the same file, although separate XML files may be created for each template. The file name may be in the format of “xyz.Rule.xml”, and the same template name may be used in the file name, so for the above example, the file name may be “Equation.Linear.1.Rule.xml”.
In the above example, the Template element has an ApplyOnReal=“1” attribute. A template can have either ApplyOnReal=“1”, or ApplyOnComplex=“1” or neither. If neither is there, the template can be used in both the real number field and the complex number field. If one of them exists, then the template is used in that number field.
The Variables/Variable elements are used to specify “principal variables”. All variables that are not principal variables are coefficients. For equation solving, the principal variables are the same as the solve-for variable list. There can be multiple Variable elements under Variables. An example would be to solve a linear equation system.
The matching expression contains the linear syntax of the input expression. Implied coefficients may be used in addition, subtraction, multiplication and division, but not in other types of expressions. For example, the user input “3x+5=2” will match to the template shown above, with implied coefficients a=1 and b=0. Implied coefficients may be omitted in alternative embodiments.
The condition element specifies a match condition, and may be omitted from a template. One or more of the following conditions may be used in the condition: “and”, “or”, “not”, “xor”, “=”, “>”, “<”, “>=”, “<=”, “is Int”, “is Fraction”, “is Number”, “is Even”, “is Odd”, “is Real”, “is Complex”, “is Rational”, “is Atom”, “is Const”, “is VariableFree” “in {_comma_delimited_list_here}”. Other conditions are contemplated.
Values/Value elements specify the intermediary variables. Each Value element may be an assignment, and it can use the coefficients specified in the Match expression, or other intermediary variables defined before the current one.
The display portion of a template contains an indication of the text to be displayed in the intermediate step. In embodiments, as explained hereinafter, the present system may be used in different language speaking countries. Accordingly, instead of hard-coding actual text into the display portion of the templates, the templates may include a text ID which identifies specific text. At runtime, the application program uses the text ID to look up the specific, localized text from a database associated with the user computing system.
The display portion of the template may also specify what parameters are to be displayed along with actual text in the intermediate step. For example, the display portion of the template may include a text ID which calls localized text:
The display portion of a template may also contain information relating to a conditional statement (if . . . then . . . else), and flow controls (goto and call statements) as explained hereinafter.
A description of the architecture of the present system will now be explained with reference to
Embodiments of the present system include an application program 104 having an algebra engine 106. Algebra engine 106 may perform the significant portion of the present system, including matching an input to a template and materializing the template. Other portions of the application program 104 may be responsible for interacting with the graphical user interface to receive input from the user and to display the results and intermediate steps generated by the algebra engine 106 according to embodiments of the present system.
Algebra engine 106 includes a plurality of known components for performing known functions of algebra engines. For example, the Parser 108 is provided to parse user input into a tree structure usable by the algebra engine 106 for solution of the problem. The parsed tree structure also allows matching of the input to the stored templates, which include template matching expressions parsed into a similar tree structure as explained hereinafter.
Serializer 110 is used to serialize the tree structure into various text representations that can be understood by a human or by other software components that are responsible for displaying the math formulas. Number Evaluation Engine 112 evaluates various operations on numbers symbolically (without round off errors). Examples of such evaluations include:
½+⅓=⅚
sqrt(8)=2*sqrt(2)
Symbol Evaluation Engine 114 evaluates operations on generic algebraic expressions symbolically (without round off errors) examples include:
sin(x)/cos(x)=tan(x)
(ê2+e)/e=e+1
Numeric Evaluation Engine 116 evaluates operations on numbers and constants numerically and generates approximate answers (possibly with round off error). Examples include:
Log(5)=0.698970004336
23{circumflex over (0)}45=1.8956258430116*10{circumflex over (0)}61
Expression Typesetting Module 118 formats an expression into a reasonable format that is generally used in text books or math publications. Such formatting procedure includes the steps of putting the terms in reasonable order (e.g., “2a x{circumflex over (0)}2” instead of “x{circumflex over (0)}2*2a”), and the right placement of terms in fractions (e.g. “x/2” instead of “½*x”), as well as the correct placement of a minus sign (e.g.
instead of
etc). This is independent of the serializer module 110. Typesetting Module 118 operates on the tree structure and therefore occurs before serialization.
Calculus Engine 120 evaluates calculus related expressions, including derivatives, integrations, limits, etc. Examples include:
Equation Solving Engine 122 solves equations both symbolically (without round off errors) and numerically (possibly with round off errors).
It is understood that algebra engine 106 may include additional and/or alternative known components for algebra engines to those described above in further embodiments.
The algebra engine 106 may further include a matching engine 130 for matching a user input to a template, and a materialization engine 140 for materializing a template with numerical expressions and/or text for display of the intermediate steps. The matching engine 130 and the materialization engine 140 are explained in greater detail hereinafter.
The overall operation of the present system will now be explained with reference to the flowchart of
In step 206, the algebra engine 106 parses the received user input. Thereafter, the algebra engine evaluates the input in a step 208 in a known manner and determines whether the input is valid. If not, the algebra engine displays an error message over the graphical user interface in step 210. If the input is found to be valid in step 208, the final result is generated in step 212.
After an input is validated, in addition to generating the final result, the application program 104, and in particular matching engine 130, searches for matching templates in step 220. Step 220 is explained in greater detail with respect to the flowchart of
For instance,
The user input is parsed into a similar tree structure. In step 232, the matching engine inspects the root node of the user input, here “=”, and rejects it if there is not a match. The matching engine then walks down all branches of the trees for both the parsed input and parsed template matching expression in step 234 and performs a matching comparison node by node. If there is a mismatch at any node, the template is rejected as a match.
There are different flags in the template to specify what in the user input can be matched to a variable in the template matching expression. The node 226 in the matching expression input tree containing the “a”, “b”, “c” and “d” can for example be wildcards that may be matched to any coefficient in a corresponding node of the user input tree. In embodiments, nodes in the stored template matching expression tree containing actual number coefficients may only match those same coefficients in the input tree nodes.
In the event a given wildcard in the template matching expression is matched to a coefficient in the input tree, then that wildcard is assigned that coefficient. In the event that the same wildcard appears twice in a template matching expression, then the input must have the same two coefficients in the corresponding nodes, or there is no match. For example, a template matching expression “ax+ay=b” would not match an input expression “2x+3y=b”.
As indicated above, in order to make the templates 100 more general, implied coefficients may be allowed during matching. For example, user input “3x” may match template matching expression “ax+b” where a=3, x=x, and b=0 is an implied coefficient.
If a given template is found not to match the input in step 234, the matching engine loops to step 244 to check if there is another template to check. If there is, the matching engine loops to the next template in step 230. Assuming a template matching the input is found, the algebra engine 106 evaluates any matching conditions in the template in step 236. In particular, as mentioned above, a template may include conditions relating to the expression represented by the template. The conditions may be a variety of different requirements which must be true in order for there to be a match between the input and template. A further partial listing of possible conditions is set forth above. As a further example, the algebra engine may check for specific values which a term in the template must have, or not have, such as “not(a=0)”.
The algebra engine 106 checks whether all conditions for a given template evaluate true for a given input in step 238. If any conditions for a template are not met, that template is dismissed as a possible match, and the algebra engine skips to step 242 to check for a next template. If a template's matching expression matches with the user input (step 234), and any matching conditions in the template are satisfied for the input (step 238), then that template is added to a stored listing of candidate matches for the input in step 240.
After the computer algebra engine iterates through all templates in step 242 and finds all candidate matches, the algebra engine next checks for overriding relationships among the candidates in step 250. In particular, sometimes the same problem can be solved in different ways, and therefore multiple templates can match with the same user input. If the templates are using different strategies, they may all be shown to the user so that the user can choose which one to use. However, at times a template A and a template B are solving the same problem using the same strategy, but template A is more general (applying to broader cases). Template B is more specific and its usage is narrower, but because of the special constraints on template B, template B uses fewer steps and is more straightforward and easier to follow. In this case, when templates A and B both match with a given user input, template A may be hidden and only template B shown as a candidate.
In order to handle this situation, templates can specify override flags (<Hide> elements in the template file format). The computer algebra engine 106 iterates through the candidates (step 250), and the algebra engine checks to see if one candidate is overridden by another candidate (step 252). If one candidate is overridden by another candidate, the overridden template is removed from the candidate list in step 254.
Once a candidate is checked for its override flags, the algebra engine checks if there are further candidates to test for the override in step 256. If so, the engine loops back to step 250 to check the next candidate. Otherwise, the final list of matching templates is stored in step 260. It is understood that the feature of override flags, and steps 250 through 256 relating thereto, may be omitted in alternative embodiments so that both candidates (templates A and B in the above example) remain as matching templates to the input.
Returning again to the overall operational flowchart of
In step 266, the algebra engine 106 checks whether a user selects one of the links in step 264. If not, the algebra engine performs no further functions for the input and displays the solution over the graphical user interface. On the other hand, if a user selects a link displayed in step 264, the materialization engine 140 of algebra engine 106 materializes the template with values from the input and/or any intermediary variable values in step 270. Further details of step 270 are shown in the flowchart of
The templates 100 contain the general procedure but not specific coefficient values from user input. A matching template, when selected, must therefore be materialized by “plugging” values from user input and/or intermediary variables into the template before the intermediate steps specified by the templates can be displayed. As used herein, the terms materialize and populate are used interchangeably. In embodiments of the present system, the materialization may happen in four general steps. The first three steps may be performed by the computer algebra engine 106 and the last step may be performed by the application program 104 communicating with the graphical user interface.
In general, the first step processes and simplifies all intermediary variable values defined in the template using coefficient values from user input. In particular, a template may specify that an input equation is to be processed into an intermediate form, or expression, which is to be used for explanation purposes in the intermediate step. The intermediate expression may require the calculation and use of intermediary variables. An example is set forth below, but it is understood that any number of expressions and intermediary variables may be specified in various templates for use in generating the display of the intermediate step(s).
Accordingly, in step 272, the algebra engine 106 extracts the coefficient values from the user input and assigns them to the corresponding variables or wildcards, if any, in the template. Any intermediary variables are then processed and simplified in step 274. As an example, assume a matching expression in a template is “a x{circumflex over (0)}2+b=c”, and user input is “2 x{circumflex over (0)}2 +3=21”. In step 272, the algebra engine will assign the coefficients 2, 3, 21 to the wildcard coefficients a, b, c, respectively.
In this example, the template may specify several intermediate steps such as:
The second general step (step 276) is to generate the expressions using coefficient values from user inputs and the intermediate variable values. In particular, any expressions specified in the template may include intermediary variables. The intermediary variables processed and simplified in step 274 are inserted into the expressions. Thus continuing with the above example, the following expressions are generated in the various steps:
The intermediate variables and expressions are used to designate what is simplified and what is not. In particular, intermediary variables are simplified, but expressions are not. Simplifying the expressions would result in simply reaching the final solution, and there would be no intermediate steps to display. Thus, the expression designated in a template is displayed, with all original inputs inserted where applicable and with all intermediary variables simplified as set forth above and inserted.
The third general step is to process the display flow using the display portion of a template 100, as explained below in steps 278 through 282. The display flow is specified in the template with any number of elements, including for example text elements, expression elements, conditional elements (if . . . then . . . else), goto elements (to terminate display flow in current template and continue from another template), and formatting constructs such as indicating a new line and new step.
As indicated above, text elements to be included in the display of the intermediate steps may or may not include parameters. Namely, the text display of the intermediate step may include the display of a user defined value (from the original input), a calculated value (from an intermediary variable) or an expression. If there are text parameters, the computer algebra engine may substitute in the actual values for the parameters in step 278.
In step 280, any conditionals are evaluated according to the values from user input and only the relevant branches are kept in the actual steps. In particular, an intermediate step may become irrelevant because terms (implied or otherwise) zeroed out, or because a condition to be satisfied in order for an intermediate result to be relevant was not in fact satisfied. If it turns out that one or more of the intermediate steps are not relevant to a particular input, these intermediate steps would not be displayed. In alternative embodiments, the algebra engine may display the irrelevant intermediate step with an indication that it is not relevant and why it is not relevant.
A template may indicate that intermediate steps from another template should be included, either in the normal course of operation or if certain conditions are true. Therefore, templates may include goto elements that indicate which additional template(s) and, if necessary, which intermediate step(s) of the additional template(s), are to be displayed. In step 282, any goto elements may be executed by appending the steps in the target template to the current step sequence.
After the third general step described above in steps 278 through 282, the one or more intermediate steps are ready for display, except that the actual text needs to be imported, depending on a language specified by the user. As mentioned above, in order to use the present system in international markets, the text may be localized into different languages. The computer algebra engine 106 may be kept language neutral, and only the application executable needs to be localized. Therefore, in step 290, the application program 104 uses the text ID specified in a template for a given intermediate step to look up the specific, localized text from a database associated with the user computing system. It is understood that actual text may be hard-coded into a template in alternative embodiments instead of retrieving localized text with text IDs.
In step 294, the parameter values of the text element are merged with the actual text. At this point, the template is completely materialized to the actual step-by-step solution specific to the user input and it can be displayed.
Returning to the overall operational flowchart in
The description above relates to generating and displaying step-by-step instructions for solving problems that are handled in a typical computer algebra system implementation, including arithmetic, elementary algebra, equation solving, linear algebra, statistics, trigonometry, and calculus, etc. However, it is understood that the present system may be used for solving mathematical problems in a wide variety of other math disciplines. Such additional disciplines include geometry, graphing, and word problems, etc.
The inventive system is operational with numerous other general purpose or special purpose computing systems, environments or configurations. Examples of well known computing systems, environments and/or configurations that may be suitable for use with the inventive system include, but are not limited to, personal computers, server computers, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, laptop and palm computers, hand held devices, distributed computing environments that include any of the above systems or devices, and the like.
With reference to
Computer 310 may include a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 310 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read only memory (ROM), EEPROM, flash memory or other memory technology, CD-ROMs, digital versatile discs (DVDs) or other optical disc storage, magnetic cassettes, magnetic tapes, magnetic disc storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 310. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.
The system memory 330 includes computer storage media in the form of volatile and/or nonvolatile memory such as ROM 331 and RAM 332. A basic input/output system (BIOS) 333, containing the basic routines that help to transfer information between elements within computer 310, such as during start-up, is typically stored in ROM 331. RAM 332 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 320. By way of example, and not limitation,
The computer 310 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, DVDs, digital video tapes, solid state RAM, solid state ROM, and the like. The hard disc drive 341 is typically connected to the system bus 321 through a non-removable memory interface such as interface 340, magnetic disc drive 351 and optical media reading device 355 are typically connected to the system bus 321 by a removable memory interface, such as interface 350.
The drives and their associated computer storage media discussed above and illustrated in
The computer 310 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 380. The remote computer 380 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 310, although only a memory storage device 381 has been illustrated in
When used in a LAN networking environment, the computer 310 is connected to the LAN 371 through a network interface or adapter 370. When used in a WAN networking environment, the computer 310 typically includes a modem 372 or other means for establishing communication over the WAN 373, such as the Internet. The modem 372, which may be internal or external, may be connected to the system bus 321 via the user input interface 360, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 310, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
The foregoing detailed description of the inventive system has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the inventive system to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the inventive system and its practical application to thereby enable others skilled in the art to best utilize the inventive system in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the inventive system be defined by the claims appended hereto.
