Hi, On Sun, Mar 16, 2014 at 5:49 PM, someone <someb...@bluewin.ch> wrote: > Hi, > > >> But what if one of the packages we use is discontinued for some >> reason? we will have to switch to another. So as Tim has pointed out, >> we should take careful decisions when we choose these additional >> libraries > > Right. This is the case. But there are some big old players around > that (hopefully) will stay for some more time. F.e. I don't think > GMP or eigen will become discontinued anytime soon.
Right. CSymPy currently (hard) depends on GMP. Btw, in the future, it would be nice to also play with alternative libraries, e.g. bsdnt: https://github.com/wbhart/bsdnt for arbitrary integers. > >> But when it comes to Symbolic manipulation, I feel that it will be >> better to have our own implementation which perhaps perform better >> (if we design it well) than the current libraries in use. > > Well, that is true under the condition that the own implementation > has some real advantages, be it speed, memory consumption or > whatever. In that case why even depend on another library? > > OTOH if we provide nothing but a much slower, less efficient > replacement for the external library, then why develop it at all? > > Now it depends on which of these two cases is the "default" clause. > > I don't think it's the first one as f.e. beating flint would > be highly non trivial if even possible. There is a reason why > they invested years into the development. > > Don't get me wrong, I'm not saying CSympy can not achieve > to be the leader. It probably can, but not in all domains of math > and not after such a short period of development. > > > I just don't think avoiding dependencies to well known libraries and > widely used libraries is worth the time. > > Anyway, don't get distracted by my comments. I think the bottom line is the following: We should carefully manage dependencies, specify which exact versions of which libraries are supported, test them on Travis-CI and only hard depend on libraries that are widely supported, like GMP. The goal of CSymPy is to provide fast symbolic manipulation for use cases, where people want to use SymPy, but it's too slow. For that, we want to provide our own implementation, that is faster/better than other libraries. Symbolic manipulation is coupled with other areas, like fast numerical evaluation and so on. We should use libraries for almost everything here. The only reason to provide our own simple (slower) implementation of let's say integer factorization is if we need to depend on a library that is perhaps not so widely used / easy to install, so that CSymPy still passes our test suite even if this library is not installed. This simplifies development and usage of CSymPy for users that don't care about this particular area (i.e. the fastest possible integer factorization). I can imagine easily depending on 20 or 30 external libraries for various things, and it would be a pain to always require all of them to be installed in order to send a patch to CSymPy. That's why I think if we only hard depend on a few (let's say 5) solid libraries and everything else is optional, it should be reasonably simple to develop CSymPy. And we would provide Debian, Sage, Conda, Hashdist, ... packages with all dependencies enabled. 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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/CADDwiVDy%2BCMGOLFDWHYi4RzCpUV4L1jY2Sk2fBgEjAc_O0oyMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
