[GSoC] Linear Algebra Module for CSymPy

[Thilina Rathnayake]

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 and it++. Armadillo seems to be the fastest among
these according to the benchmarks here. 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

[someone]

Hi,

> Apart from SymPy matrices module, there are open source linear

> algebra modules implemented in c++:

Consider also eigen:

http://eigen.tuxfamily.org/index.php?title=Main_Page

and LinBox (and its forks):

http://www.linalg.org/

[Thilina Rathnayake]

Hi,

Thanks for the links. I'll have a look at them. I didn't even know they existed.

Eigen is even used by Google. That's really interesting.

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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@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/531c94b5.886e0e0a.2cb6.ffffbf67SMTPIN_ADDED_BROKEN%40gmr-mx.google.com.

For more options, visit https://groups.google.com/d/optout.

[mario]

csympy could use flint for matrices with multiprecision numbers

[Thilina Rathnayake]

Hi Mario,

Thanks for the reply.

One of the design goals of CSymPy is that user should be able to install

and use it without additional dependencies. Currently, only compulsory 

dependency for CSymPy is the gmp module. We can use FLINT, BLAS,

or LAPACK for linear algebra if the user is ready to install them, but if not

CSymPy should be able to do them itself. I think Ondrej will have something

to add to this.

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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@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/92d9c5ea-869d-4025-a3fa-53477a2eae67%40googlegroups.com.

[Thilina Rathnayake]

I am not sure BLAS or LAPACK supports arbitrary precision arithmetic. If not

we have to go with FLINT.

Regards,

Thilina

[Tim Lahey]

Keep in mind that symbolic linear algebra is quite different than
numerical linear algebra. A lot of the algorithms aren't designed for
symbolic matrices.

Cheers,

Tim.

>>>> 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

>>> https://groups.google.com/d/msgid/sympy/92d9c5ea-869d-4025-a3fa-53477a2eae67%40googlegroups.com<https://groups.google.com/d/msgid/sympy/92d9c5ea-869d-4025-a3fa-53477a2eae67%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 sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@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/CAPnoRopfocWKWOMg6SH2Zg9h4fadkjdY1eO8W%2B8s6tAgLgu%3D9A%40mail.gmail.com.

[Thilina Rathnayake]

Hi,

Thanks Tim for the heads up. I think Linbox currently offers symbolic

linear algebra algorithms so we can refer it.

 http://www.linalg.org/

Regards,

Thilina

email to sympy+unsubscribe@googlegroups.com.

To post to this group, send email to sy...@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/92d9c5ea-869d-4025-a3fa-53477a2eae67%40googlegroups.com<https://groups.google.com/d/msgid/sympy/92d9c5ea-869d-4025-a3fa-53477a2eae67%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 sympy+unsubscribe@googlegroups.com.

To post to this group, send email to sy...@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/CAPnoRopfocWKWOMg6SH2Zg9h4fadkjdY1eO8W%2B8s6tAgLgu%3D9A%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 sympy+unsubscribe@googlegroups.com.

To post to this group, send email to sy...@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/1E55FAB0-F118-4450-B0BF-5550B55D42C8%40gmail.com.

[Tim Lahey]

Yes, Linbox is probably your best bet for symbolic linear algebra code.

Cheers,

Tim.

> email to sympy+un...@googlegroups.com.

> To post to this group, send email to sy...@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/92d9c5ea-869d-4025-a3fa-53477a2eae67%40googlegroups.com<https://groups.google.com/d/msgid/sympy/92d9c5ea-869d-4025-a3fa-53477a2eae67%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 sympy+un...@googlegroups.com.

> To post to this group, send email to sy...@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/CAPnoRopfocWKWOMg6SH2Zg9h4fadkjdY1eO8W%2B8s6tAgLgu%3D9A%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 sympy+un...@googlegroups.com.

> To post to this group, send email to sy...@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/1E55FAB0-F118-4450-B0BF-5550B55D42C8%40gmail.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 sympy+un...@googlegroups.com.

> To post to this group, send email to sy...@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/CAPnoRop%2Bd6G6LhbUvV-ujgF3MXnRz5wd7Ya2PJ1f1KE51%3D-bBA%40mail.gmail.com.

[Thilina Rathnayake]

Hi All,

I studied about a fork of linbox called LELA which is used in Singular. It uses

the following strategy when creating and manipulating matrices. Though the

process is somewhat complicated, I think it's okay since because the user will

be calling these functionalities through python wrappers and we can provide

convenient APIs for the user to get his job done .

1. Define the Ring which the elements of the Matrix/Vector belong to -

    First we should define a ring from which the elements should be taken.
    We can provide inbuilt rings like Integers and Rationals. We can also support

    modular rings which contain integers modulo some number. To support more

    general rings, we can provide a wrapper which will take any type that implements

    basic arithmetic operations (built in or user defined).

    Defined rings can then be used to store the elements belong to the ring, to do
    arithmetic operations on the elements of the ring,  to perform various checks like
    similarity of elements.

2. Define Vectors/Matrices over the ring

    Next we can define a Matrix or  a vector using the elements from the defined ring.

    These can be Sparse or Dense and the algorithms used by these structure will
    differ depending on that. Various methods can be provided to initialize, iterate and
    perform basic Vector and Matrix arithmetic.

   

3. Set of Higher level algorithms can be provided for these matrices and vectors separately

    like finding determinant, rank, decompositions and etc..

I omitted a lot of implementations details and the nature of the API we should provide.
That should be discussed separately. But as an Architecture for the module, Is this okay?

You can read more about LELA's architecture here.

Regards,

Thilina

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/74BEC21E-9CBD-45D6-84A2-73FF8FD0C981%40gmail.com.

[Ondřej Čertík]

On Sunday, March 9, 2014 5:21:22 PM UTC-10, Thilina Rathnayake wrote:

Hi Mario,

Thanks for the reply.

One of the design goals of CSymPy is that user should be able to install

and use it without additional dependencies. Currently, only compulsory 

dependency for CSymPy is the gmp module. We can use FLINT, BLAS,

or LAPACK for linear algebra if the user is ready to install them, but if not

CSymPy should be able to do them itself. I think Ondrej will have something

to add to this.

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 only thing I would do, to make things easier to install is that if the user doesn't want to install all the dependencies of CSymPy, let's say Flint, then if you call the given function or class from CSymPy that depends on Flint, it would raise a runtime exception.

I think that's a reasonable compromise, because I can see easily that we might want to depend on 10+ libraries, but each of them typically is only used in some subfield that is very relevant to one user, but not 90% of the other users.

I am open to all suggestions regarding this.

Ondrej

[Tim Lahey]

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.

Cheers,

Tim.

---
Tim Lahey, Ph.D.
Post-Doctoral Fellow
Systems Design Engineering
University of Waterloo

[Ondřej Čertík]

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

[Tim Lahey]

On 13 Mar 2014, at 15:41, Ondřej Čertík wrote:

> 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).

I think LinBox (http://www.linalg.org) would work. It seems to be
updated more often than LELA. They each have their strengths and
weaknesses. LELA is a fork of LinBox. It looks like it can use
GMP/FLINT.

>
> 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.

I think that's a good idea.

[Thilina Rathnayake]

Thank you Ondrej and Tim for your inputs. I too think we should concentrate

on Symbolic matrix manipulation rather than the numerical matrices since there
are good libraries we can use to do them.

The approach used in Armadillo is that if the user is willing to install additional
libraries it uses them for fast calculations, otherwise it uses it's own implementation.
If we were to just throw an exception in this kind of a scenario, certain other modules

which user might think as unrelated, might have to be disabled too.

For example, Suppose CSymPy has an equation solver which solves a system
of equations using matrix manipulations. If we don't have our own implementation
of the matrices and if the user didn't install it through an external library, it won't be
possible for the user to use the equation solver.

If the goal of CSymPy is to be a symbolic manipulation library, I don't think the above is

going to be a big problem. I see lots of pros in concentrating just on symbolic calculation.

For example, if we do a good job on symbolic manipulation rather than the current general

CASs, CSymPy with a good numerical library like numpy might be an unbeatable
combination.

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 sympy+unsubscribe@googlegroups.com.

To post to this group, send email to sy...@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/86ADDFF2-CA11-4297-81ED-EAC785834D0F%40gmail.com.

[Ondřej Čertík]

On Fri, Mar 14, 2014 at 4:26 PM, Thilina Rathnayake
<thilin...@gmail.com> wrote:
> Thank you Ondrej and Tim for your inputs. I too think we should concentrate
> on Symbolic matrix manipulation rather than the numerical matrices since
> there
> are good libraries we can use to do them.
>
> The approach used in Armadillo is that if the user is willing to install
> additional
> libraries it uses them for fast calculations, otherwise it uses it's own
> implementation.

That's generally the best, e.g. for integer factorization, we
implemented a simple
and reasonable fast algorithm ourselves and use optional libraries for
(much) faster
execution if the user enables them.

> If we were to just throw an exception in this kind of a scenario, certain
> other modules
> which user might think as unrelated, might have to be disabled too.

Yes, and also one has to disable/enable our tests. So it's better to implement
a simple implementation ourselves.

>
> For example, Suppose CSymPy has an equation solver which solves a system
> of equations using matrix manipulations. If we don't have our own
> implementation
> of the matrices and if the user didn't install it through an external
> library, it won't be
> possible for the user to use the equation solver.

Right.

>
> If the goal of CSymPy is to be a symbolic manipulation library, I don't
> think the above is
> going to be a big problem. I see lots of pros in concentrating just on
> symbolic calculation.
> For example, if we do a good job on symbolic manipulation rather than the
> current general
> CASs, CSymPy with a good numerical library like numpy might be an unbeatable
> combination.

That's right. I see it to be used in combination with SymPy and other
Python libraries
to obtain nice environment. Btw, there is also this new NumPy like
library in C++:

https://github.com/ContinuumIO/libdynd

I don't follow it too closely, but I think it follows the same concept
as CSymPy --- stick to
pure C++, and provide optional Python wrappers.

Ondrej

[someone]

Hi,

> > The approach used in Armadillo is that if the user is willing to
> > install additional
> > libraries it uses them for fast calculations, otherwise it uses
> > it's own implementation.

I really don't see why we should spend so much effort trying
to minimize and cut the dependencies to powerful and mature
external libraries. This just wastes effort in reinventing
the wheel and all other parts of the car.

Sympy as well as almost any other software packet (in the scientific
world) does not live in free space but is most useful when interconnected
to many other packages.

Installing dependencies in really not a big problem in most cases.
And with good step by step documentation definitely helps in the
others.

[Thilina Rathnayake]

Hi,

I don't see any problem in using other good packages with CSymPy.
That is why I said that if the user is willing to install other libraries we
should allow it. This might provide very fast and efficient functionalities.

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 and having

our own fall-back implementation will benefit us a lot when the user decide

not to install them or the libraries are discontinued or become unusable due to

some reason.

I don't say that we should have fall-back implementations to all the modules

we use, but we should do so at least in the specific fields where we wish to
make a mark. Since CSymPy is more concentrated on Symbolic manipulation,
I don't find it a bad idea to reuse good numerical libraries available. It's okay even
if we don't do our own fall-back implementations to these numerical libraries.

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. If all what we do is just re-use existing libraries,
why should  someone use CSymPy in the first place? They can easily use the

existing ones directly.

This is just my view on this. Love to hear what all of you have to say.

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 sympy+un...@googlegroups.com.

To post to this group, send email to sy...@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/53251b97.491a0f0a.04ac.3f1eSMTPIN_ADDED_BROKEN%40gmr-mx.google.com.

[someone]

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.

> 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.

[Ondřej Čertík]

Hi,

On Sun, Mar 16, 2014 at 5:49 PM, someone <some...@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

[mario]

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:

[Thilina Rathnayake]

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

--

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+un...@googlegroups.com.
To post to this group, send email to sy...@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/a1c958b6-5752-4314-ba3d-63f18f2cb5a2%40googlegroups.com.

[Ondřej Čertík]

On Mon, Mar 17, 2014 at 9:40 AM, Thilina Rathnayake
<thilin...@gmail.com> wrote:
> 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

Flint already has a C++ wrapper, see http://www.flintlib.org/features.html.
So we would just use it.

> 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.

Flint doesn't provide matrices for symbolic expressions. So I would
stick with your original
proposal to write good linear algebra functionality for symbolic
types. I don't see any easy way around this.

Ondrej

> https://groups.google.com/d/msgid/sympy/CAPnoRorOzkCimivJfc5a2ppK3rxC_Wea%3DYkEZdodf6%2BgAz1aCQ%40mail.gmail.com.

[Thilina Rathnayake]

Thank Ondrej for the reply.

Yes, it seems like the we'll have to go back to the original proposal

Regards,

Thilina

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVB8OxForfZ8BqJ6dwLKVT0HxqhaWh61y4LQhVNfU1vP7Q%40mail.gmail.com.

[Thilina Rathnayake]

Hi,

I took a look at the Numerical libraries we can use. Both FLINT and LELA are

GPL licensed. So it's incompatible with the CSymPy's MIT license. Linbox

is licensed under LGPL but it has hard dependencies like Givaro. Take a look

at here.

http://linalg.org/linbox-html/dist.html

The libdynd which Ondrej pointed out earlier is released under BSD license
and I guess it's compatible with MIT license.

https://github.com/ContinuumIO/libdynd/blob/master/LICENSE.md

Any suggestions regarding this?
 

Regards,

Thilina

[Ondřej Čertík]

On Tue, Mar 18, 2014 at 10:18 AM, Thilina Rathnayake
<thilin...@gmail.com> wrote:
> Hi,
>
> I took a look at the Numerical libraries we can use. Both FLINT and LELA are
> GPL licensed. So it's incompatible with the CSymPy's MIT license. Linbox
> is licensed under LGPL but it has hard dependencies like Givaro. Take a look
> at here.
>
> http://linalg.org/linbox-html/dist.html
>
> The libdynd which Ondrej pointed out earlier is released under BSD license
> and I guess it's compatible with MIT license.
>
> https://github.com/ContinuumIO/libdynd/blob/master/LICENSE.md
>
> Any suggestions regarding this?

You can use any GPL licensed library, as long as it is optional, i.e. as long
as CSymPy works without it as well. That way we are not derivative work and
can use BSD-style license for CSymPy. Libraries, that we hard depend on,
i.e. CSymPy does not work without them (like GMP), must be BSD-style
or LGPL.

I would recommend to use any good library out there if it is useful.
If it's GPL licensed,
then it needs to be optional.

Ondrej

[Thilina Rathnayake]

Thanks Ondrej for the reply.

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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@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/CADDwiVBdNFTE7RbWLewyaN%3DsWRS9jhuNDOJ6J313N1tgOKDqSg%40mail.gmail.com.