Hi, On 4 April 2012 14:03, Sergiu Ivanov <[email protected]> wrote:
> On Tue, Apr 3, 2012 at 10:01 PM, Joachim Durchholz <[email protected]> > wrote: > > Am 03.04.2012 20:30, schrieb Sergiu Ivanov: > > > > This discussion has gotten somewhat circular, and no single posting has > > addressed all points and put them into perspective. > > So that's my other proposal: write up all proposals, enumerate the pros > and > > cons of each, then decide. > > I will expose my understanding of the situation; it is obviously > biased :-) > > Current Ring class (operation-aware elements). > > Pros: > > * easier manipulation of elements of a ring (a*b instead of > R.mul(a,b)); > > * is already implemented. > > Cons: > > * it's somewhat cumbersome to define two different rings over the > same set of elements; > > * it is unclear where to store the metadata about ring operations, > because this information seems to belong to the ring, while the > operation itself is implemented in elements; > > * more dependencies between classes: elements need information about > the operations, the ring needs information about the operations. > > Suggest Ring class (operation-unaware elements). > > Pros: > > * one can define several rings over the same set of elements without > influencing the elements themselves; > > * all concepts are fully gathered in the corresponding classes > (Operation, Ring, Element), which minimises the number of > dependencies between the classes: in this setup, ring depends on > operation; > > Cons: > > * unwieldy way to apply operations (R.mul(a,b) instead of a*b); > > * too verbose for cases where the information about the operation is > not very important. > > (We have all seen that both approaches can easily emulate the other > one, so I didn't list emulation on any of these lists). > 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". 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. > Sergiu > > -- > 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. > > Mateusz -- 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.
