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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 [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. > > -- > 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. > > -- 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.
