OpenMath Browser
Go to the demo
OpenMath Browser is an application for summarising and browsing of large mathematical expressions. It is a part of my final year project "Intelligent summarising and browsing of mathematical expressions" under the supervision of Prof. James Davenport.
OpenMath Browser offers the following capabilities:
Comments are welcome to: i.stoyanova@alumni.bath.ac.uk.
- Reading and parsing OpenMath 2.0 input in XML format (using the RIACA library developed by Research Institute for Applications of Computer Algebra, Eindhoven University of Technology);
- Performing summarisation and expansion on the OpenMath object;
- Translating the OpenMath object into LaTeX (using an OpenMath to LaTeX phrasebook) and rendering mathematical expressions in LATEX (using JLatexMath package).
More information about:
Notes on examples
- Width of the image of the mathematical expression is assumed as a relative measure for the efficiency in terms of graphical reprsentation. This is supported by research on understandability (or what we call efficiency in terms of semantic representation), which suggests that the visualisation of the abstract structure facilitates understanding. Thus, the abstract structure needs to be visible as much as possible at the initial encounter of the expression.
- Expressions are displayed using the same size and type of font, thus width comparisons are based on relatively stable criteria.
- Partially summarised expressions display first occurrence of subexpressions and replaces further occurrences with labels.
- Labels for repeating subexpressions contain their unique id and use the same colour as the box in which the substitution is defined (i.e. the first occurrence of the subexpression when it is assigned an id).
- In fully summarised expressions all occurrences of repeating subexpressions are replaced by labels which are then defined below the main expression.
- Equivalence of representations (see example 3 below) is not considered in the project.
Examples
Collection of OpenMath files: OMcollection.zip
1. Typical example: improvement in both graphical and OpenMath representation (cubic.omx; Example 1 in the demo)
Original expression Original Image Summarised expression Partially summarised image Fully summarised image 7202 symbols 56 cm 4249 symbols 79.4 cm
(due to labelling)21.4 cm
2. Problematic example: improvement in OpenMath representation but not in graphical (integral.omx)
Original expression Original Image Summarised expression Partially summarised image Fully summarised image 15206 symbols 249.2 cm 7122 symbols 214.8 cm 176.5 cm
3. Problematic example: no improvement in OpenMath representation but graphical representation is not possible if not summarised (large-pol.omx; Example 5 in the demo)
Original expression Original Image Summarised expression Summarised image Other possible representation 48299 symbols >1000 cm 48299 symbols 10.9 cm 1.6 cm
4. Large matrices (matrix1.omx, matrix2.omx, Examples 7 and 8 in the demo)
Original matrix Original Image Summarised expression Summarised image Other possible representation 186167 symbols 71.1 cm 186167 symbols 8.1 cm - 48299 symbols - 48299 symbols 8.1 cm -
Problems
- Display of expression to fit within screen dimensions so that its abstract structure is visible from the beginning.
- To find the ballance between information a label can provide and the idea of supressing details so that the structure is visible.
- To find the best approach towards more user friendly representation.
- To decide upon summarisation method by observing the characteristics of original expression.
- So far most of the summarisation depends on the type of mathematical operation or object (e.g. whether the expression is a long sum, product, matrix, etc). The question is to what degree is it possible to adopt an abstract approach? Furthermore, the big question is WHAT IS A LARGE EXPRESSION? How large an expression/subexpression needs to be so that it worth replacing it with a label: e.g. if we replace "3.a.b" it will improve the OpenMath representation but maybe will affect negatively graphical representation; also some subexpressions (or features) have a more important role than others, how to distinguish them.
Conclusions and future work
- Do not, by default, replace sub-expressions by longer labels.
- Do not, by default, use 'common' sub-expressions which are no longer common when the full DAG has been formed.
- We say 'by default' in the above two because the user might be interested in all common structure.
- Not making explicit all the multiplication signs in the expression - the challenge lies, as always, in deciding which can be elided.
- Better default behaviour for matrix displays.
- Consider mathematical equality.
- Allow more flexibility for summarisation - sometimes it may be required to treat differently particular occurrences of expressions.
- Allow more flexibility for navigation.
Features and functionalities of OpenMath Browser
Please refer to the manual: manual-demo.pdf
Please feel free to email me questions and/or comments to i.stoyanova@alumni.bath.ac.uk.
Go to the demo