I agree. The biggest challenge with symbolic matrices is expression blow up. In some cases it is unavoidable, for instance, symbolic eigenvalues/eigenvectors use the symbolic solutions to polynomials, which are complicated in the general case for n > 2.
One thing I meant by "overhead" is that if the type of a matrix's entries is known to all be rational numbers, for instance, we can operate directly on those numbers, ideally using fast number types like gmpy.mpq. If they are all rational functions, we can use polynomial algorithms that operate on rational functions. These always keep rational functions in canonical form, and the zero equivalence testing becomes literally "expr == 0" (no simplification required). These can be more efficient than general symbolic manipulation. This is how the polys module is structured. See https://docs.sympy.org/latest/modules/polys/internals.html. It would be nice to have a similar structure in the matrices, where a matrix can have a ground domain (or type) associated with its underlying data. Aaron Meurer On Thu, Mar 14, 2019 at 2:52 PM Oscar Benjamin <[email protected]> wrote: > > (Replying on-list) > > On Thu, 14 Mar 2019 at 20:37, Alan Bromborsky <[email protected]> wrote: > > > > Since most pc these days have multiple cores and threads what not use > > parallel algorithyms. For honesty I must state I have a vested interest > > since I have a pc with a threadripper cpu with 16 cores and 32 threads. > > Parallel algorithms can offer improvement. Your 16 cores might amount > to a 10x speed up if used well for this kind of thing. The > double-threading probably can't be exploited in CPython. > > However I think that many of the things that SymPy is slow for have > *really* bad asymptotic performance: think O(N!) rather than O(N^2). > Many orders of magnitude improvements can be made by spotting these > where more efficient methods are possible. It's not hard in a CAS to > accidentally generate enormous expressions and end up simplifying them > down again. This leads to many situations where it would be vastly > more efficient to somehow take a more direct route. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxTeAGZUv1kdtKCvBRodMZPyX5jHh76G0M49VshwMziJZA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JGfKjgHP3EaoX%3DXW_SMfnbGOZgi9LLJoUT3Ty7%3Dutd%2BA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
