In the last mail I completely disregarded the difference between Tensor and TensorField (and Vector and VectorField). For example the matrix describing a homogeneous VectorField in the Cartesian basis will not depend on coordinates, but it will depend on coordinates in spherical basis (because the basis of the VectorSpace in each point of the VectorField is different).
On 22 February 2012 19:51, [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.
