lubgr / tsym Goto Github PK

The logic could be implemented in a Printer class, that is instantiated with an implementation of the interface PrintEngine. A PrintEngine has thus only one task: transforming the instructions given by Printer into some (markup) language.

Printer:

• Numbers >= 0, Symbols, Functions, Constants, Powers are treated as 'scalars'
• Sums, Products, Numbers < 0 are treated as 'composites'

PrintEngine methods:

• openParentheses()
• closeParentheses()
• addPositiveNumber(Number)
• addSymbol(Symbol)
• addFunctionName(Name)
• addPlus()
• addMinus()
• addUnaryMinus()
• addTimes()
• open/closeScalarNumerator()
• open/closeScalarDenominator()
• open/closeCompositeNumerator()
• open/closeCompositeDenominator()
• open/closeScalarExponent()
• open/closeCompositeExponent()
• openMultiline(int)
• nextLine()
• closeMultiline()
• openMultiColumn(int)
• nextColumn()
• closeMultiColumn()
• open/closeVector()
• open/closeMatrix()
• open/closeSquareRoot()

Implementations of PrintEngine:

• LatexEngine
• PlainTextEngine

(-1 + sqrt(2))*a could be (sqrt(2) - 1)

The searching based upon BasePtr hashes should be much faster than the sequential search currently in use. It might also be good to opt for static unordered_maps, as they don't change between instances - there is no need to fill the lookup table with entries for each object creation.

• can be used to decide whether the result of a transformation is worth storing in the cache (e.g. normalization) and maybe later on for a simplify() method
• pure virtual and const method complexity(), returning an unsignend in Base
• the implemented methods in Base-derived classes can e.g. return
  • Undefined 0
  • Numeric: integer 1, fraction 2, double 3
  • Constant 4
  • Symbol 5 (for both positive and non-positive)
  • Sum 5 + operands
  • Product 5 + operands
  • Power 5 + base + 2*exp
  • Function 6 + operands
• unit tests should all be in a new test/testcomplexity.cpp

Caching is currently implemented with local, static std::unordered_map instances, not protected by any locks taken on a mutex.

Enable/diableUtf8 and -Fractions from the Printer class must be accessible even if the class itself is not in the public API.

comparison should work similar to the comparison of Undefined objects. requesting toDouble(), numerator(), denominator() should at least print a warning before returning 0.

It appears that the the returning of the Determinant from the PLU decomposition isn't aware of the swaping of the rows and therefore the sign is probably flipped.

See https://github.com/rath3t/tsym/tree/determinant-PLU-swap-issue

When comparing two symbols with equal names, one created with a positive flag and one without, doPermute must return an appropiate order. currently, order::doPermute(aPositive, a) and order::doPermute(a, aPositive) will probably both return false, which is inconsistent.

The solution of a linear system of equations via Matrix::solve doesn't seem to be affected, only the determinant fails.

The main reason for having it in a header was the intent to allow for arbitrary matrix and vector types provided by client code. While this principle should be kept, it's reasonable to copy all matrix/vector entries of the system of equations via a standard type (likely std::vector) into a Pimpl-hidden backend. This could implement the current homebrewn or more optimized, third-party functionality, without exposing the details publicly. The copying of matrix/vector entries should't hurt performance, as the expression simplifications during the solution are much more costly.

These classes have no member variables and thus no state. it doesn't make sense to have them as classes. the sub-functions can be in an anonymous namespace or declared static inside of the implementation file.

Internally, they shall use libgmp's gcd and lcm functions, which could be faster compared to the current approach (both methods attributed to Number).

• interface AbstractNumber with subclasses Fraction, Int, None (= undefined, but that class is already there), Double
• possibly an infinity class
• even a templated class is possible to allow different integer implementations?

Probably, only the isEqual method must be overridden. The static variables for the symbol registry (even if construct-on-first-use) are unnecessary then. It's simpler, too, because the mechanism is only involved when a temporary variable is created, and not each time a symbol is instantiated. also makes the BasePtr ctors and dtor simpler.

There is no consistent boolean return value, because e.g. comparing two symbols will yield an unclear result. Using the order relation of these two symbols could be a choice, but obscures the difference between comparisons of e.g. numbers (or operands which can be compared with a definite result) and symbols (or operators that can't). A new Comparison object should instead be returned.

Implementation of the actual comparison can be achieved by a lessThan method that subtracts the right hand side from the left hand side and comparing to zero. This way, automatic simplification does the work, e.g. 3ab < 4ab results into -a*b < 0, which is unclear if a and b aren't symbols with a positive flag, and true otherwise.

Public methods of the Comparison class could be isTrue(), isFalse(), isUnclear(), isTrueByOrderRelation() etc.