Le vendredi 30 mars 2012 à 22:15 +0300, Sergiu Ivanov a écrit : > Hello, > > I will answer to a comment by Tom here, partly because it's more > comfortable for me to write E-mails. Should anyone feel this switch > is wrong, we can always turn back to discussing on Melange. > > Tom Bachmann March 30, 2012, 9:37 a.m.
> > >Regarding Object-Oriented redesign of polys code: please consider that > Mateusz (the main author of everything in polys/) has put a lot of > thought and work into the code. Note also that for many applications in > mind, the performance of Groebner basis algorithms is highly sensitive. > Thus at least the core functionality should be implemented in as raw a > form as possible. This also facilitates later potential > re-implementation in e.g. C. In any case, Mateusz is the most likely > mentor for this project, so it's him you have to get on bord. Note also > that in domains/, there are already classes for rings, polynomialrings > etc (although they implement functionality somewhat different from what > you envision). Writing C in Python gives you the speed of Python and the maintainability of C. If you want fast Pythonic code, you need to use Cython or PyPy (well, ATM, PyPy is crap at dealing with big integers, but hopefully, one day...). They both target idiomatic Python code, so code using classes in a pythonic way, without over-engineering, is actually likely to be faster than a mass of global functions with many extraneous arguments. > > Yes, I absolutely don't doubt that a lot of thought has been put into > the code I was looking at. However, the polys module is not > absolutely devoid of classes, therefore I think that my additions > aren't that unusual :-) > > Nevertheless, the fact that I try to use the object-oriented approach > in my implementation in no way hinders the eventual exclusion of > classes. The classes I am suggesting are only going to include a > couple methods; it should be very easy to take these methods out and > turn them into simple functions, thus forgetting about classes. That's the job of a compiler. You shouldn't worry about it at all. > > >Regarding object-oriented structures for algebraic objects: please > note that various people in various GSOC projects, and also without > GSOC, seem to be thinking about implementing this sort of thing. In > fact I myself have been toying with the idea of implementing a > commutative algebra / algebraic geometry module that provides various > of the classes. What I am trying to say is: implementation and > optimization of the groebner-walk algorithm is most likely the most > importand, and hardest, part of your project, and it would be a great > addition to sympy. It seems less important, and more messy, to get the > "meta-infrastructure" set up and past tons of discussion on the list > (this is not to discourage you, just a heads up...). > > Thank you for pointing out the classes in domains/ ! I haven't > managed to come over them. As you have noted, these classes indeed > focus on something different from what I envision to achieve with the > classes I suggest. I will make an explicit point (and I will also > modify the proposal accordingly) that I in no way plan to fully > implement rings and polynomial rings as algebraic structures. My goal > is making my code future-compatible with the eventual introduction of > these algebraic structures. Frankly speaking, I won't be surprised if > the classes which I will (maybe) implement will eventually be thrown > away and substituted with something else. However, migrating the > Groebner walk to this "something" else should be much easier because > of the foundations I am going to lay in this project. As far as I can tell, "domains" don't represent algebraic structures but are metadata for concrete types. So I agree with your assessment. > > On the other hand, as I say in the proposal, the classes Ring, Ideal, > etc. will only have the most basic of the functionality; I can't even > consider them to be skeletons of the corresponding algebraic > structures. This is why I don't expect much trouble with getting such > changes merged, especially if I have discussed the modifications > before. > > >More technicalities: "high-level" classes should apparently go into > "...tools.py" files in polys/. Look at e.g. polytools.py --- it has a > GroebnerBasis class! Well, that's an awkward and evidently confusing convention. Feel free to reorganise the code more logically. > > Oh, indeed! Thank you so much! I have seen it appear across the > code, but I couldn't trace the name to the origins and eventually > forgot about it :-( > > I will modify my proposal accordingly. > > >[If the above sounded rather critical: let me stress that you seem to have > >put a lot of work and thought into this, and the proposal is very solid. All > >of my comments should be considered as "minor".] > > Thank you very much for your feedback! And thank you for worrying for > the possibility of interpreting your comments as critical :-) > > 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.
