On Jul 31, 2009, at 9:49 AM, Marco wrote:
> > Hi Ondrej, > > Thanks for your message and for your original talk. Let me just make a > couple of quick comments and I'll try to be more complete later. > > It is not clear to me how the object representing a vector space > should be set up. But something like what you suggest seems right. > > For example: > > 1. V = VectorSpace() would create an object V which represents a > vector space. as you suggest, it might take an optional argument for > dimension, and also for which field it is over (R, C, ...) I am mostly > interested in R and C but the others would be highly useful too. > > 2. V itself would be a class whose objects are, of course, vectors in > V. so v = V() would create in our namespace a specific vector v > inside V. > > 3. there is a tricky business when we think about subspaces: for > example, v generates a subspace of V, usually denoted Span(v). We > would like to be able to instantiate an element of V which is, for > example, NOT in Span(v). So in some way, in the namespace we should > have v as well as Span(v) (which itself is an instance of VectorSpace, > and would be a subvectorspace of V), and when we create w, we should > be able to specify that it is not in Span(v). > > Presumably VectorSpace would inherit from Set (not necessarily the > builtin set type, but one which is more mathematically accurate) and > perhaps we should be discussing Set instead, since the above is > partially set-theoretic requirement. You might take a look at this thread (http://groups.google.com/group/sympy/browse_thread/thread/98b2c2ea95958574/03c970e35fffe914?lnk=gst&q=set#03c970e35fffe914 ). Someone else on the list was starting to develop the interval class to do intersections and so on. I think we should have a general Set class, which could have properties like cardinality, sets that it is a subset of (like R or Z), whether the set is a field, and things like that. We could also use that to create some standard classes for R or C or Z[n] or whatever. Of course, if you want to deal with a finite set and actually manipulate the objects, it would be best to just stick with a Python set. By the way, what sorts of things would you end up actually calculating with the VectorSpace class? Aaron Meurer > > Point 3 is just one example of the kind of functionality we need to > truly capture what we do every day in what I would consider is the > most mainstream mathematics. > > Let me know what you think. > Marco > > > > > > On Jul 30, 9:02 am, Ondrej Certik <[email protected]> wrote: >> Hi, >> >> On Thu, Jul 30, 2009 at 12:15 AM, Aaron S. >> Meurer<[email protected]> wrote: >> >>> Hi. Ondrej will probably have better answers to your questions when >>> he replies, but here is my take >> >> Aaron's replies are excellent. Some comments below: >> >> >> >>> On Jul 29, 2009, at 9:57 PM, Marco wrote: >> >>>> I was very impressed by the description of SymPy here: >> >>>> http://www.euroscipy.org/presentations/slides/index.html >> >>>> and especially slide 14 "Internals: Object oriented model". >> >>>> I have a couple of general questions about how Object-oriented >>>> SymPy >>>> is. I'm a mathematician and would like to use or extend SymPy to do >>>> abstract differential geometry. >> >>>> 1. Where/how can I see a diagram of the structure of the classes in >>>> SymPy? >> >>> You could just download the source and look at the directory >>> structure >>> of sympy/. You could also do >>> >>> import sympy >>> >>> dir(sympy) >>> in a Python shell. All of the classes will start with uppercase >>> letters (except for some functions like sin and cos). >> >>>> 2. Is SymPy at all modeled after category theory, which organizes >>>> mathematics in an essentially object-oriented way? >>> I am not familiar with category theory, so I cannot answer for sure, >>> but Python is an object oriented language, so SymPy is object >>> oriented. However, the core is not organized in a highly abstract >>> object oriented way. You also might take a look at the SymPyCore >>> project, which is based on SymPy, which I think is closer to what >>> you >>> are talking about here. You should look into the code yourself to >>> see >>> if it is. >> >>> Also, for core objects, like Add, Mul, and Pow, the most important >>> thing is speed, so if a more abstract model would be slower, we >>> probably wouldn't use it. I personally think it could be improved >>> some, so don't think that the way it is now is the way it has to >>> stay. For example, we are hoping to get a Cython core at some >>> point. >>>> 3. Is there a SymPy approach to, for example, vector spaces? I do >>>> *not* mean matrix algebra or computations in components. I mean an >>>> actual abstract vector space, where objects would be vectors and >>>> one >>>> could take linear combinations of vectors. I'm asking this >>>> question >>>> as an example of a more general question - whether SymPy has been >>>> used >>>> to do "abstract" computations on mathematical objects such as >>>> vector >>>> spaces, manifolds, etc. (as mathematicians often do) rather than >>>> explicit ones in numbers or polynomials. >>> I do not know the answer for vector spaces. You might look at the >>> Geometric Algebra module, which implements a separate algebra from >>> the >>> rest of SymPy. We also have support for things like non-commutative >>> Symbols, though it isn't the greatest, but you could for example >>> represent a matrix as a non-commutative Symbol, with scalars as >>> commutative symbols. I think SymPyCore again might have more on >>> that >>> front, but you will have to check it out for yourself (or wait until >>> someone more knowledgeable replies). >> >> We use Python classes to represent mathematical objects, so it >> depends >> how abstract you want to go, I suggest you design a simple set of >> classes that would represent what you want, e.g. a vector space + >> acting on it. And then you create methods for these classes to do >> useful manipulation of your objects. And you can use the full of >> sympy >> to do useful stuff, e.g create some matrices for the base >> transformations etc., if you wanted, or you can stay totally >> abstract, >> if you wanted too. >> >> So I can imagine something like this: >> >> space = VectorSpace(<maybe add some more information about the space >> here, like a dimension>) >> >> base = space.base() #this would return a set of base vectors >> >> so it would return a set of Vector() instances. Tell us your >> particular application, I can help you design it. >> >> >> >>> We would love to have you help develop SymPy. Are you already >>> familiar with Python/Git? The best way to get involved is to just >>> start submitting patches and having your work reviewed. I do not >>> think differential geometry is supported yet, though I am not >>> positive >>> as I am not familiar with differential geometry. >> >> The only thing from differential geometry that we have so far is the >> calculation of the Schwarzschild metric in the general relativity, >> see >> the examples/advanced/relativity.py example how to do that. >> >> Ondrej > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
