Hello, On Wed, Apr 4, 2012 at 10:26 PM, Mateusz Paprocki <matt...@gmail.com> wrote: > > I'm joining this discussion a little late, but let me clarify a few things. > If you look into the source code of polys, you'll see that sometimes I use > a*b (+, - (both), *, **), and sometimes domain.op(a, b) (e.g. QQ.quo(a, b)). > The reason to use certain operators directly is speed in the first place > (convenience is second). Each level of wrappers adds extra overhead that in > case of polys is unacceptable (note that it is not uncommon for polys to > execute operations millions or tens of millions times per computation). > Division (especially because of gmpy's default behavior) and everything else > (e.g. gcd(), lcm(), ...) have to use domain.op(a, b, ...) syntax. The > domains framework was developed to make algorithms in polys work with > different types of coefficients and (very important!) different backends for > each type (ZZ -> Integer, int, mpz). Abstraction was not a goal, so my > answer to your earlier question is "no, unless you can figure out how to get > both worlds work in one framework".
Thank you for explanation! I obviously didn't know the details, but the fact that Domain was tailored for polynomials to work better was what I thought immediately when Tom told me about those classes. > If you want to propose a new framework, you have to be very specific what > you want to achieve (provide us with concrete examples or preferably tests). > You said that this is needed for Groebner walk (as I recall). Tell us why > and then we can proceed with discussion. If the algorithm is complicated > enough, I strongly suggest to make it work over simple domains first and > then generalize it to make it work with whatever you want/need. My initial goal was as follows: I'd have liked to make my implementation of the Groebner walk ready for the *future* implementation of ring theory in SymPy. When I was shown the classes in sympy.polys.domains, I had the impression that these classes are not really fit to serve as a foundation for a solid implementation of ring theory, so I suggested a different class hierarchy in my proposal [0]. In short, the class hierarchy is the following: class Operation to represent an operation, class Ring to represent a ring, class RingIdeal. Then classes PolynomialRing and PolynomialRingIdeal. Each of these classes would only provide the basics of functionality, mostly concerned with actually carrying out the operations. However, in view of what you have just said and after this idea of mine has stewed in my head for a while, it looks like I should indeed focus on implementing the Groebner walk with the existing domain infrastructure. Afterwards, it should be possible to actually implement the classes I have suggested and make the Groebner walk (and, maybe, all Groebner bases-related stuff) capable of working with *both* a domain (as it does now) and the PolynomialRing class which I suggest. Obviously, in the second case, we will most certainly see a considerable cut in performance, but should be able to work in a more general setup. Sergiu [0] https://github.com/sympy/sympy/wiki/GSoC-2012-Application-Sergiu-Ivanov:-Generic-Gr%C3%B6bner-Walk -- 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.
