raharrison / mathengine Goto Github PK

Currently solvers such as the NewtonRaphsonSolver and NewtonBisectionSolver, which require derivative values of the target function, have the option of using numerical differentiation through the finite difference methods, or to use a predefined derivative function from the user.

An option should be added to use the symbolic differentiation classes to compute the exact derivative of the target function before solving. This would give more precise results than when using numerical differentiation and would not require the user to provide an exact derivative function of their own.

The existing options of numerical differentiation and predefined derivative functions should still remain. Perhaps an enum should be added that specifies the method of differentiation.

The README file really needs some content that explains the library as a whole. Perhaps also include some code samples and usages etc.

The library has gotten quite big so the readme may also be pretty extensive to cover it all.

The library at the moment is overwhelmingly badly documented in terms of both comments and example usage code.

Detailed Javadoc needs to be added to nearly all current packages - especially the parser package which could be quite difficult for other developers to understand in it's current state. It would also be good to have example code which shows how to use each package.

This is however a very large task as the library has grown to be over the 20k lines mark. This however is still one of the top priorities.

Should not have a .toNodeNumber() method in Node. Instead each node should have its own NodeTransformer instance which provides a way to transform the current node into another type of node. For example a NodeMatrix holds a transformer that can convert it into a vector of vectors.

Possible syntax:

NodeVector vector = nodematrixinstance.getNodeTransformer().convertToVector();

If a UnaryOperator accepts a Vector as input, then for some operators such as NSolve, depending on how many elements there are in the vector different operations should be carried out.

Instead a UnaryOperator should maintain how many arguments it can accept. Before the implementation is called this is checked and an exception is thrown if the numbers of arguments do not match. This puts less pressure on the implementations.

Arbitrary precision arithmetic in unit conversions which would mean that no precision is lost when doing conversions.

This would be through the use of the BigRational class.

Currently for example when using doubles for the conversions, the results for certain conversions are less than ideal in terms of precision.

e.g: 40 megabits in megabytes = 4.989517819706498 instead of the correct answer of 5. This happens mostly in the digital storage category where the range of factors is extremely large.

Need to still have the option of retrieving the result as a double, however use BigRational internally for the conversions.

Need to check if this has any performance implications. Use of the BigRational(double) constructor is advised which constructs an object which represents the exact same bits as the double over BigRational(double, tolerance) which although can get better results, is slower and can fail. Should do some tests still on which one should be used.

The library needs a comprehensive set of unit tests for each package to locate and iron out any bugs.

Add VectorOperator that becomes superclass to all UnaryOperators that accept a vector as an argument. This will convert all arguments to a vector or a vector or vectors in the case that a matrix is passed in.

Also add MatrixOperator that only accepts matrices as arguments. Throws an exception if any other input is received or could convert it all to a matrix. Puts less pressure on the concrete operators.

Could also convert SimpleUnaryOperator into a NumberOperator as it already has the required behaviour.

A matrix with one internal row vector of size n gets parsed as a matrix of n rows each with one element.

The matrix should be correctly parsed as a matrix with one row.

e.g -

[ { 6, 18 } ] gets parsed as [ { 6 }, { 18 } ]