Hi All, Thanks Ondrej, Mario and Someone for your valuable input.
I accept that it's almost impossible for us to beat a good library like Flint and it's really unlikely that we will not have support for it in future. So definitely we should use it (or any othert library) to boost our performance. When doing so we should make sure that CSymPy doesn't become something like sage or become difficult for a developer to work on it as Ondrej has pointed out. So the bottom line is we should reuse whenever we can without sacrificing the maintainability, extensibility and user-friendliness. So I am going to change my initial proposal a bit and propose the following. How about writing a wrapper this summer for flint (or any other library we select) to be used with CSymPy? I guess Flint is written in C. Other alternatives we have are LELA and LInbox both written in C++. Latter two libraries support symbolic manipulation also. We can decide which library we should select and I would love to know what are your choices. Mario has already sided with Flint. I studied Linbox and LELA quite a bit but not in the perspective of writing wrappers on top of them. So I'll have to take a look at them again. In case we don't need to make this a hard dependency, as a fall-back implementation I could do our own implementation for Basic as Ondrej pointed out earlier. Since all the other types like Number, Integer, Rational, Function are derived from Basic, all of these types can be used with this implementation. We can also provide specialized versions of the Matrices and algorithms to these types. I would like to know your opinions on this. Regards, Thilina On Mon, Mar 17, 2014 at 1:21 PM, mario <[email protected]> wrote: > My opinion is that it would be great if CSymPy depended only on Flint and > its extensions; > for what is missing in it one could make other extensions to it or write > code > directly in CSymPy. The reason is that there are costs in using many > libraries; > one must learn how to use them; there is often a slowdown in converting > to the required > data structures. > > > > On Sunday, March 9, 2014 4:26:28 PM UTC+1, Thilina Rathnayake wrote: > >> Hi All, >> >> I would like to work on implementing a Linear Algebra Module for CSymPy >> this summer >> as a GSoC project. I like to focus mainly on Matrices and related >> algorithms as they play >> a central role in Linear algebra. >> >> I hope to implement following (rough) list of things related to matrices: >> >> 1. Basic Operations: >> Addition, Scalar multiplication, transposition >> Matrix multiplication >> Row operations >> Finding a Submatrix (by deleting specific rows and columns) >> >> 2. Square Matrices >> Decompositions >> Inverse >> Eigen values, Eigen vectors and Determinants >> Nullspace >> >> I haven't decided on the magnitude of the scope of this project but since >> Matrices are a >> well studied and implemented field in scientific and numeric computation >> lots of references >> can be found so we can start implementing right after we get the >> requirements and designs >> correct. >> >> Apart from SymPy matrices module, there are open source linear algebra >> modules >> implemented in c++ like Armadillo <http://arma.sourceforge.net/> and >> it++<http://itpp.sourceforge.net/4.3.1/>. >> Armadillo seems to be the fastest among >> these according to the benchmarks >> here.<http://arma.sourceforge.net/speed.html>Armadillo focuses on numeric >> computations. >> Following two links provide useful information about implementing >> numerical matrix >> algorithms in C++. >> >> http://arma.sourceforge.net/armadillo_nicta_2010.pdf >> http://itee.uq.edu.au/~conrad/misc/sanderson_templates_ >> lecture_uqcomp7305.pdf >> >> Generalizing these functions to work with elements from a more general >> field rather than >> numeric fields won't be that hard. That way we can support symbolic >> expressions as well. >> We can create a matrix base class and derive matrices which can support a >> specific >> Field (domain) effectively, like matrices with rational elements or real >> elements. >> >> Should we think about the implementation of about sparse/dense or >> mutable/immutable >> matrices as a part of this project? >> >> Regards, >> Thilina >> > -- > 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 http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/a1c958b6-5752-4314-ba3d-63f18f2cb5a2%40googlegroups.com<https://groups.google.com/d/msgid/sympy/a1c958b6-5752-4314-ba3d-63f18f2cb5a2%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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 http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAPnoRorOzkCimivJfc5a2ppK3rxC_Wea%3DYkEZdodf6%2BgAz1aCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
