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? - 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. - If we are going to have some kind of ImmutableMatrix that can play nicely with Expr, how will that work with all of this? 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.
