On Fri, May 13, 2011 at 7:04 AM, SherjilOzair <sherjiloz...@gmail.com> wrote: > > > 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 ?
First, I'm assuming you really meant the PEP8 name to_X :) I think maybe you should allow both to_X and from_X, so you can actually just define all the methods on the new object and make it work without having to edit the already existing ones. > >> >> - 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 ? They should be non-commutative, and they need to check shape when multiplying. The first is (obviously) already implemented. For the second, see issue 1860. Aaron Meurer > >> >> 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. > > -- 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.
