On Wed, Apr 4, 2012 at 12:50 AM, Tom Bachmann <e_mc...@web.de> wrote: >> Tom, I think I understand your points, but I'd still like to ask you >> whether you find it acceptable to have the classes I have suggested in >> SymPy? >> > > Also, I think we got a little carried away by the whole Ring.mul vs __mul__ > business. I think it has been established now that the approaches are > interchangeable. Regarding other aspects of your proposal: > > - "class Ring which will contain two instances of Operation and will have > only the basic functions, such as storing a set of generators." > > This is *more* concrete than the current Ring class. In particular, what do > you mean by storing a set of generators? What are generators of QQ? What of > ZZ(x)?
Yes, you're right, this phrase was continually scraping the back of my mind. Probably, this should sound like: "store the underlying set of the ring". I think I should also state the fact that Ring may eventually include other ways of representing rings in software. > - deriving RingIdeal from ring, treating it as a subring: > > I don't think that makes sense. Ideals have no natural multiplicative unit, > whereas a type of ring I tend to think of has (admittedly, this may > sometimes be relaxed). I'm not sure I see your point here; indeed, an ideal of ring with a multiplicative unit need not necessarily include the unit, but this doesn't make it less of a ring. > But I do agree there should be an Ideal class, which > somehow relates to a particular ring. [I'm from a commutative algebra > background. To me an ideal is a particular kind of module. However, I think > it is helpful to have a separate class, since there are a couple of > operations that make sense on ideals that don't on modules.] Great :-) > - PolynomialRingIdeal will store a reference to the field > > What for? It stores a reference to the ring, which already has a reference > to the field. Oh yes, sure, thank you for pointing this out. > I think I should make it clear that I agree that the kinds of classes you > sketch are desirable and needed. As I have said a couple of times I am > somewhat reluctant to designing large, boiler-plate class hierarchies (as > you say, most of your classes will not really *do* anything), mainly because > I don't feel confident I can anticipate the needs of *actual* code > correctly. However, this should not discourage you. If you feel it helps > your project, by all means implement these classes (imho). Thank you very much for your feedback! Anticipating the future needs which are unknown at the moment is indeed meaningless. However, the classes I'm suggesting are actually meant to fit my current needs of some basic implementation of ring theory, while *also* being easy to later extend. Also, the class hierarchy I describe looks neither large, nor boilerplate to me :-) > As I have also said before, I have some interest in implementing commutative > algebra / algebraic geometry code for sympy myself. But as I said, I feel > like I work in a "lower level" of the class hierarchy. I may create classes > called e.g. "Ideal", but please feel free to understand them as > "ParticularIdeal", i.e. so that you can add more suitable, general base > classes above. Oh, I see. Again, I'm truly thankful for your feedback. Sergiu -- 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.
