On May 13, 8:51 am, Aaron Meurer <asmeu...@gmail.com> wrote: > On Thu, May 12, 2011 at 9:41 PM, Sherjil Ozair <sherjiloz...@gmail.com> wrote: > > I see. This doesn't seem very difficult. It boils down to adding more types > > to the groundtypes list. > > From an algorithmic point of view, all the algorithms need to know about the > > groundtypes, other than support for the 4 basic operations, is their support > > of the .is_zero function. > > The groundtypes that you mention, Aaron, have been implemented by mattpap in > > polys, along with the .is_zero functions. > > So that doesn't seem to be a problem. > > Has ZZ<sqrt(2)> been implemented by mattpap ? > > Yeah, at least to some extent. He could tell you more about what is > there and what isn't yet. > > > Aaron, other than this, what do you think about the class structure ? How do > > you think one should intelligently emulate Polys for the purpose of speeding > > up matrices ? > > Well, I'm not highly familiar with the data structures and algorithms > of matrices, but if it is designed like the polys, it should be good > (or at least on the right track). I would ask the following questions > about the design to see if it is good: > > - Is it easy to add new types at each level (ground types, > representations of matrices (sparse, dense, etc.), etc.) in a way that > does not require extending or even touching the others?
Each groudtype has a different class of its own. As in Polys, the Polys class automatically chooses the suitable groundtype by analyzing the data. So the only place, I think, that would affect addition of a new groundtype would be the function that determines which groundtype to use. > > - Is it easy to convert an object of one type to an object of a > different type on the same level (like sparse => dense)? This is one > case where I think the objects will have to know about each other. Each addition of a new object type X would involve adding methods toX() to all the other object types. Is this good enough ? > > - If we are going to have some kind of ImmutableMatrix that can play > nicely with Expr, how will that work with all of this? I was thinking of making ImmutableMatrix derive from MutableMatrix class, overriding its methods like __setitem__ which change the data of the class, and functions like __hash__. This might involve making Immutable counterparts of all DS classes, like ImmutableDOKMatrix, etc. However, there would be do code duplication. As to whether it plays nicely with Expr, I think it is largely Expr's job to work with Matrices nicely. What interface does Expr assume for a particular class to be able to become its member ? What functionality do matrices need to have apart from immutability ? > > That's all I can think of for right now. > > Aaron Meurer > > > > > > > > > > > On Fri, May 13, 2011 at 7:27 AM, Aaron Meurer <asmeu...@gmail.com> wrote: > > >> Yes, the "general expressions" meant Expr objects. But I think you > >> should allow more advanced fields than just QQ like the coefficient > >> fields in the Polys, things like ZZ(x), or even ZZ<sqrt(2)> (if you > >> reuse code from the polys, it should be easy to do anything that the > >> polys support). ZZ(x) is easier to work with than a general > >> expression, for example, you can tell if an element of ZZ(x) is zero > >> just by rewriting it as p/q, where p and q are expanded polynomials. > >> On the other hand, the zero equivalence problem is in general not > >> solvable for general Expr expressions, and even for those for which we > >> can solve it, it can be computationally expensive, involving calls to > >> things like trigsimp(). This simplifies the logic and correctness of > >> things like rref. > > >> There's a place in my Risch code where I manipulate matrices of > >> rational functions, and call things like .rref() and .nullspace() on > >> them, and it's essential that rref() is correct. In my case, I just > >> have it call cancel() (I had to modify .rref() to allow a custom > >> simplification function). By the way, if we had a Frac() class to > >> complement Poly for rationaal functions, you could just support that > >> in the matrices (that might be easier than trying to support the polys > >> coefficient field classes directly). > > >> Aaron Meurer > > >> On Thu, May 12, 2011 at 7:11 PM, SherjilOzair <sherjiloz...@gmail.com> > >> wrote: > >> > By 'rational function terms' and'general expression terms' do you mean > >> > that a matrix should take Expr objects as elements ? > >> > Of course, I missed to add it in the list of groundtypes. Felt it was > >> > obvious. > > >> > On May 13, 4:53 am, Aaron Meurer <asmeu...@gmail.com> wrote: > >> >> I think a Matrix could also have, for example, rational function > >> >> terms, and also you want to be able to support general expression > >> >> terms. How would that fit in your model? > > >> >> Aaron Meurer > > >> >> On Thu, May 12, 2011 at 5:51 PM, Sherjil Ozair <sherjiloz...@gmail.com> > >> >> wrote: > >> >> > Hello everyone, > >> >> > I took ideas from mattpap's thesis at [1], specifically the idea of > >> >> > multi > >> >> > level structure. > >> >> > The hierarchy I have in mind is > >> >> > Level 0 : A collection of functions that operate on groundtypes(GMPY, > >> >> > Python, Sympy). > >> >> > Functions of this layer will receive the Matrix data as arguments. > >> >> > Function names will be prefixed with identifiers as to which data > >> >> > structure > >> >> > it works on. > >> >> > This layer is unaware of Matrix classes. > >> >> > Functions of this level can only call functions of the same level. > >> >> > All the algorithms for factorization, etc. will be implemented in > >> >> > this > >> >> > level. > >> >> > Level 1 : A collection of classes like DOKMatrix, COOMatrix, > >> >> > DenseMatrix, > >> >> > etc. > >> >> > The data structure is defined in this class. > >> >> > This class will have user functions which use the functions of level > >> >> > 0. > >> >> > Level 2 : The Matrix class > >> >> > These class which will return one of the class of level 1 using the > >> >> > __new__ > >> >> > function. > >> >> > This idea is still unformed. I invite comments to help me evolve this > >> >> > idea. > >> >> > Ask if you feel something is not clear. > > >> >> > [1] http://mattpap.github.com/masters-thesis/html/src/internals.html > > >> >> > -- > >> >> > You received this message because you are subscribed to the Google > >> >> > Groups > >> >> > "sympy" group. > >> >> > To post to this group, send email to sympy@googlegroups.com. > >> >> > To unsubscribe from this group, send email to > >> >> > sympy+unsubscr...@googlegroups.com. > >> >> > 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 sympy@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > sympy+unsubscr...@googlegroups.com. > >> > 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 sympy@googlegroups.com. > >> To unsubscribe from this group, send email to > >> sympy+unsubscr...@googlegroups.com. > >> 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 sympy@googlegroups.com. > > To unsubscribe from this group, send email to > > sympy+unsubscr...@googlegroups.com. > > 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 sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
