On Fri, Mar 30, 2012 at 2:22 PM, Ronan Lamy <[email protected]> wrote: > 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.
>From what I remember, there are logical base classes like Ring and Field, of which the domains are subclasses. >> >> 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. I agree. We should reorganize the polys so that the three layers are clearer, probably by using three subdirectories. Aaron Meurer >> >> 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. > -- 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.
