> I just feel that we are getting stuck with and spending too much time on > things that we shouldn't be taking this much time. Therefore, I request again > to all parties involved : Please voice your views/problems with these > structural changes suggested so that we can move ahead with things.
I understand that you are eager to start writing code, but you should understand that having an actual design is a prerequisite for writing useful code. There are a lot of SymPy conventions that you and Sachin have not learned about yet and that are not respected in your designs. If we proceed that way most of what you write, even if functional will not be of great use for sympy. Anyway, if you two want to move faster, just contact each-other as I have suggested and propose a common API. I have made a few suggestions in https://github.com/sympy/sympy/wiki/Vectors-EM-framework#another-proposal. These suggestions fix the issues with tree traversal, scalar+vector errors and immutability but do not address interoperability with mechanics for instance. No ScalarField and no Vector classes are necessary for what I have written. Reuse whatever you find useful. And remember: when you start codding does depend on you - show an api design that you both have previously agreed on and that addresses: - immutability - tree traversal and sympy conventions - scalar+vector error detection - interoperability with mechanics On 11 June 2013 13:26, Prasoon Shukla <[email protected]> wrote: > Let us get some things clear here. Vector is going to be subclassed from > Basic. Also, after seeing the discussions/problems above, Vector + Vector > will give an Add on which we can call something akin to a .doit() to result > in a Vector. I do not see any problems with this approach. > > Next, reference frames. First thing is the distinction between RefFrame > class and CoordSys class. Stefan has pointed out that there is no need to > implement the classes differently. Okay, then we will have just one, > immutable, CoordSys class. The parameters required for intialization of > kinematic parameters will have to be provided when declaring the coordinate > system. New CoordSys object will result from methods like rotate, orient > etc. > > With these suggestions, I do not think that there should be any more > structural issues. If there are any more of these issues, please mention > them here now and please mention them as early as possible. > > These changes are justified, I hope, because this module has to play nice > with the rest of SymPy. > > I just feel that we are getting stuck with and spending too much time on > things that we shouldn't be taking this much time. Therefore, I request > again to all parties involved : Please voice your views/problems with these > structural changes suggested so that we can move ahead with things. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy?hl=en-US. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
