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 ? 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 ? 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.
