On Fri, Mar 30, 2012 at 4:59 AM, Ronan Lamy <[email protected]> wrote: > > This looks like it'll be a solid proposal. In particular, you do a good > job of summarising the feasibility of your project, its evaluation > criteria and the benefits it would bring. However, some points > (particularly the section "Infrastructure setup") could be made more > concrete if you wrote some doctest-ish pseudocode. Bonus points if the > code actually works.
Thank you for your feedback! I will throw down some pseudo-code in a couple of days. >> As a way to better structure the code, I propose a (partial) > transition to object-oriented design. > > Yay! +10. Cool :-) >> I suggest defining a very basic class Operation which will initially > contain one method with two arguments, which will perform the operation > itself. > > I suspect that having to use the object in order to perform the > operation would be cumbersome, so it might be more fruitful to consider > Operation as a description of the operation, instead of as the operation > itself. This is exactly the point of Operation: it will eventually store the information about the operation *and* will be able to actually perform the operation on two elements. The problem is that implementing a full fledged Operation is beyond the scope of my project, so I am only going to set up a very basic form of it. Eventually, when someone (maybe myself even, but later) gets to work on base classes for abstract algebraic structures, it will be possible to easily migrate the existing Groebner code base to the proper structures. >> I will start by defining the function nextPoint() > > "nextPoint" isn't PEP8-compliant. It should be "next_point". Oh, sorry, habits :-( Fixed. >> July 9 - July 15: start merging the changes upstream; start working on > the documentation; > > That's rather late. Any pull request with more than ~10 commits is > painful to review. A pull request at that stage is likely to contain a > few dozen commits, so you'd be lucky if it got merged before the end of > August. You should endeavour to send pull requests as soon as you have a > consistent and well-tested piece of functionality. I actually had this thought while writing the proposal, but wasn't sure about it. For me, pushing things upstream in small chunks feels much more comfortable; it's good news that the developers are also comfortable with strategy. Fixed the proposal by removing explicit statements about merging in the timeline and adding a proposition about pushing things in small chunks after the timeline. 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.
