On Thu, Mar 13, 2014 at 9:28 AM, Tim Lahey <[email protected]> wrote: > On 13 Mar 2014, at 15:17, Ondřej Čertík wrote: >> >> >> It's really up to us how we design CSymPy. But I would try to reuse as >> much >> as we can from other libraries where it makes sense rather than >> reimplementing stuff ourselves. So in particular, I would use Flint, >> Eigen, >> Armadillo etc., as those are well tested libraries with wide usage. >> > > The problem I see with this approach is that there could be a lot of > conversions between the different types used in the specific libraries. > Plus, there's the situations like with linear algebra. There's numeric > linear algebra libraries, but they're useless for symbolic linear algebra. > For numeric linear algebra, why don't we just defer to NumPy, as that's > their area of expertise? > > I had the library conversion problem in trying to implement my Master's > thesis in C++ as the linear algebra libraries and the ODE solvers all used > different vector/matrix types. I gave up and went to Fortran. > > If we're going to use additional libraries, we should make a careful > decisions as to when to use them. Otherwise, I can see CSymPy becoming Sage.
Those are some good points, I use Fortran too for numerics, almost every day in fact. CSymPy is currently much faster than Sage on some of the symbolic benchmarks that I tried: https://github.com/certik/csympy/tree/master/benchmarks because there is not the overhead of Python / C++ conversion. Ultimately, the goal of CSymPy is to provide fast symbolic manipulation library, with the particular applications to areas where people can't use SymPy because it is just too slow. In particular, I want CSymPy to be as fast or faster than other symbolic software, open source or commercial. So I really don't want to reimplement numerical algorithms etc. Coming back to the LA proposal from Thilina: I think that the most pressing application is to provide Matrix algorithms for symbols from CSymPy. For everything else, like double precision, or GMP, or other types, I would simply reuse LELA (here is the github repo: https://github.com/Singular/LELA) or maybe something else that is maintained more often (last patch to LELA is from a year ago). So in particular, let's concentrate most of the proposal on implementing specialized Matrix classes for CSymPy Basic types. That's the 90% of the uses, for now. To be honest, I wouldn't even worry about templating it -- we might do it later, if we think it makes sense. I am open on this of course. It makes sense to me to provide good solid implementation for CSymPy Basic type and then if we want to generalize this for some other types, we can always use this as the low level building block. But it seems to me that if we just do this for Basic, and wrap it to Python and make sure it works with SymPy, that would be super useful. Let me know what you think. Ondrej -- 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/CADDwiVDjHxDrKqr2HP%2BqLbuXxgYFTy895ffw9OHt%3DmB4LQMdhA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
