Hi Krastaonv Thanks for the feedback. You bring up a number of important issues. I'd like to respond to the main one
I completely agree that the solution needs to clearly separate abstract tensors (multi-linear functions) from indexed collections of components (ndarrays). I think the difficult part is to find a formulation which arranges all of the classes/ideas you mention above (LinearOperator, Matrix, Tensor, Indexed, VectorSpace, etc...) in a simple and elegant manner. On Wed, Feb 22, 2012 at 6:51 PM, [email protected] < [email protected]> wrote: > On 20 February 2012 23:20, Matthew Rocklin <[email protected]> wrote: > > @Aaron Thanks for the feedback, the KroneckerDelta anecdote is > hilarious. I > > suspect that a lot of current work could be refactored with a good linear > > algebra module. There is even a current GSoC project discussing units > that > > could make use of it. Lots of things that SymPy finds difficult are > > easily representable as vector spaces. Thanks also for updating the page, > > ground types is not something I know much about. I'll add to the projects > > page when I get some time. > > > > @Alan I completely agree about abstract index notation. I have a small > > section of the wiki page on tensor indexing. There I pose that we might > be > > able to use indexing as a way to define most operations. The tricky thing > > with this project is how to describe all tensor-ish operations with a > single > > syntax that can be applied to a wide variety of applications. Can we > create > > a single system which can be cleanly extended to include both Riemannian > > geometry and dense matrix computations? My current thought is > that indexed > > expressions are a powerful-yet-general description that these > > representations all share. > I do not think that mixing tensors and matrices too much is a good > idea. The main problem with the proposals I have read on the wiki is > that matrices and linear operators are not distinguished sufficiently > well. Many of the proposals make sense for linear operator, but not > for matrices. > > More precisely: > > 1. Matrices are only a representation of a linear operator. > > 2. A basis must be chosen before creating this representation. The > information about the basis is not contained in the matrix > representation. > > 3. The information about the vector space is lost when taking this > representation. For example a linear operator from R^n to R^m (vectors > formed of real numbers) and from R[n-1] to R[m-1] (polynomials with > real coefficients) will both be matrices in M(R, n, m) (n-by-m real > matrices) > > 4. MatrixSymbol is not enough. We need LinearOperator that contains > VectorSpace (one for the domain of definition and one for the Image). > Then we can generate matrices and matrix symbols from the > LinearOperator. > > 5. Tensor is an object closer to LinearOperator than to Matrix. It > contains the information about the TangentBundle. Only when we add a > basis and the indices stop being abstract we get actual > multidimensional arrays, but this is not the interesting part in their > usage. > > 6. Using the tensor as a base for matrix is a bad idea because: > 6.1 Abstract tensors do not depend on the basis (they are akin to > LinearOperators, not matrices, see 5 and 2) > 6.2 Even when the indices stop being abstract you will use tensors for > stuff that is much different than the main usage of matrices. I won't > use "sparse" tensors, but I may use "sparse" matrices. I don't care > about the ground types of the tensor, because I use it as a symbol, > not as a container. I care about the base type of matrices, because > they are used in the core of high performance algorithms just like the > poly module. > 6.3 TangentBundle and VectorSpace are not the same at all in > implementation terms. (I can back down on this if I see a good > proposal). > > So I imagine something like: > 1. LinearOperator, VectorSpace, Vector (_not_ a container, just a > symbol, no shape, it may be a function or a polynomial if the vector > space is over them) > > 2. Tensor, TangentBundle, AbstractTensor (with abstract indices) > (Those are _not_ containers, but symbols) > > 3. Indexed (the class currently in the tensor module. It seems like > the way forward for interoperability with numpy) This is a container > with some other smart operation defined on it. It does not contain > information about the basis that is used. It has shape. > > 4. Matrices, MatrixSymbol, ImmutableMatrix. (2D container that rests > completely separate from Indexed for performance reasons. It has > shape. Does not contain information about the basis that is used). > > 5. When deciding on a basis, LinearOperator can generate a Matrix and > Tensor can generate an Idexed. > > 6. Maybe creation of IndexedSymbol akin to MatrixSymbol, and > ImmutableIndexed (I am not sure that Indexed is actually mutable) > > 7. Maybe the creation of common base for IndexedSymbol and > MatrixSymbol, but not for Indexed and Matrix > > 8. Ground types are import for Matrix, not for the others. Container > types (list, numpy arrays, etc.) are important for Matrix and Indexed, > not the others. > > I am definitely not seeing the whole picture, but I consider the > distinction between LinearOperator over a VectorSpace and Matrix over > some basis a very important one. > > The symmetries treating code should be implemented in LinearOperator > and Tensor and not in Matrix and Indexed in my opinion. There should > be some way to check the Matrix class for symmetries. > > Stefan > > > your idea of finding symmetries) would apply for all application > projects. > > > > I really appreciate the input so far. I think that if only one person > thinks > > about this project then it will likely end up as > > just-another-linear-algebra-module. Extra perspectives greatly reduce > this > > risk. I would be interested in what people could see coming out of a > general > > linear algebra system. What projects would this facilitate? > > > > On Mon, Feb 20, 2012 at 9:38 PM, Alan Bromborsky <[email protected]> > > wrote: > >> > >> On 02/20/2012 10:00 PM, Aaron Meurer wrote: > >>> > >>> I updated the section on that page about ground types to be a little > >>> clearer about what we want there. Many things will actually involve > >>> improvements to Poly() to get things to work (for example, the > >>> addition of a Frac() class). > >>> > >>> Aaron Meurer > >>> > >>> On Mon, Feb 20, 2012 at 7:40 PM, Aaron Meurer<[email protected]> > wrote: > >>>> > >>>> On Mon, Feb 20, 2012 at 2:19 PM, Matthew Rocklin<[email protected]> > >>>> wrote: > >>>>> > >>>>> Hi Everyone, > >>>>> > >>>>> I would like to create a general tensor/linear algebra framework for > >>>>> SymPy. > >>>>> I'd like to hear ideas from the community about this. > >>>>> > >>>>> We already have a few linear algebraic projects within SymPy > >>>>> (i.e. Matrices, SparseMatrices, MatExprs, Indexed/IndexedBase code > >>>>> generation, Physics stuff, Geometric Algebra (sort of)) but they > don't > >>>>> communicate well. It would be nice to create a general and abstract > >>>>> framework off of which these projects and others could hang and > >>>>> interact > >>>>> more naturally. > >>>>> > >>>>> I'm writing the community about this for two reasons. > >>>>> Reason one: I'd like feedback as to whether or not this sort of > >>>>> undertaking > >>>>> is a good idea. If it is I'd welcome some thoughts on how it should > be > >>>>> done > >>>>> and how it could be useful for future work. > >>>> > >>>> Definitely. One problem right now is that a lot of modules duplicate > >>>> work, because we don't really have a good centrailzed module for > >>>> things. For example, over GCI, a student merged together three > >>>> independent KroneckerDelta implementations (one in > >>>> sympy/physics/quantum, one in sympy/physics/secondquant, and one in > >>>> sympy/functions/special/tensor_functions.py). No doubt there are > >>>> other things still duplicated. > >>>> > >>>> That's also why even if we are implementing some of these things to > >>>> help with physics, we should try to separate mathematical concepts > >>>> from physical concepts in the implementation. > >>>> > >>>>> Reason two: I think I can separate this work into a few pieces, each > of > >>>>> which would make for a good GSoC project for this year or next. Is > this > >>>>> endeavor something into which the community would want to invest > >>>>> resources? > >>>> > >>>> I think so. Some projects may depend on others (e.g., we're limited in > >>>> what we can do with slow matrices). But feel free to do this and add > >>>> the ideas to the GSoC ideas page. That page needs more ideas that > >>>> have more descriptions on them (like the ones at the bottom). Not > >>>> only will this help potential students, but it will help us a lot when > >>>> we apply. > >>>> > >>>> Aaron Meurer > >>>> > >>>>> Here are some projects that interest me > >>>>> > >>>>> Framework design - we need a sufficiently general framework (this is > >>>>> hard > >>>>> and probably has to be half completed before GSoC time) > >>>>> Abstract Vector Spaces > >>>>> Tensor Math - Krastanov was talking about this and I think it's a > great > >>>>> idea. There is a lot of good multilinear algebra out there that SymPy > >>>>> doesn't currently touch at all. > >>>>> General storage - Efficient NDArray classes (dense, mutable, sparse, > >>>>> functional, numpy, external programs) - views of NDArrays (transpose, > >>>>> slices). > >>>>> Theorem proving type system for > >>>>> tensors/matrices > >>>>> > http://scicomp.stackexchange.com/questions/74/symbolic-software-packagbasic > >>>>> es-for-matrix-expressions > >>>>> > >>>>> I've dumped some thoughts on the following wiki page > >>>>> https://github.com/sympy/sympy/wiki/Linear-Algebra-Vision > >>>>> > >>>>> Comments or questions are welcome. > >>>>> > >>>>> -Matt > >>>>> > >>>>> -- > >>>>> You received this message because you are subscribed to the Google > >>>>> Groups > >>>>> "sympy" group. > >>>>> To post to this group, send email to [email protected]. > >>>>> To unsubscribe from this group, send email to > >>>>> [email protected]. > >>>>> For more options, visit this group at > >>>>> http://groups.google.com/group/sympy?hl=en. > >> > >> I am rewriting the geometric algebra module using noncommuting symbols > to > >> represent base vectors and base multivectors and let general > multivectors be > >> linear combinations of the base multivectors and let sympy do the heavy > >> lifting with regard to simplification and other operations. The current > >> GA module was written before I understood what sympy could do and is a > real > >> mess from the point of view of being an extensible module. > >> > >> Someone should employ all the inherent abilities of sympy to write a > >> module for Tensors using Penrose's abstract index > >> http://en.wikipedia.org/wiki/Abstract_index_notation notation > especially > >> allowing for simplifications using tensor symmetries and also allow for > >> symbolic differentiation. > >> > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "sympy" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group at > >> http://groups.google.com/group/sympy?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sympy" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/sympy?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
